Skip to content

A
angle
Commit bc7554f9 by Geoff Lang Committed by Commit Bot
Options

Remove extension files that are not written by ANGLE.

We inconsistantly added some extension txt files to our extensions folder that are not maintained but possibly implemented by ANGLE. Some of these extensions trip up Android's automatic license detection. Bug: None Change-Id: I9bde4235c7ad2bf4d9bcf5385f4138296cef2c13 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2653848Reviewed-by: 's avatarJonah Ryan-Davis <jonahr@google.com> Commit-Queue: Geoff Lang <geofflang@chromium.org>
parent 8f6c328d
Showing with 0 additions and 3693 deletions
extensions/EGL_EXT_create_context_robustness.txt deleted 100644 → 0
Name
EXT_create_context_robustness
Name Strings
EGL_EXT_create_context_robustness
Contributors
Daniel Koch, TransGaming
Contributors to EGL_KHR_create_context
Contact
Greg Roth (groth 'at' nvidia.com)
Status
Complete.
Version
Version 3, 2011/10/31
Number
EGL Extension #37
Dependencies
Requires EGL 1.4
Written against the EGL 1.4 specification.
An OpenGL implementation supporting GL_ARB_robustness, an OpenGL ES
implementation supporting GL_EXT_robustness, or an implementation
supporting equivalent functionality is required.
Overview
This extension allows creating an OpenGL or OpenGL ES context
supporting robust buffer access behavior and a specified graphics
reset notification behavior.
New Procedures and Functions
None
New Tokens
Accepted as an attribute name in the <*attrib_list> argument to
eglCreateContext:
EGL_CONTEXT_OPENGL_ROBUST_ACCESS_EXT 0x30BF
EGL_CONTEXT_OPENGL_RESET_NOTIFICATION_STRATEGY_EXT 0x3138
Accepted as an attribute value for EGL_CONTEXT_RESET_NOTIFICATION_-
STRATEGY_EXT in the <*attrib_list> argument to eglCreateContext:
EGL_NO_RESET_NOTIFICATION_EXT 0x31BE
EGL_LOSE_CONTEXT_ON_RESET_EXT 0x31BF
Additions to the EGL 1.4 Specification
Replace section 3.7.1 "Creating Rendering Contexts" from the
fifth paragraph through the seventh paragraph:
<attrib_list> specifies a list of attributes for the context. The
list has the same structure as described for eglChooseConfig. If an
attribute is not specified in <attrib_list>, then the default value
specified below is used instead. <attrib_list> may be NULL or empty
(first attribute is EGL_NONE), in which case attributes assume their
default values as described below. Most attributes are only meaningful
for specific client APIs, and will generate an EGL_BAD_ATTRIBUTE
error when specified to create for another client API context.
Context Versions
----------------
EGL_CONTEXT_CLIENT_VERSION determines which version of an OpenGL ES
context to create. This attribute may only be specified when creating
an OpenGL ES context (e.g. when the current rendering API is
EGL_OPENGL_ES_API). An attribute value of 1 specifies creation of an
OpenGL ES 1.x context. An attribute value of 2 specifies creation of an
Open GL ES 2.x context. The default value for EGL_CONTEXT_CLIENT_VERSION
is 1.
Context Robust Access
-------------
EGL_CONTEXT_OPENGL_ROBUST_ACCESS_EXT indicates whether <robust buffer
access> should be enabled for the OpenGL ES context. Robust buffer
access is defined in the GL_EXT_robustness extension specification,
and the resulting context must support GL_EXT_robustness and robust
buffer access as described therein. The default value of
EGL_CONTEXT_OPENGL_ROBUST_ACCESS_EXT is EGL_FALSE.
Context Reset Notification
--------------------------
The attribute name EGL_CONTEXT_OPENGL_RESET_NOTIFICATION_STRATEGY_-
EXT specifies the <reset notification behavior> of the rendering
context. This attribute is only meaningful for OpenGL ES contexts,
and specifying it for other types of contexts will generate an
EGL_BAD_ATTRIBUTE error.
Reset notification behavior is defined in the GL_EXT_robustness
extension for OpenGL ES, and the resulting context must support
GL_EXT_robustness and the specified reset strategy. The attribute
value may be either EGL_NO_RESET_NOTIFICATION_EXT or EGL_LOSE_-
CONTEXT_ON_RESET_EXT, which respectively result in disabling
delivery of reset notifications or the loss of all context state
upon reset notification as described by the GL_EXT_robustness. The
default value for EGL_CONTEXT_OPENGL_RESET_NOTIFICATION_STRATEGY_EXT
is EGL_NO_RESET_NOTIFICATION_EXT.
Add to the eglCreateContext context creation errors:
* If <config> does not support a client API context compatible
with the requested context flags and context reset notification
behavior (for client API types where these attributes are
supported), then an EGL_BAD_CONFIG error is generated.
* If the reset notification behavior of <share_context> and the
newly created context are different then an EGL_BAD_MATCH error is
generated.
Errors
EGL_BAD_CONFIG is generated if EGL_CONTEXT_OPENGL_ROBUST_ACCESS_-
EXT is set to EGL_TRUE and no GL context supporting the GL_EXT_-
robustness extension and robust access as described therein can be
created.
EGL_BAD_CONFIG is generated if no GL context supporting the
GL_EXT_robustness extension and the specified reset notification
behavior (the value of attribute EGL_CONTEXT_RESET_NOTIFICATION_-
STRATEGY_EXT) can be created.
BAD_MATCH is generated if the reset notification behavior of
<share_context> does not match the reset notification behavior of
the context being created.
New State
None
Conformance Tests
TBD
Sample Code
TBD
Issues
None
Revision History
Rev. Date Author Changes
---- ------------ --------- ----------------------------------------
3 31 Oct 2011 groth Reverted to attribute for robust access. Now it's a
companion to rather than subset of KHR_create_context
2 11 Oct 2011 groth Merged ANGLE and NV extensions.
1 15 July 2011 groth Initial version
extensions/EXT_blend_func_extended.txt deleted 100644 → 0
Name
EXT_blend_func_extended
Name Strings
GL_EXT_blend_func_extended
Contact
Mark Kilgard, NVIDIA Corporation (mjk 'at' nvidia.com)
Contributors
Daniel Koch, NVIDIA
Slawomir Grajewski, Intel
Chris Dalton, NVIDIA
Brian Salomon, Google
From ARB_blend_func_extended...
Graham Sellers, AMD
Mark Young, AMD
Nick Haemel, AMD
Pierre Boudier, AMD
Mais Alnasser, AMD
Jeff Bolz, NVIDIA
Pat Brown, NVIDIA
Ian Stewart, NVIDIA
Jon Leech, Khronos
Status
Draft, almost complete
Version
Last Modified Date: July 29, 2015
Revision: 5
Number
XXX
Dependencies
This extension is written against the OpenGL ES 3.1 (June 4, 2014)
specification, but can apply to earlier versions back to ES 2.0.
GLSL version 300 and 310 language is written against The OpenGL ES
Shading Language (July 11, 2012).
GLSL version 100 language is written against The OpenGL ES Shading
Language (May 12, 2009).
The NV_draw_buffers and EXT_draw_buffers extensions trivially affect
the definition of this extension.
The EXT_draw_buffers_indexed extension affects the definition of
this extension.
Overview
This extension provides an ES version of the ARB_blend_func_extended
functionality.
Traditional OpenGL includes fixed-function blending that combines
source colors with the existing content of a render buffer in
a variety of ways. A number of extensions have enhanced this
functionality by adding further sources of blending weights and
methods to combine them. However, the inputs to the fixed-function
blending units are constrained to a source color (as output from
fragment shading), destination color (as the current content of the
frame buffer) or constants that may be used in their place.
This extension adds new blending functions whereby a fragment
shader may output two colors, one of which is treated as the
source color, and the other used as a blending factor for either
source or destination colors. Furthermore, this extension increases
orthogonality by allowing the SRC_ALPHA_SATURATE function to be used
as the destination weight.
Because of the limitations of the OpenGL ES 2.0 shading language,
new built-in variables (gl_SecondaryFragColorEXT,
gl_SecondaryFragDataEXT) are added to the ES 1.00 shading language
rather than introduce more complex features for user-defined fragment
outputs. Because such built-in variable are deprecated in ES 3.0,
these variables are NOT available in the OpenGL ES 3.xx shading
language verisons.
IP Status
No known IP claims.
New Procedures and Functions
void BindFragDataLocationIndexedEXT(uint program, uint colorNumber,
uint index, const char * name);
int GetFragDataIndexEXT(uint program, const char * name);
void BindFragDataLocationEXT(uint program, uint colorNumber, const char * name)
int GetProgramResourceLocationIndexEXT(uint program, enum programInterface, const char *name);
New Tokens
Accepted by the <src> and <dst> parameters of BlendFunc and
BlendFunciEXT, and by the <srcRGB>, <dstRGB>, <srcAlpha> and <dstAlpha>
parameters of BlendFuncSeparate and BlendFuncSeparateiEXT:
SRC1_COLOR_EXT 0x88F9
SRC1_ALPHA_EXT 0x8589 // OpenGL 1.5 token value
ONE_MINUS_SRC1_COLOR_EXT 0x88FA
ONE_MINUS_SRC1_ALPHA_EXT 0x88FB
SRC_ALPHA_SATURATE_EXT 0x0308
Accepted in the <props> array of GetProgramResourceiv:
LOCATION_INDEX_EXT 0x930F
Accepted by the <pname> parameter of GetBooleanv, GetIntegerv,
and GetFloatv:
MAX_DUAL_SOURCE_DRAW_BUFFERS_EXT 0x88FC
Additions to Chapter 7 of the OpenGL ES 3.1 Specification (Programs and
Shaders)
Add a row to table 7.2 "GetProgramResourceiv properties and supported
interfaces" (page 82):
Property Supported Interfaces
------------------ --------------------
LOCATION_INDEX_EXT PROGRAM_OUTPUT
Modify section 7.3.1.1 "Naming Active Resources" subsection to include
after the LOCATION paragraph (page 84):
"For the property LOCATION_INDEX_EXT, a single integer identifying the
fragment color index of an active fragment shader output variable
is written to params. If the active variable is not an output for a
fragment shader, the value -1 will be written to params."
Modify (page 87) the paragraph introducing GetProgramResourceLocation
to begin:
"The commands
int GetProgramResourceLocation( uint program,
enum programInterface, const char *name );
int GetProgramResourceLocationIndexEXT( uint program,
enum programInterface, const char *name );
return the location or the fragment color index, respectively,
assigned to the variable named name in interface programInterface
of program object program."
Change the ending of the same paragraph to read:
"For GetProgramResourceLocationIndexEXT, programInterface must be
PROGRAM_OUTPUT. The value -1 will be returned by either command if
an error occurs, if name does not identify an active variable on
programInterface, or if name identifies an active variable that
does not have a valid location assigned, as described above. The
locations returned by these commands are the same locations returned
when querying the LOCATION and LOCATION_INDEX resource properties."
Change the next paragaph to begin:
"A string provided to GetProgramResourceLocation or
GetProgramResourceLocationIndexEXT is considered to match an active
variable if ..."
Change the last paragraph of the section (page 88) to read:
... "If the string specifies an element of an array variable,
GetProgramResourceLocation and GetProgramResourceLocationIndexEXT
return the location or fragment color index assigned to that
element. If it specifies the base name of an array, it identifies
the resources associated with the first element of the array."
Additions to Chapter 14 of the OpenGL ES 3.1 Specification (Programmable
Fragment Processing)
Modify section 14.2.3 "Shader Outputs" subsection to include:
"The binding of a user-defined varying out variable to a fragment color number
can be specified explicitly. The command
void BindFragDataLocationIndexedEXT(uint program, uint colorNumber,
uint index, const char * name);
specifies that the varying out variable name in <program> should
be bound to fragment color <colorNumber> when the program is next
linked. <index> may be zero or one to specify that the color
be used as either the first or second color input to the blend
equation, respectively, as described in Section 15.1.5 (Blending).
If <name> was bound previously, its assigned binding is replaced
with colorNumber. <name> must be a null-terminated string. The error
INVALID_VALUE is generated if <colorNumber> is equal or greater
than the value of MAX_DRAW_BUFFERS and <index> is zero,
or if <colorNumber> is equal or greater than the value of
MAX_DUAL_SOURCE_DRAW_BUFFERS_EXT and <index> is greater than or
equal to one. The command
void BindFragDataLocationEXT(uint program, uint colorNumber,
const char * name)
is equivalent to calling BindFragDataLocationIndexedEXT with the
same values for <program>, <colorNumber> and <name>, and with <index>
set to zero.
When a program is linked, any varying out variables without
a binding specified through BindFragDataLocationIndexedEXT or
BindFragDataLocationEXT will automatically be bound to fragment
colors and indices by the GL. All such assignments will use color
indices of zero. Such bindings can be queried using the commands
GetFragDataLocation and GetFragDataIndexEXT. Output binding
assignments will cause LinkProgram to fail:
* if the number of active outputs is greater than the value of
MAX_DRAW_BUFFERS_EXT;
* if the program has an active output assigned to a location greater
than or equal to the value of MAX_DUAL_SOURCE_DRAW_BUFFERS_EXT
and has an active output assigned an index greater than or equal
to one;
* if more than one varying out variable is bound to the same number
and index; or
* if the explicit binding assignments do not leave enough space
for the linker to automatically assign a location for a varying
out array, which requires multiple contiguous locations.
BindFragDataLocationIndexedEXT may be issued before any shader objects
are attached to a program object. Hence it is allowed to bind any
name (except a name starting with gl_) to a color number and index,
including a name that is never used as a varying out variable in
any fragment shader object. Assigned bindings for variables that
do not exist are ignored."
Add to end of section:
"The command
int GetFragDataIndexEXT(uint program, const char * name);
returns the index of the fragment color to which the variable <name>
was bound when the program object <program> was last linked. If
program has not been successfully linked, the error INVALID_OPERATION
is generated. If name is not a varying out variable, or if an error
occurs, -1 will be returned. The command is equivalent to
GetProgramResourceLocationIndex(program, PROGRAM_OUTPUT, name);"
Additions to Chapter 15 of the OpenGL ES 3.1 Specification (Writing
Fragments and Samples to the Framebuffer)
Modify section 15.1.5.2 "Blend Functions":
Change the first paragraph to read:
"The weighting factors used by the blend equation are determined by
the blend functions. There are four possible sources for weighting
factors. These are the constant color (Rc, Gc, Bc, Ac) (see
BlendColor, p. 211), the first source color (Rs0, Gs0, Bs0, As0),
the second source color (Rs1, Gs1, Bs1, As1), and the destination
color (the existing content of the draw buffer). Additionally the
special constants ZERO and ONE are available as weighting factors."
Modify Table 15.2 (RGB and ALPHA source and destination blend
functions ...) as follows
RGB Blend Factors Alpha Blend Factors
Value (Sr, Sg, Sb) or (Dr, Dg, Db) Sa or Da
----- ---------------------------- -------------------
ZERO (0, 0, 0) 0
ONE (1, 1, 1) 1
SRC_COLOR (Rs0, Gs0, Bs0) As0
ONE_MINUS_SRC_COLOR (1, 1, 1) - (Rs0, Gs0, Bs0) 1 - As0
DST_COLOR (Rd, Gd, Bd) Ad
ONE_MINUS_DST_COLOR (1, 1, 1) - (Rd, Gd, Bd) 1 - Ad
SRC_ALPHA (As0, As0, As0) As0
ONE_MINUS_SRC_ALPHA (1, 1, 1) - (As0, As0, As0) 1 - As0
DST_ALPHA (Ad, Ad, Ad) Ad
ONE_MINUS_DST_ALPHA (1, 1, 1) - (Ad, Ad, Ad) 1 - Ad
CONSTANT_COLOR (Rc, Gc, Bc) Ac
ONE_MINUS_CONSTANT_COLOR (1, 1, 1) - (Rc, Gc, Bc) 1 - Ac
CONSTANT_ALPHA (Ac, Ac, Ac) Ac
ONE_MINUS_CONSTANT_ALPHA (1, 1, 1) - (Ac, Ac, Ac) 1 - Ac
SRC_ALPHA_SATURATE (f, f, f) 1 New (for ES 2.x)
SRC1_COLOR_EXT (Rs1, Gs1, Bs1) As1 New
ONE_MINUS_SRC1_COLOR_EXT (1, 1, 1) - (Rs1, Gs1, Bs1) 1 - As1 New
SRC1_ALPHA_EXT (As1, As1, As1) As1 New
ONE_MINUS_SRC1_ALPHA_EXT (1, 1, 1) - (As1, As1, As1) 1 - As1 New
For ES 2.0, remove table's footnote saying (ES 3.x already has this
removed):
SRC_ALPHA_SATURATE is valid only for source RGB and alpha
blending functions.
Add the following subsections to Section 5.1.5 Blending, at the end
of the subsection 15.1.5.2 "Blend Functions":
"15.1.5.X Dual Source Blending and Multiple Draw Buffers
Blend functions that require the second color input, <Rs1, Gs1, Bs1,
As1> (SRC1_COLOR_EXT, SRC1_ALPHA_EXT, ONE_MINUS_SRC1_COLOR_EXT, or
ONE_MINUS_SRC1_ALPHA_EXT) may consume hardware resources that could
otherwise be used for rendering to multiple draw buffers. Therefore,
the number of draw buffers that can be attached to a frame buffer
may be lower when using dual-source blending.
The maximum number of draw buffers that may be attached to a
single frame buffer when using dual-source blending functions is
implementation dependent and can be queried by calling GetIntegerv
with the symbolic constant MAX_DUAL_SOURCE_DRAW_BUFFERS_EXT. When
using dual-source blending, MAX_DUAL_SOURCE_DRAW_BUFFERS_EXT should be
used in place of MAX_DRAW_BUFFERS_EXT to determine the maximum number
of draw buffers that may be attached to a single frame buffer. The
value of MAX_DUAL_SOURCE_DRAW_BUFFERS_EXT must be at least 1. If
the value of MAX_DUAL_SOURCE_DRAW_BUFFERS_EXT is 1, then dual-source
blending and multiple draw buffers cannot be used simultaneously.
If either blend function is set to one of the second source factors
(SRC1_COLOR_EXT, SRC1_ALPHA_EXT, ONE_MINUS_SRC1_COLOR_EXT, or
ONE_MINUS_SRC1_ALPHA_EXT) for any draw buffer and any draw buffers
equal to or greater than the value of MAX_DUAL_SOURCE_DRAW_BUFFERS_EXT
have values other than NONE, the error INVALID_OPERATION is generated
by drawing commands.
15.1.5.Y Generation of Second Color Source for Blending
Rendering using any of the blend functions that consume the second
input color (SRC1_COLOR_EXT, ONE_MINUS_SRC1_COLOR_EXT, SRC1_ALPHA_EXT
or ONE_MINUS_SRC1_ALPHA_EXT) using a shader that does not output
a second source color will produce undefined results. To produce
input for the second source color, a shader must be used that outputs
a second source color.
When using a GLSL version 300 es or higher fragment shader with
dual-source blending functions, the color output varyings are bound
to the first (index 0) and second (index 1) inputs of a draw buffer
using BindFragDataLocationIndexedEXT as described in the "Shader
Outputs" subsection of Section 3.12.2 or by layout qualifiers for
location=/n/ and index=/m/. Data written to the first of these outputs
becomes the first source color input to the blender (corresponding
to SRC_COLOR and SRC_ALPHA). Data written to the second of these
outputs generates the second source color input to the blender
(corresponding to SRC1_COLOR_EXT and SRC1_ALPHA_EXT).
Alternatively if the GLSL version 100 fragment shader is used (where
user-defined color outputs are unsupported, hence a user-defined
color output is not available for BindFragDataLocationIndexEXT), the
gl_FragColor and gl_SecondaryFragColorEXT fragment outputs correspond
to the first and second source color respectively. Similarly the
gl_FragData and gl_SecondaryFragDataEXT fragment output arrays
correspond to the first and second source color respectively of each
color buffer output.
If the second color input to the blender is not written in the
shader, or if no output is bound to the second input of a blender,
the result of the blending operation is not defined.
Other shading languages may define similar methods for producing
the first and second color inputs to blending equations."
Additions to the OpenGL ES Shading Language 1.00 Specification
Including the following line in a shader can be used to control the
language features described in this extension:
#extension GL_EXT_blend_func_extended : <behavior>
where <behavior> is as specified in section 3.4.
A new preprocessor #define is added to the OpenGL ES Shading Language:
#define GL_EXT_blend_func_extended 1
Modify paragraphs in section 7.2 "Fragment Shader Special Variables" as follows:
First paragraph, second sentence:
"Fragment shaders output values to the OpenGL ES pipeline using
the built-in variables gl_FragColor, gl_SecondaryFragColorEXT,
gl_FragData, and gl_SecondaryFragDataEXT, unless the discard keyword
is executed."
Second paragraph, first sentence:
"It is not a requirement for the fragment shader to write to
either gl_FragColor, gl_SecondaryFragColorEXT, gl_FragData, or
gl_SecondaryFragDataEXT."
Add after the fourth paragraph:
"Writing to gl_SecondaryFragColorEXT specifies a second fragment color
that will be used by the subsequent fixed functionality pipeline for
dual source blending. If subsequent fixed functionality consumes the
second fragment color and an execution of a fragment shader does
not write a value to gl_SecondaryFragColorEXT then the secondary
fragment color consumed is undefined."
Add after the fifth paragraph:
"The variable gl_SecondaryFragDataEXT is an array. Writing to
gl_SecondaryFragDataEXT[n] specifies the secondary fragment data that
will be used by the subsequent fixed functionality pipeline for data n
for dual source blending. If subsequent fixed functionality consumes
secondary fragment data and an execution of a fragment shader does
not write a value to it, then the secondary fragment data consumed
is undefined."
Modify the sixth paragraph to read:
"If a shader statically assigns a value to gl_FragColor or
gl_SecondaryFragColorEXT, it may not assign a value to any
element of gl_FragData or gl_SecondaryFragDataEXT. If a shader
statically writes a value to any element of gl_FragData or
gl_SecondaryFragDataEXT, it may not assign a value to gl_FragColor
or gl_SecondaryFragColorEXT. That is, a shader may assign values to
either the set of gl_FragColor and gl_SecondaryFragColorEXT or the
set of gl_FragData and gl_SecondaryFragDataEXT, but not both."
Modify the eighth paragraph to read:
"If a shader executes the discard keyword, the fragment is discarded,
and the values of gl_FragColor, gl_SecondaryFragColorEXT, gl_FragData,
and gl_SecondaryFragDataEXT become irrelevant."
Add these built-in variable to the list "accessible from a fragment shader":
mediump vec4 gl_SecondaryFragColorEXT;
mediump vec4 gl_SecondaryFragDataEXT[gl_MaxDualSourceDrawBuffersEXT];
Add to section 7.4 "Built-In Constants" the following constant:
const mediump int gl_MaxDualSourceDrawBuffersEXT = 1;
Additions to the OpenGL ES Shading Language 3.00 and 3.10 Specification
Including the following line in a shader can be used to control the
language features described in this extension:
#extension GL_EXT_blend_func_extended : <behavior>
where <behavior> is as specified in section 3.4.
A new preprocessor #define is added to the OpenGL ES Shading Language:
#define GL_EXT_blend_func_extended 1
Modify section 4.4.2 "Output Layout Qualifiers":
Change the second paragraph to read:
"Fragment shaders allow output layout qualifiers only on the interface
qualifier out. The layout qualifier identifier for fragment shader
outputs is:
layout-qualifier-id
location = integer-constant
index = integer-constant
Each of these qualifiers may appear at most once. If index is
specified, location must also be specified. If index is not
specified, the value 0 is used."
Add an additional example to the end of the fourth paragraph's example:
"And,
layout(location = 3, index = 1) out vec4 factor;
will establish that the fragment shader output factor is copied out
to fragment color 3 as the second (index one) input to the blend
equation."
Change the first sentence of the second to last paragraph to read:
"If there is more than one fragment output, the location must
be specified for all outputs unless the EXT_blend_func_extended
extension is enabled in which case more than one unassigned fragment
output locations are allowed though they must be assigned to unique
locations assigned with glBindFragDataLocationIndexedEXT prior to
linking."
Add to section 7.4 "Built-In Constants" the following constant:
const mediump int gl_MaxDualSourceDrawBuffersEXT = 1;
Dependencies on OpenGL ES 3.0
If OpenGL ES 3.0 or higher is not supported (meaning OpenGL ES 2.0
support only), remove all references to the functions:
BindFragDataLocationIndexedEXT
GetFragDataIndexEXT
BindFragDataLocationEXT
GetProgramResourceLocationIndexEXT
Also ignore the additions to chapters 7 and 14 and the paragraph in
section 15.1.5.Y related to GLSL version 300 es or higher.
When OpenGL ES 3.0 or higher, the "Additions to the OpenGL ES
Shading Language 1.00 Specification" applies to the version 100
shading language, but not later versions.
Dependencies on OpenGL ES 3.1
If OpenGL ES 3.1 or higher is not supported (meaning OpenGL ES 3.0
or earlier), remove all references to the function
GetProgramResourceLocationIndexEXT
because program resource queries are added by ES 3.1.
Also ignore the additions to chapter 7.
Dependencies on EXT_draw_buffers or NV_draw_buffers
Using dual-source blending functions may consume additional outputs
from hardware shading units and therefore can reduce the number
of draw buffers that may be attached to a single frame buffer when
dual-source blending functions are enabled. In this case, the value
of MAX_DUAL_SOURCE_DRAW_BUFFERS_EXT may be less than the value of
MAX_DRAW_BUFFERS_EXT. If EXT_draw_buffers or NV_draw_buffers is not
supported then the value of MAX_DUAL_SOURCE_DRAW_BUFFERS_EXT must
be 1. Furthermore, the discussion in the subsection entitled "Dual
Source Blending and Multiple Draw Buffers" may be discarded.
Dependencies on EXT_draw_buffers_indexed
If EXT_draw_buffers_indexed is not supported, all references to
BlendFunciEXT and BlendFuncSeparateiEXT should be removed. In this
case, the blend functions for all attached draw buffers will be the
same.
Errors
The error INVALID_OPERATION is generated by Begin or any
procedure that implicitly calls Begin if any draw buffer has a
blend function requiring the second color input (SRC1_COLOR_EXT,
ONE_MINUS_SRC1_COLOR_EXT, SRC1_ALPHA_EXT or ONE_MINUS_SRC1_ALPHA_EXT),
and a framebuffer is bound that has more than the value of
MAX_DUAL_SOURCE_DRAW_BUFFERS_EXT-1 active color attachments.
New State
None
While no changes to table 20.12 (Pixel Operations) are strictly
necessary, new enumerations are supported for the BLEND_SRC_RGB,
BLEND_SRC_ALPHA, BLEND_DST_RGB, and BLEND_DST_ALPHA state to support
SRC1_COLOR_EXT, SRC1_ALPHA_EXT, ONE_MINUS_SRC1_COLOR_EXT, and
ONE_MINUS_SRC1_ALPHA_EXT (and for ES 2.0, SRC_ALPHA_SATURATE_EXT).
New Implementation Dependent State
Get Value Type Get Command Minimum Value Description Sec.
--------- ---- ----------- ------------- ------------------- ------
MAX_DUAL_SOURCE_DRAW_BUFFERS_EXT Z+ GetIntegerv 1 Maximum number of 15.1.5
active draw buffers
when using dual-source
blending
Example Use Cases
There are several potential uses for this functionality. A first
example is in the implementation of sub-pixel accurate font rendering
algorithms. Given a known layout of pixel elements (red, green
and blue components), coverage may be calculated independently for
each element and passed to the blender in the second source color
as a per-channel opacity. To use this mode, use the following blend
functions:
glBlendFunc(GL_SRC1_COLOR_EXT, GL_ONE_MINUS_SRC1_COLOR_EXT);
As a second example, consider a partially reflective colored glass
window. It will attenuate light passing through it, and reflect
some of the light that strikes it. Using an appropriate combination
of functions, this effect may be simulated in a single pass using
only fixed-function blending hardware. In this case, the following
blend functions may be used:
glBlendFunc(GL_SRC_ALPHA, GL_SRC1_COLOR_EXT);
Issues
0. What should this extension be named?
RESOLVED: EXT_blend_func_extended, matching the name of
ARB_blend_func_extended upon which this extension is based but
providing a multi-vendor extension for ES implementations.
1. Is this extension compatible with the ARB_blend_func_extended
version?
RESOLVED: Yes. This extension is 100% functionally identical to
ARB_blend_func_extended but for the ES 2.x and 3.x APIs.
The token values are _EXT suffixed but have the same values as
the ARB_blend_func_extended tokens.
Philosophically if this extension is going for 100% parity and
functionality with ARB_blend_func_extended, it should simply add
all the stuff in ARB_blend_func_extended...
2. Should the next commands be EXT suffixed?
RESOLVED: Yes. This is not an OES extension.
This means source code coming from a desktop environment should
call eglGetProcAddress on function names with the EXT suffix.
However because extension functions are called through function
pointers, this is only a minor change isolated to function pointer
initialization.
2. Should this extension allow ES 2.0 contexts to use
GL_SRC_ALPHA_SATURATE for the destination blend function?
RESOLVED: Yes, the ARB_blend_func_extended extension adds support
for using GL_SRC_ALPHA_SATURATE as the destination factor as "bonus"
functionality.
ES 3.x already allows GL_SRC_ALPHA_SATURATE for the destination
factor so this additional functionality is new only to ES 2.0 contexts
supporting this extension.
We expect no GPU hardware capable of dual-source blending to not
also support GL_SRC_ALPHA_SATURATE as the destination factor.
3. Should this extension provide the glBindFragDataLocation and
glBindFragDataLocationIndexed functionality?
RESOLVED: Yes. With EXT suffixes.
4. Should this really be OES_blend_func_extended?
RESOLVED: Go with EXT is for expediency.
Additionally this extension supports functionality such
GL_SRC_ALPHA_SATURATE that all desktop GPU hardware is assumed to
have. ES-only vendors might not want this in an OES extension.
The same could be said for the glBindFragDataLocation* functionality.
5. Does this extension need an interaction with
OES_blend_equation_separate?
RESOLVED: No, that's an ES 1.1 extension. ES 2.0 and on all support
separate blend functions.
6. Are there any OpenGL ES Shading Language interactions?
RESOLVED: Yes, to use this extension, a #extension line will be needed
in the shader requesting the EXT_blend_func_extended functionality.
Example:
#extension GL_EXT_blend_func_extended : require
The ARB_blend_func_extended functionality does NOT require a special
#extension line to use its functionality because the ARB version
relies on existing GLSL functionality that allows for multiple
fragment outputs as part of supporting multiple render targets.
In the ARB version, then glBindFragDataLocationIndexed can bind
these unassigned locations to different source output colors.
But GLSL OpenGL ES 3.00 and 3.10 both explicitly preclude more than
one fragment shader output with an unassigned location. Hence a
#extension is needed to relax this error condition. And then this
extension's glBindFragDataLocationIndexedEXT must be used to assign
locations as necessary.
7. Can the indexed location be assigned explicitly in the shader?
RESOLVED: Yes, for ES 3.x shaders where the GLSL ES 3.x supports
layout qualifiers. ES 2.0 does not support the layout qualifier or
user-defined fragment outputs.
8. Should both the layout qualifier mechanism and the
glBindFragDataLocationIndexed-style API for specifying the index of
a user-defined fragment shader output be supported?
RESOLVED: Yes, both should be supported. This makes it easier
for existing applications to port to ES 3.0 as both mechanisms are
available.
FYI: The "layout(location=0,index=1)" type syntax for dual-source
blending was introduced to OpenGL in GLSL 3.30 and 4.00 in
conjunction with OpenGL 3.3 and 4.0 respectively. The original
ARB_blend_func_extended was written with respect to OpenGL 3.2 and
intended to support dual-source blending without the need to extend
the GLSL language by instead supporting assignment if the fragment
output index via glBindFragDataLocationIndexed.
9. How to support OpenGL ES 2.0 where user-defined fragment shader
outputs are not supported?
RESOLVED: Introduce new gl_SecondaryFragColorEXT and
gl_SecondaryFragDataEXT built-in variables for specifying the second
source color.
These built-ins are only available in the ES 1.00 shader language
version.
It is important to provide an ES 2.0 mechanism because WebGL 1.0 is
based on ES 2.0. Chrome's internal command buffer mechanism is also
based around ES 2.0 and Skia intends to use this extension.
This includes adding a gl_MaxDualSourceDrawBuffersEXT
implementation-dependent constant.
10. Does the version 100 syntax (gl_SecondaryFragColorEXT,
gl_SecondaryFragDataEXT) work in an ES 3.0 context?
RESOLVED: Yes. For compatibility reasons, an ES 3.0 context
advertising EXT_blend_func_extended must support the built-ins for
the fragment shader secondary color outputs.
11. How many elements should be in the gl_SecondaryFragDataEXT array?
RESOLVED: The gl_SecondaryFragDataEXT array should have as
many elements as the GLSL built-in implementation constant
gl_MaxDualSourceDrawBuffersEXT which should be the value of the
context's GL_MAX_DUAL_SOURCE_DRAW_BUFFERS_EXT implementation-dependent
constant.
This means the number of elements in gl_SecondaryFragDataEXT is
different than the number of gl_FragData elements.
12. What precision should the gl_SecondaryFragColorEXT and
gl_SecondaryFragDataEXT be?
RESOLVED: mediump. This is consistent with gl_FragColor and
gl_FragData.
13. Should gl_MaxDualSourceDrawBuffersEXT be exposed in both ES 2.0
(where it sizes the gl_SecondaryFragDataEXT array) and also 3.x
contexts (where there is no fixed-function array)?
RESOLVED: Implementation-wise, it is easiest to expose this
implementation-dependent constant for all ES contexts.
As a practical matter, we don't expect any implementations will
advertise any value other than 1 for this constant.
Note: There is no implementation-dependent GLSL constant comparable
to gl_MaxDualSourceDrawBuffersEXT in ARB_blend_func_extended
(or OpenGL 3.3/4.0 introducing the ARB_blend_func_extended
functionality).
14. Any more issues?
RESOLVED: See the issues in the ARB_blend_func_extended
specification. This extension resolves those issues to match the
ARB extension version.
Revision History
Rev. Date Author Changes
---- -------- --------- -----------------------------------------
1 05/22/15 mjk Initial revision.
2 07/06/15 mjk Proper ES 2.0 interactions; complete.
3 07/08/15 mjk Feedback from Brian
4 07/08/15 mjk Feedback from Daniel
5 07/29/15 mjk ES 3.x contexts (as well as 2.0) expose
gl_MaxDualSourceDrawBuffersEXT
extensions/EXT_blend_minmax.txt deleted 100644 → 0
Name
EXT_blend_minmax
Name Strings
GL_EXT_blend_minmax
Version
Last Modified Date: September 17, 2009
Version: 1.5
Number
OpenGL Extension #37
OpenGL ES Extension #65
Dependencies
There is an interaction with OpenGL ES.
Overview
Blending capability is extended by respecifying the entire blend
equation. While this document defines only two new equations, the
BlendEquationEXT procedure that it defines will be used by subsequent
extensions to define additional blending equations.
The two new equations defined by this extension produce the minimum
(or maximum) color components of the source and destination colors.
Taking the maximum is useful for applications such as maximum projection
in medical imaging.
Issues
* I've prefixed the ADD token with FUNC, to indicate that the blend
equation includes the parameters specified by BlendFunc. (The min
and max equations don't.) Is this necessary? Is it too ugly?
Is there a better way to accomplish the same thing?
New Procedures and Functions
void BlendEquationEXT(enum mode);
New Tokens
Accepted by the <mode> parameter of BlendEquationEXT:
FUNC_ADD_EXT 0x8006
MIN_EXT 0x8007
MAX_EXT 0x8008
Accepted by the <pname> parameter of GetBooleanv, GetIntegerv,
GetFloatv, and GetDoublev:
BLEND_EQUATION_EXT 0x8009
Additions to Chapter 2 of the GL Specification (OpenGL Operation)
None
Additions to Chapter 3 of the GL Specification (Rasterization)
None
Additions to Chapter 4 of the GL Specification (Per-Fragment Operations
and the Framebuffer)
The GL Specification defines a single blending equation. This
extension introduces a blend equation mode that is specified by calling
BlendEquationEXT with one of three enumerated values. The default
value FUNC_ADD_EXT specifies that the blending equation defined in
the GL Specification be used. This equation is
C' = (Cs * S) + (Cd * D)
/ 1.0 C' > 1.0
C = (
\ C' C' <= 1.0
where Cs and Cd are the source and destination colors, and S and D are
as specified by BlendFunc.
If BlendEquationEXT is called with <mode> set to MIN_EXT, the
blending equation becomes
C = min (Cs, Cd)
Finally, if BlendEquationEXT is called with <mode> set to MAX_EXT, the
blending equation becomes
C = max (Cs, Cd)
In all cases the blending equation is evaluated separately for each
color component.
Additions to Chapter 5 of the GL Specification (Special Functions)
None
Additions to Chapter 6 of the GL Specification (State and State Requests)
None
Additions to the GLX Specification
None
GLX Protocol
A new GL rendering command is added. The following command is sent to the
server as part of a glXRender request:
BlendEquationEXT
2 8 rendering command length
2 4097 rendering command opcode
4 ENUM mode
Dependencies on OpenGL ES
If the GL is OpenGL ES, only the new MIN_EXT and MAX_EXT blend equations
are introduced by this extension. BlendEquationOES, FUNC_ADD_OES, and
BLEND_EQUATION_OES are introduced by the OES_blend_subtract extension,
which is required for this extension to operate. Alternatively,
OpenGL ES 2.0 is required, which introduces BlendEquation, FUNC_ADD, and
BLEND_EQUATION without the suffixes.
MIN_EXT and MAX_EXT should be added to Table 4.blendeq described in the
OES_blend_subtract extension specification, and Table 4.1 of the OpenGL
ES 2.0 specification.
Mentions of GetDoublev, Begin/End, and GLX in this extension specification
can be ignored for OpenGL ES. Also, BlendEquationEXT and FUNC_ADD_EXT
instead have the OES suffix courtesy of OES_blend_subtract, or no suffix
courtesy of core OpenGL ES 2.0.
Errors
INVALID_ENUM is generated by BlendEquationEXT if its single parameter
is not FUNC_ADD_EXT, MIN_EXT, or MAX_EXT.
INVALID_OPERATION is generated if BlendEquationEXT is executed between
the execution of Begin and the corresponding execution to End.
New State
Get Value Get Command Type Initial Value Attribute
--------- ----------- ---- ------------- ---------
BLEND_EQUATION_EXT GetIntegerv Z3 FUNC_ADD_EXT color-buffer
New Implementation Dependent State
None
Revision History
Version 1.5, September 17, 2009 (Jon Leech) -
Merge into OpenGL Registry version of the extension and assign
OpenGL ES extension number.
Version 1.4, May 19, 2009 (Benj Lipchak) -
Adapted for OpenGL ES.
Version 1.3, May 31, 1995 -
Last SGI revision.
extensions/EXT_color_buffer_float.txt deleted 100644 → 0
Name
EXT_color_buffer_float
Name Strings
GL_EXT_color_buffer_float
Contributors
OpenGL ES Working Group members
Contact
Mark Callow, HI Corp. (callow.mark 'at' artspark.co.jp)
Notice
©2012 The Khronos Group Inc.
Status
Complete
IP Status
Graphics Properties Holdings (GPH, formerly SGI) owns US Patent
#6,650,327, issued November 18, 2003. GPH believes this patent
contains necessary IP for graphics systems implementing floating
point (FP) rasterization and FP framebuffer capabilities.
GPH will not grant Khronos royalty-free use of this IP for use
in OpenGL ES, but will discuss licensing on RAND terms, on an
individual basis with companies wishing to use this IP in the
context of conformant OpenGL ES implementations. GPH does not
plan to make any special exemption for open source
implementations.
See
https://www.khronos.org/files/ip-disclosures/opengl/SGI%20IP%20Disclosure%20Mar05_clean.pdf
for the full disclosure.
Version
Date: January 11th, 2013
Revision: 5
Number
OpenGL ES Extension #137
Dependencies
Requires OpenGL ES 3.0.
Written based on the wording of the OpenGL ES 3.0.1 Specification
(January 10th, 2013).
Overview
This extension allows a variety of floating point formats to be
rendered to via framebuffer objects.
New Procedures and Functions
None
New Tokens
None
Additions to Chapter 3 of the OpenGL ES 3.0 Specification
(Rasterization)
3.8.3 Texture Image Specification, unnumbered subsection "Required
Texture Formats", p. 126
Change the first two bullet items to the following:
- Texture and renderbuffer color formats (see section 4.4.2).
- RGBA32F, RGBA32I, RGBA32UI, RGBA16F, RGBA16I, RGBA16UI,
RGBA8, RGBA8I, RGBA8UI, SRGB8_ALPHA8, RGB10_A2, RGB10_-
A2UI, RGBA4, and RGB5_A1.
- RGB8 and RGB565.
- R11F G11F B10F.
- RG32F, RG32I, RG32UI, RG16F, RG16I, RG16UI, RG8, RG8I, and
RG8UI.
- R32F, R32I, R32UI, R16F, R16I, R16UI, R8, R8I, and R8UI.
- Texture-only color formats:
- RGBA8_SNORM.
- RGB32F, RGB32I, and RGB32UI.
- RGB16F, RGB16I, and RGB16UI.
- RGB8_SNORM, RGB8I, RGB8UI, and SRGB8.
- RGB9_E5.
- RG8_SNORM.
- R8_SNORM.
Table 3.12, p. 128 & 129
Convert the dash under 'Color-renderable' to a 'check' for the
following internal formats: R16F, RG16F, RGBA16F, R32F, RG32F,
RGBA32F and R11F_G11F_B10F.
Additions to Chapter 4 of the OpenGL ES 3.0 Specification (Per-Fragment
Operations and the Framebuffer)
(changed lines marked with *; added lines marked with +)
Chapter 4 Introduction, p. 167
Paragraph 5, sentence 3, p 168, insert "floating point" as shown:
"R, G, B, and A components may be represented as unsigned
* normalized fixed-point, floating point or signed or unsigned
integer values; ..." ^^^^^^^^^^^^^^
4.1.7 Blending, p. 174
Modify paragraphs 3 & 4:
* "If the color buffer is fixed-point, the components of the
source and destination values and blend factors are clamped
* to [0; 1] prior to evaluating the blend equation. If the color
+ buffer is floating-point, no clamping occurs. The resulting four
+ values are sent to the next operation.
Blending applies only if the color buffer has a fixed-point or
* or floating-point format. If the color buffer has an integer
* format, proceed to the next operation. Furthermore, an
+ INVALID_OPERATION error is generated by DrawArrays and the other
+ drawing commands defined in section 2.8.3 if blending is enabled
+ (see below) and any draw buffer has a 32-bit floating-point
+ format."
4.2.3 Clearing the Buffers, p. 183
Modify second paragraph, inserting "floating point":
" void ClearColor(float r, float g, float b, float a);
* sets the clear value for fixed- and floating-point color buffers.
..." ^^^^^^^^^^^^^^^^^^
4.3.1 Reading Pixels, p. 186
In paragraph 4, beginning "Only two combinations of format
and type are accepted ...", after the sentence ending "... type
UNSIGNED_BYTE is accepted." insert the following sentence:
"For floating-point rendering surfaces, the combination
format RGBA and type FLOAT is accepted."
4.3.1 unnumbered subsection "Obtaining Pixels from the Framebuffer",
p. 188
Modify penultimate paragraph, p189, "If format is an integer ..."
"If format is an integer format and the color buffer is not an
integer format; if the color buffer is an integer format and
* format is not an integer format; if format is an integer format
* and type is FLOAT, HALF_FLOAT, or UNSIGNED_INT_10F_11F_11F_REV;
+ or if the color buffer is a floating-point format and type is
+ not FLOAT, HALF FLOAT, or UNSIGNED_INT_10F_11F_11F_REV, the error
INVALID_OPERATION occurs."
4.3.1 unnumbered subsection "Conversion of RGBA values", p.190
Sole paragraph, sentence 3, insert "or floating point" as shown:
* "For an integer or floating point color buffer, the elements
are unmodified."^^^^^^^^^^^^^^^^^
4.3.2 Copying Pixels, p192
Modify first error condition, at bottom of p193, "The read buffer
contains ..." to encompass floating-point buffers.
* "- The read buffer contains fixed-point or floating-point values
* and any draw buffer contains neither fixed-point nor
* floating-point values."
4.4.2 Attaching Images to Framebuffer Objects, p. 197, unnumbered
subsection "Required Renderbuffer Formats", p. 200
In the last paragraph beginning "Implementations must support
creation ...", modify the final phrase to
* "with the exception of signed and unsigned integer, RGBA16F,
+ R32F, RG32F and RGBA32F formats.
Additions to Chapter 5 of the OpenGL ES 2.0 Specification (Special Functions)
None
Additions to Chapter 6 of the OpenGL ES 2.0 Specification (State and State
Requests)
6.1.15 Internal Format Queries, p. 237
P. 238, paragraph 8 after "Since multisampling is not supported
for signed and unsigned integer internal formats, the value of
NUM_SAMPLE_COUNTS will be zero for such formats.", insert new
one-sentence paragraph:
"If <internalformat> is RGBA16F, R32F, RG32F, or RGBA32F, the
value of NUM_SAMPLE_COUNTS may be zero, or else the maximum
value in SAMPLES may be less than the value of MAX_SAMPLES."
New Implementation Dependent State
None
Issues
Revision History
Rev. Date Author Changes
---- -------- --------- -----------------------------------------
1 10/16/12 markc Initial version
2 10/18/12 markc Referenced preliminary version of OpenGL
ES 3.0.1 specification and updated page
numbers.
3 11/21/12 markc Corrected IP status.
4 01/09/13 markc Changed date of referenced OpenGL ES
3.0.1 specification. Made minor language
simplification.
5 01/11/13 markc Changed date to release version of
OpenGL ES 3.0.1 specification.
Clarified change to "Required
renderbuffer formats" section.
# vim:ai:ts=4:sts=4:sw=4:expandtab:textwidth=70
extensions/EXT_draw_buffers.txt deleted 100644 → 0
Name
EXT_draw_buffers
Name Strings
GL_EXT_draw_buffers
Contributors
Contributors to GL_NV_draw_buffers
Contributors to GL_NV_fbo_color_attachments
Contributors to the OpenGL ES 2.0 specification
Contributors to the OpenGLSL ES 1.0.17 specification
Contributors to the OpenGL ES 3.0 specification
Nicolas Capens, TransGaming Inc.
Daniel Koch, TransGaming Inc.
Alastair Patrick, Google Inc.
Kenneth Russell, Google Inc.
Greg Roth, NVIDIA Corporation
Ben Bowman, Imagination Technologies
Members of the WebGL and OpenGL ES working groups
Contact
Daniel Koch (daniel 'at' transgaming.com)
Status
Draft Complete
Version
Last Modified Date: January 30, 2013
Revision: #7
Number
TBD
Dependencies
OpenGL ES 2.0 is required.
The extension is written against the OpenGL ES 2.0 specification.
ANGLE_framebuffer_blit affects the definition of this extension.
APPLE_framebuffer_multisample affects the definitin of this extension.
Overview
This extension increases the number of available framebuffer object
color attachment points, extends OpenGL ES 2.0 to allow multiple output
colors, and provides a mechanism for directing those outputs to
multiple color buffers.
This extension is similar to the combination of the GL_NV_draw_buffers
and GL_NV_fbo_color_attachments extensions, but imposes certain
restrictions informed by the OpenGL ES 3.0 API.
New Procedures and Functions
void DrawBuffersEXT(sizei n, const enum *bufs);
New Tokens
Accepted by the <pname> parameter of GetIntegerv:
MAX_COLOR_ATTACHMENTS_EXT 0x8CDF
Accepted by the <pname> parameters of GetIntegerv and GetFloatv:
MAX_DRAW_BUFFERS_EXT 0x8824
DRAW_BUFFER0_EXT 0x8825
DRAW_BUFFER1_EXT 0x8826
DRAW_BUFFER2_EXT 0x8827
DRAW_BUFFER3_EXT 0x8828
DRAW_BUFFER4_EXT 0x8829
DRAW_BUFFER5_EXT 0x882A
DRAW_BUFFER6_EXT 0x882B
DRAW_BUFFER7_EXT 0x882C
DRAW_BUFFER8_EXT 0x882D
DRAW_BUFFER9_EXT 0x882E
DRAW_BUFFER10_EXT 0x882F
DRAW_BUFFER11_EXT 0x8830
DRAW_BUFFER12_EXT 0x8831
DRAW_BUFFER13_EXT 0x8832
DRAW_BUFFER14_EXT 0x8833
DRAW_BUFFER15_EXT 0x8834
Accepted by the <attachment> parameter of FramebufferRenderbuffer,
FramebufferTexture2D and GetFramebufferAttachmentParameteriv, and by
the <bufs> parameter of DrawBuffersEXT:
COLOR_ATTACHMENT0_EXT 0x8CE0
COLOR_ATTACHMENT1_EXT 0x8CE1
COLOR_ATTACHMENT2_EXT 0x8CE2
COLOR_ATTACHMENT3_EXT 0x8CE3
COLOR_ATTACHMENT4_EXT 0x8CE4
COLOR_ATTACHMENT5_EXT 0x8CE5
COLOR_ATTACHMENT6_EXT 0x8CE6
COLOR_ATTACHMENT7_EXT 0x8CE7
COLOR_ATTACHMENT8_EXT 0x8CE8
COLOR_ATTACHMENT9_EXT 0x8CE9
COLOR_ATTACHMENT10_EXT 0x8CEA
COLOR_ATTACHMENT11_EXT 0x8CEB
COLOR_ATTACHMENT12_EXT 0x8CEC
COLOR_ATTACHMENT13_EXT 0x8CED
COLOR_ATTACHMENT14_EXT 0x8CEE
COLOR_ATTACHMENT15_EXT 0x8CEF
The COLOR_ATTACHMENT0_EXT constant is equal to the
COLOR_ATTACHMENT0 constant.
Each COLOR_ATTACHMENT<i>_EXT adheres to COLOR_ATTACHMENT<i>_EXT
= COLOR_ATTACHMENT0_EXT + <i>.
Changes to Chapter 3 of the OpenGL ES 2.0 Specification (Rasterization)
Section 3.2, (Multisampling). Replace the second paragraph:
An additional buffer, called the multisample buffer, is added to the
window system-provided framebuffer. Pixel sample values, including
color, depth, and stencil values, are stored in this buffer. Samples
contain separate color values for each fragment color. When the
window system-provided framebuffer includes a multisample buffer, it
does not include depth or stencil buffers, even if the multisample
buffer does not store depth or stencil values. Color buffers do
coexist with the multisample buffer, however.
Section 3.8.2, (Shader Execution) Replace subsection "Shader
Outputs":
The OpenGL ES Shading Language specification describes the values
that may be output by a fragment shader. These are gl_FragColor and
gl_FragData[n]. The final fragment color values or the final
fragment data values written by a fragment shader are clamped to the
range [0, 1] and then converted to fixed-point as described in
section 2.1.2 for framebuffer color components.
Writing to gl_FragColor specifies the fragment color (color number
zero) that will be used by subsequent stages of the pipeline.
Writing to gl_FragData[n] specifies the value of fragment color
number n. Any colors, or color components, associated with a
fragment that are not written by the fragment shader are undefined.
A fragment shader may not statically assign values to both
gl_FragColor and gl_FragData. In this case, a compile or link error
will result. A shader statically assigns a value to a variable if,
after preprocessing, it contains a statement that would write to the
variable, whether or not run-time flow of control will cause that
statement to be executed.
Changes to Chapter 4 of the OpenGL ES 2.0 Specification (Per-Fragment
Operations and the Frame Buffer)
Modify the overview of Chapter 4 and replace the sentences
of the fifth paragraph which read:
"The name of the color buffer of an application-created framebuffer
object is COLOR_ATTACHMENT0. The names of the depth and stencil buffers
are DEPTH_ATTACHMENT and STENCIL_ATTACHMENT."
With the following:
"A framebuffer object has an array of color buffer attachment points,
numbered zero through <n>, a depth buffer attachment point, and a
stencil buffer attachment point."
Insert Table 4.3 to Section 4.2.1 (and renumber subsequent tables):
Symbolic Constant Meaning
----------------- ---------------------
NONE No buffer
COLOR_ATTACHMENT<i>_EXT (see caption) Output fragment color to image
attached at color attachment
point i
Table 4.3: Arguments to DrawBuffersEXT when the context is bound to a
framebuffer object, and the buffers they indicate. <i> in
COLOR_ATTACHMENT<i>_EXT may range from zero to the value of
MAX_COLOR_ATTACHMENTS_EXT minus one.
Replace Section 4.2.1, "Selecting a Buffer for Writing" with the following:
"By default, color values are written into the front buffer for
single buffered surfaces or into the back buffer for back buffered
surfaces as determined when making the context current. To control
the color buffer into which each of the fragment color values is
written, DrawBuffersEXT is used.
The command
void DrawBuffersEXT(sizei n, const enum *bufs);
defines the draw buffers to which all fragment colors are written.
<n> specifies the number of buffers in <bufs>. <bufs> is a pointer
to an array of symbolic constants specifying the buffer to which
each fragment color is written.
Each buffer listed in <bufs> must be BACK, NONE, or one of the
values from table 4.3. Further, acceptable values for the constants
in <bufs> depend on whether the GL is using the default framebuffer
(i.e., DRAW_FRAMEBUFFER_BINDING is zero), or a framebuffer object
(i.e., DRAW_FRAMEBUFFER_BINDING is non-zero). For more information
about framebuffer objects, see section 4.4.
If the GL is bound to the default framebuffer, then <n> must be 1
and the constant must be BACK or NONE. When draw buffer zero is
BACK, color values are written into the sole buffer for single-
buffered contexts, or into the back buffer for double-buffered
contexts. If DrawBuffersEXT is supplied with a constant other than
BACK and NONE, the error INVALID_OPERATION is generated.
If the GL is bound to a draw framebuffer object, then each of the
constants must be one of the values listed in table 4.3.
In both cases, the draw buffers being defined correspond in order to
the respective fragment colors. The draw buffer for fragment
colors beyond <n> is set to NONE.
The maximum number of draw buffers is implementation-dependent. The
number of draw buffers supported can be queried by calling
GetIntegerv with the symbolic constant MAX_DRAW_BUFFERS_EXT. An
INVALID_VALUE error is generated if <n> is greater than
MAX_DRAW_BUFFERS_EXT.
If the GL is bound to a draw framebuffer object, the <i>th buffer listed
in <bufs> must be COLOR_ATTACHMENT<i>_EXT or NONE. Specifying a
buffer out of order, BACK, or COLOR_ATTACHMENT<m>_EXT where <m> is
greater than or equal to the value of MAX_COLOR_ATTACHMENTS_EXT,
will generate the error INVALID_OPERATION.
If a fragment shader writes to "gl_FragColor", DrawBuffersEXT
specifies the set of draw buffers into which the color
written to "gl_FragColor" is written. If a fragment shader writes to
"gl_FragData", DrawBuffersEXT specifies a set of draw buffers
into which each of the multiple output colors defined by these
variables are separately written. If a fragment shader writes to
neither "gl_FragColor" nor "gl_FragData" the values of the
fragment colors following shader execution are undefined, and may
differ for each fragment color.
Indicating a buffer or buffers using DrawBuffersEXT causes
subsequent pixel color value writes to affect the indicated
buffers. If the GL is bound to a draw framebuffer object and a draw
buffer selects an attachment that has no image attached, then that
fragment color is not written.
Specifying NONE as the draw buffer for a fragment color will inhibit
that fragment color from being written.
The state required to handle color buffer selection for each
framebuffer is an integer for each supported fragment color. For the
default framebuffer, in the initial state the draw buffer for
fragment color zero is BACK if there is a default framebuffer
associated with the context, otherwise NONE. For framebuffer
objects, in the initial state the draw buffer for fragment color
zero is COLOR_ATTACHMENT0_EXT.
For both the default framebuffer and framebuffer objects, the
initial state of draw buffers for fragment colors other than zero is
NONE.
The value of the draw buffer selected for fragment color <i> can be
queried by calling GetIntegerv with the symbolic constant
DRAW_BUFFER<i>_EXT."
Modify Section 4.2.3 (Clearing the Buffers) and replace the first
two paragraphs with the following:
"The GL provides a means for setting portions of every pixel in a
particular buffer to the same value. The argument to
void Clear(bitfield buf);
is the bitwise OR of a number of values indicating which buffers are
to be cleared. The values are COLOR_BUFFER_BIT, DEPTH_BUFFER_BIT, and
STENCIL_BUFFER_BIT, indicating the buffers currently enabled for color
writing, the depth buffer, and the stencil buffer (see below),
respectively. The value to which each buffer is cleared depends on
the setting of the clear value for that buffer. If the mask is not a
bitwise OR of the specified values, then the error INVALID_VALUE is
generated.
void ClearColor(clampf r, clampf, g, clampf b, clampf a);
sets the clear value for fixed-point color buffers. Each of the
specified components is clamped to [0, 1] and converted to fixed-point
as described in section 2.1.2 for framebuffer color components."
Replace the second paragraph of Section 4.4.1 (Binding and Managing
Framebuffer Objects) with the following:
"The namespace for framebuffer objects is the unsigned integers, with
zero reserved by OpenGL ES to refer to the default framebuffer. A
framebuffer object is created by binding an unused name to the
target FRAMEBUFFER, DRAW_FRAMEBUFFER, or READ_FRAMEBUFFER. The binding
is effected by calling
void BindFramebuffer(enum target, uint framebuffer);
with <target> set the desired framebuffer target and <framebuffer> set
to the unused name. The resulting framebuffer object is a new state
vector. There is a number of color attachment points, plus one each
for the depth and stencil attachment points. The number of color attachment
points is equal to the value of MAX_COLOR_ATTACHMENTS_EXT."
Replace the third item in the bulleted list in Section 4.4.1 (Binding
and Managing Framebuffer Objects) with the following:
" * The only color buffer bitplanes are the ones defined by the
framebuffer attachments points named COLOR_ATTACHMENT0_EXT through
COLOR_ATTACHMENT<n>_EXT."
Modify Section 4.4.3 (Renderbuffer Objects) in the
"Attaching Renderbuffer Images to a Framebuffer" subsection as follows:
Insert the following table:
Name of attachment
---------------------------------------
COLOR_ATTACHMENT<i>_EXT (see caption)
DEPTH_ATTACHMENT
STENCIL_ATTACHMENT
Table 4.x: Framebuffer attachment points. <i> in COLOR_ATTACHMENT<i>_EXT
may range from zero to the value of MAX_COLOR_ATTACHMENTS_EXT minus 1.
Modify the third sentence of the paragraph following the definition of
FramebufferRenderbuffer to be as follows:
"<attachment> should be set to one of the attachment points of the
framebuffer listed in Table 4.x."
Modify Section 4.4.3 (Renderbuffer Objects) in the "Attaching Texture
Images to a Framebuffer" subsection as follows:
Modify the last sentence of the paragraph following the definition of
FramebufferTexture2D to be as follows:
"<attachment> must be one of the attachment points of the framebuffer
listed in Table 4.x."
Modify Section 4.4.5 (Framebuffer Completeness) and replace the 3rd
item in the bulleted list in the "Framebuffer Attachment Completeness"
subsection with the following:
" * If <attachment> is COLOR_ATTACHMENT<i>_EXT, then <image> must
have a color-renderable internal format."
Changes to Chapter 6 of the OpenGL ES 2.0 Specification (State and
State Requests)
In section 6.1.3 (Enumerated Queries) modify the third sentence in
the definition of GetFramebufferAttachmentParameteriv to be as follows:
"<attachment> must be one of the attachment points of the framebuffer
listed in Table 4.x."
Changes to Chapter 3 of the OpenGL ES Shading Language 1.0.17 Specification (Basics)
Add a new section:
3.4.1 GL_EXT_draw_buffers Extension
To use the GL_EXT_draw_buffers extension in a shader it
must be enabled using the #extension directive.
The shading language preprocessor #define
GL_EXT_draw_buffers will be defined to 1, if the
GL_EXT_draw_buffers extension is supported.
Dependencies on ANGLE_framebuffer_blit and APPLE_framebuffer_multisample:
If neither ANGLE_framebuffer_blit nor APPLE_framebuffer_multisample are
supported, then all references to "draw framebuffers" should be replaced
with references to "framebuffers". References to DRAW_FRAMEBUFFER_BINDING
should be replaced with references to FRAMEBUFFER_BINDING. References to
DRAW_FRAMEBUFFER and READ_FRAMEBUFFER should be removed.
If ANGLE_framebuffer_blit is supported, DRAW_FRAMEBUFFER_BINDING, DRAW_FRAMEBUFFER
and READ_FRAMEBUFFER all refer to corresponding _ANGLE suffixed names
(they have the same token values).
If APPLE_framebuffer_multisample is supported, DRAW_FRAMEBUFFER_BINDING,
DRAW_FRAMEBUFFER and READ_FRAMEBUFFER all refer to the corresponding _APPLE
suffixed names (they have the same token values).
Errors
The INVALID_OPERATION error is generated if DrawBuffersEXT is called
when the default framebuffer is bound and any of the following conditions
hold:
- <n> is greater than 1 and less than MAX_DRAW_BUFFERS_EXT,
- <bufs> contains a value other than BACK or NONE.
The INVALID_OPERATION error is generated if DrawBuffersEXT is called
when bound to a draw framebuffer object and any of the following
conditions hold:
- the <i>th value in <bufs> is not COLOR_ATTACHMENT<i>_EXT or NONE.
The INVALID_VALUE error is generated if DrawBuffersEXT is called
with a value of <n> which is greater than MAX_DRAW_BUFFERS_EXT.
The INVALID_ENUM error is generated by FramebufferRenderbuffer if
the <attachment> parameter is not one of the values listed in Table 4.x.
The INVALID_ENUM error is generated by FramebufferTexture2D if
the <attachment> parameter is not one of the values listed in Table 4.x.
The INVALID_ENUM error is generated by GetFramebufferAttachmentParameteriv
if the <attachment> parameter is not one of the values listed in Table 4.x.
New State
Add Table 6.X Framebuffer (State per framebuffer object):
State Type Get Command Initial Value Description
------------------ ---- ------------ ------------- -----------
DRAW_BUFFER<i>_EXT Z10* GetIntegerv see 4.2.1 Draw buffer selected
for fragment color i
Add to Table 6.18 (Implementation Dependent Values)
Get value Type Get Cmnd Minimum Value Description Sec.
-------------------- ---- ----------- ------------- ----------- -----
MAX_DRAW_BUFFERS_EXT Z+ GetIntegerv 1 Maximum number of 4.2.1
active draw buffers
MAX_COLOR_ATTACHMENTS_EXT Z+ GetIntegerv 1 Number of framebuffer 4.4.1
color attachment points
Issues
See ARB_draw_buffers for relevant issues.
1) What are the differences between this extension and NV_draw_buffers
+ NV_fbo_color_attachments?
RESOLVED. This extension:
- adds interactions with blit_framebuffer and the separate
draw/read binding points
- The draw buffer and color attachment limits are global instead
of per-fbo (see Issue 2)
- can be used to with default framebuffer to set NONE/BACK (see Issue 4)
- retains the ordering restrictions on color attachments that are
imposed by ES 3.0.
2) Should the MAX_DRAW_BUFFERS_EXT and MAX_COLOR_ATTACHMENTS_EXT limits
be per-framebuffer values or implementation dependent constants?
DISCUSSION: In ARB_draw_buffers this was per-context (see Issue 2).
EXT_framebuffer_object (and subsequently ARB_framebuffer_object, and GL 3.0
through GL 4.2) made these queries framebuffer-dependent.
However in GL 4.3 and GLES 3.0, these limits were changed from
framebuffer-dependent state to implementation-dependent state after
much discussion (Bug 7990).
NV_draw_buffers has MAX_DRAW_BUFFERS listed as per-framebuffer state,
but NV_fbo_color_attachments has MAX_COLOR_ATTACHMENTS as an
implementation-dependent constant.
This is relevant because some implementations are not able to support
multisampling in conjuction with multiple color attachments. If the
query is per-framebuffer, they can report a maximum of one attachment
when there are multisampled attachments, but a higher limit when only
single-sampled attachments are present.
RESOLVED. Make this global context state as this is most consistent
with GLES 3.0 and updated GL drivers. In an implementation cannot
support multisampling in conjunction with multiple color attachments,
perhaps such an implementation could report FBO incomplete in this
situation, but this is less than desirable.
3) Should we support broadcast from gl_FragColor to all gl_FragData[x]
or should it be synonymous with gl_FragData[0]?
DISCUSSION: With NV_draw_buffers, writing to gl_FragColor writes to all
the enabled draw buffers (ie broadcast). In OpenGL ES 3.0 when using
ESSL 1.0, gl_FragColor is equivalent to writing a single output to
gl_FragData[0] and multiple outputs are not possible. When using ESSL 3.0,
only user-defined out variables may be used.
If broadcast is supported, some implementations may have to replace
writes to gl_FragColor with replicated writes to all possible gl_FragData
locations when this extension is enabled.
RESOLVED: Writes to gl_FragColor are broadcast to all enabled color
buffers. ES 3.0 using ESSL 1.0 doesn't support broadcast because
ESSL 1.0 was not extended to have multiple color outputs (but that is
what this extension adds). ESSL 3.0 doesn't support the broadcast because
it doesn't have the gl_FragColor variable at all, and only has user-
defined out variables. This extension extends ESSL 1.0 to have multiple
color outputs. Broadcasting from gl_FragColor to all enabled color
buffers is the most consistent with existing draw buffer extensions to
date (both NV_draw_buffers and desktop GL).
4) Should we allow DrawBuffersEXT to be called when the default FBO is
bound?
DISCUSSION: NV_draw_buffers specifies that DrawBuffersNV errors with
INVALID_OPERATION when the default FBO is bound. OpenGL ES 3.0 allows
DrawBuffers to toggle between BACK and NONE on the default FBO.
An implementation that does not natively support disabling the drawbuffer
on the default FBO could emulate this by disabling color writes.
RESOLVED: Allow DrawBuffersEXT to be called for the default FBO. This
is more forward looking and is compatible with ES 3.0.
5) What are the requirements on the color attachment sizes and formats?
RESOLVED: ES 2.0 requires that all color buffers attached to application-
created framebuffer objects must have the same number of bitplanes
(Chapter 4 overview p91). ES 2.0 also requires that all attached images
have the same width and height (Section 4.4.5 Framebuffer Completeness).
This extension does not lift those requirements, and failing to meet
them will result in an incomplete FBO.
6) Does this have any interactions with glClear?
RESOLVED: Yes. When multiple color buffers are enabled for writing,
glClear clears all of the color buffers. Added language clarifying
that glClear and glClearColor may affect multiple color buffers.
Revision History
01/30/2013 dgkoch add issue 6 and clear interactions
renamed to EXT_draw_buffers based on feedback
changed resolution of issue 3.
01/23/2013 dgkoch add resolutions to issues 2-4.
add issue 5.
Add Table 4.x and update various explicit
references to COLOR_ATTACHMENT0.
Add errors.
11/13/2012 dgkoch add revision history
add text from updated ES 3.0 spec
add issues for discussion
10/16/2012 kbr update name string
10/16/2012 kbr remove restrition requiring draw buffer 0 to be non-NULL
10/12/2012 kbr remove references to GetDoublev and ReadBuffer
10/11/2012 kbr initial draft extension
extensions/EXT_robustness.txt deleted 100644 → 0
Name
EXT_robustness
Name Strings
GL_EXT_robustness
Contributors
Daniel Koch, TransGaming
Nicolas Capens, TransGaming
Contributors to ARB_robustness
Contact
Greg Roth, NVIDIA (groth 'at' nvidia.com)
Status
Complete.
Version
Version 3, 2011/10/31
Number
OpenGL ES Extension #107
Dependencies
This extension is written against the OpenGL ES 2.0 Specification
but can apply to OpenGL ES 1.1 and up.
EGL_EXT_create_context_robustness is used to determine if a context
implementing this extension supports robust buffer access, and if it
supports reset notification.
Overview
Several recent trends in how OpenGL integrates into modern computer
systems have created new requirements for robustness and security
for OpenGL rendering contexts.
Additionally GPU architectures now support hardware fault detection;
for example, video memory supporting ECC (error correcting codes)
and error detection. OpenGL contexts should be capable of recovering
from hardware faults such as uncorrectable memory errors. Along with
recovery from such hardware faults, the recovery mechanism can
also allow recovery from video memory access exceptions and system
software failures. System software failures can be due to device
changes or driver failures.
OpenGL queries that that return (write) some number of bytes to a
buffer indicated by a pointer parameter introduce risk of buffer
overflows that might be exploitable by malware. To address this,
queries with return value sizes that are not expressed directly by
the parameters to the query itself are given additional API
functions with an additional parameter that specifies the number of
bytes in the buffer and never writing bytes beyond that limit. This
is particularly useful for multi-threaded usage of OpenGL contexts
in a "share group" where one context can change objects in ways that
can cause buffer overflows for another context's OpenGL queries.
The original ARB_vertex_buffer_object extension includes an issue
that explicitly states program termination is allowed when
out-of-bounds vertex buffer object fetches occur. Modern graphics
hardware is capable well-defined behavior in the case of out-of-
bounds vertex buffer object fetches. Older hardware may require
extra checks to enforce well-defined (and termination free)
behavior, but this expense is warranted when processing potentially
untrusted content.
The intent of this extension is to address some specific robustness
goals:
* For all existing OpenGL queries, provide additional "safe" APIs
that limit data written to user pointers to a buffer size in
bytes that is an explicit additional parameter of the query.
* Provide a mechanism for an OpenGL application to learn about
graphics resets that affect the context. When a graphics reset
occurs, the OpenGL context becomes unusable and the application
must create a new context to continue operation. Detecting a
graphics reset happens through an inexpensive query.
* Provide an enable to guarantee that out-of-bounds buffer object
accesses by the GPU will have deterministic behavior and preclude
application instability or termination due to an incorrect buffer
access. Such accesses include vertex buffer fetches of
attributes and indices, and indexed reads of uniforms or
parameters from buffers.
New Procedures and Functions
enum GetGraphicsResetStatusEXT();
void ReadnPixelsEXT(int x, int y, sizei width, sizei height,
enum format, enum type, sizei bufSize,
void *data);
void GetnUniformfvEXT(uint program, int location, sizei bufSize,
float *params);
void GetnUniformivEXT(uint program, int location, sizei bufSize,
int *params);
New Tokens
Returned by GetGraphicsResetStatusEXT:
NO_ERROR 0x0000
GUILTY_CONTEXT_RESET_EXT 0x8253
INNOCENT_CONTEXT_RESET_EXT 0x8254
UNKNOWN_CONTEXT_RESET_EXT 0x8255
Accepted by the <value> parameter of GetBooleanv, GetIntegerv,
and GetFloatv:
CONTEXT_ROBUST_ACCESS_EXT 0x90F3
RESET_NOTIFICATION_STRATEGY_EXT 0x8256
Returned by GetIntegerv and related simple queries when <value> is
RESET_NOTIFICATION_STRATEGY_EXT :
LOSE_CONTEXT_ON_RESET_EXT 0x8252
NO_RESET_NOTIFICATION_EXT 0x8261
Additions to Chapter 2 of the OpenGL ES 2.0 Specification (OpenGL ES Operation)
Add a new subsection after 2.5 "GL Errors" and renumber subsequent
sections accordingly.
2.6 "Graphics Reset Recovery"
Certain events can result in a reset of the GL context. Such a reset
causes all context state to be lost. Recovery from such events
requires recreation of all objects in the affected context. The
current status of the graphics reset state is returned by
enum GetGraphicsResetStatusEXT();
The symbolic constant returned indicates if the GL context has been
in a reset state at any point since the last call to
GetGraphicsResetStatusEXT. NO_ERROR indicates that the GL context
has not been in a reset state since the last call.
GUILTY_CONTEXT_RESET_EXT indicates that a reset has been detected
that is attributable to the current GL context.
INNOCENT_CONTEXT_RESET_EXT indicates a reset has been detected that
is not attributable to the current GL context.
UNKNOWN_CONTEXT_RESET_EXT indicates a detected graphics reset whose
cause is unknown.
If a reset status other than NO_ERROR is returned and subsequent
calls return NO_ERROR, the context reset was encountered and
completed. If a reset status is repeatedly returned, the context may
be in the process of resetting.
Reset notification behavior is determined at context creation time,
and may be queried by calling GetIntegerv with the symbolic constant
RESET_NOTIFICATION_STRATEGY_EXT.
If the reset notification behavior is NO_RESET_NOTIFICATION_EXT,
then the implementation will never deliver notification of reset
events, and GetGraphicsResetStatusEXT will always return
NO_ERROR[fn1].
[fn1: In this case it is recommended that implementations should
not allow loss of context state no matter what events occur.
However, this is only a recommendation, and cannot be relied
upon by applications.]
If the behavior is LOSE_CONTEXT_ON_RESET_EXT, a graphics reset will
result in the loss of all context state, requiring the recreation of
all associated objects. In this case GetGraphicsResetStatusEXT may
return any of the values described above.
If a graphics reset notification occurs in a context, a notification
must also occur in all other contexts which share objects with that
context[fn2].
[fn2: The values returned by GetGraphicsResetStatusEXT in the
different contexts may differ.]
Add to Section 2.8 "Vertex Arrays" before subsection "Transferring
Array Elements"
Robust buffer access is enabled by creating a context with robust
access enabled through the window system binding APIs. When enabled,
indices within the vertex array that lie outside the arrays defined
for enabled attributes result in undefined values for the
corresponding attributes, but cannot result in application failure.
Robust buffer access behavior may be queried by calling GetIntegerv
with the symbolic constant CONTEXT_ROBUST_ACCESS_EXT.
Additions to Chapter 4 of the OpenGL ES 2.0 Specification (Per-Fragment
Operations and the Frame Buffer)
Modify section 4.3.1 "Reading Pixels"
Pixels are read using
void ReadPixels(int x, int y, sizei width, sizei height,
enum format, enum type, void *data);
void ReadnPixelsEXT(int x, int y, sizei width, sizei height,
enum format, enum type, sizei bufSize,
void *data);
Add to the description of ReadPixels:
ReadnPixelsEXT behaves identically to ReadPixels except that it does
not write more than <bufSize> bytes into <data>. If the buffer size
required to fill all the requested data is greater than <bufSize> an
INVALID_OPERATION error is generated and <data> is not altered.
Additions to Chapter 5 of the OpenGL ES 2.0 Specification (Special
Functions):
None
Additions to Chapter 6 of the OpenGL ES 2.0 Specification (State and
State Requests)
Modify Section 6.1.8 "Shader and Program Queries"
The commands
void GetUniformfv(uint program, int location, float *params);
void GetnUniformfvEXT(uint program, int location, sizei bufSize,
float *params);
void GetUniformiv(uint program, int location, int *params);
void GetnUniformivEXT(uint program, int location, sizei bufSize,
int *params);
return the value or values of the uniform at location <location>
for program object <program> in the array <params>. Calling
GetnUniformfvEXT or GetnUniformivEXT ensures that no more than
<bufSize> bytes are written into <params>. If the buffer size
required to fill all the requested data is greater than <bufSize> an
INVALID_OPERATION error is generated and <params> is not altered.
...
Additions to The OpenGL ES Shading Language Specification, Version 1.
Append to the third paragraph of section 4.1.9 "Arrays"
If robust buffer access is enabled via the OpenGL ES API, such
indexing must not result in abnormal program termination. The
results are still undefined, but implementations are encouraged to
produce zero values for such accesses.
Interactions with EGL_EXT_create_context_robustness
If the EGL window-system binding API is used to create a context,
the EGL_EXT_create_context_robustness extension is supported, and
the attribute EGL_CONTEXT_OPENGL_ROBUST_ACCESS_EXT is set to
EGL_TRUE when eglCreateContext is called, the resulting context will
perform robust buffer access as described above in section 2.8, and
the CONTEXT_ROBUST_ACCESS_EXT query will return GL_TRUE as described
above in section 6.1.5.
If the EGL window-system binding API is used to create a context and
the EGL_EXT_create_context_robustness extension is supported, then
the value of attribute EGL_CONTEXT_RESET_NOTIFICATION_STRATEGY_EXT
determines the reset notification behavior and the value of
RESET_NOTIFICATION_STRATEGY_EXT, as described in section 2.6.
Errors
ReadnPixelsEXT, GetnUniformfvEXT, and GetnUniformivEXT share all the
errors of their unsized buffer query counterparts with the addition
that INVALID_OPERATION is generated if the buffer size required to
fill all the requested data is greater than <bufSize>.
New Implementation Dependent State
Get Value Type Get Command Minimum Value Description Sec. Attribute
--------- ---- ----------- ------------- --------------------------- ----- ---------
CONTEXT_ROBUST_ACCESS_EXT B GetIntegerv - Robust access enabled 6.1.5 -
RESET_NOTIFICATION_STRATEGY_EXT Z_2 GetIntegerv See sec. 2.6 Reset notification behavior 2.6 -
Issues
1. What should this extension be called?
RESOLVED: EXT_robustness
Since this is intended to be a version of ARB_robustness for
OpenGL ES, it should be named accordingly.
2. How does this extension differ from Desktop GL's ARB_robustness?
RESOLVED: Because EGL_EXT_create_context_robustness uses a
separate attribute to enable robust buffer access, a
corresponding query is added here.
3. Should we provide a context creation mechanism to enable this extension?
RESOLVED. Yes.
Currently, EGL_EXT_create_context_robustness provides this
mechanism via two unique attributes. These attributes differ
from those specified by KHR_create_context to allow for
differences in what functionality those attributes define.
4. What can cause a graphics reset?
Either user or implementor errors may result in a graphics reset.
If the application attempts to perform a rendering that takes too long
whether due to an infinite loop in a shader or even just a rendering
operation that takes too long on the given hardware. Implementation
errors may produce badly formed hardware commands. Memory access errors
may result from user or implementor mistakes. On some systems, power
management events such as system sleep, screen saver activation, or
pre-emption may also context resets to occur. Any of these events may
result in a graphics reset event that will be detectable by the
mechanism described in this extension.
5. How should the application react to a reset context event?
RESOLVED: For this extension, the application is expected to query
the reset status until NO_ERROR is returned. If a reset is encountered,
at least one *RESET* status will be returned. Once NO_ERROR is again
encountered, the application can safely destroy the old context and
create a new one.
After a reset event, apps should not use a context for any purpose
other than determining its reset status, and then destroying it. If a
context receives a reset event, all other contexts in its share group
will also receive reset events, and should be destroyed and
recreated.
Apps should be cautious in interpreting the GUILTY and INNOCENT reset
statuses. These are guidelines to the immediate cause of a reset, but
not guarantees of the ultimate cause.
6. If a graphics reset occurs in a shared context, what happens in
shared contexts?
RESOLVED: A reset in one context will result in a reset in all other
contexts in its share group.
7. How can an application query for robust buffer access support,
since this is now determined at context creation time?
RESOLVED. The application can query the value of ROBUST_ACCESS_EXT
using GetIntegerv. If true, this functionality is enabled.
8. How is the reset notification behavior controlled?
RESOLVED: Reset notification behavior is determined at context
creation time using EGL/GLX/WGL/etc. mechanisms. In order that shared
objects be handled predictably, a context cannot share with
another context unless both have the same reset notification
behavior.
Revision History
Rev. Date Author Changes
---- ------------ --------- ----------------------------------------
3 31 Oct 2011 groth Reverted to attribute for robust access. Now it's a
companion to rather than subset of KHR_create_context
2 11 Oct 2011 groth Merged ANGLE and NV extensions.
Convert to using flag to indicate robust access.
1 15 July 2011 groth Initial version
extensions/EXT_texture_rg.txt deleted 100644 → 0
Name
EXT_texture_rg
Name Strings
GL_EXT_texture_rg
Contributors
Contributors to ARB_texture_rg, on which this extension is based
Kyle Haughey
Richard Schreyer
Contact
Benj Lipchak, Apple (lipchak 'at' apple.com)
Status
Complete
Version
Date: July 22, 2011
Revision: 3
Number
OpenGL ES Extension #103
Dependencies
Requires OpenGL ES 2.0.
Written based on the wording of the OpenGL ES 2.0.25 Full Specification
(November 2, 2010).
OES_texture_float affects the definition of this extension.
OES_texture_half_float affects the definition of this extension.
APPLE_framebuffer_multisample affects the definition of this extension.
Overview
Historically one- and two-component textures have been specified in OpenGL
ES using the luminance or luminance-alpha (L/LA) formats. With the advent
of programmable shaders and render-to-texture capabilities these legacy
formats carry some historical artifacts which are no longer useful.
For example, when sampling from such textures, the luminance values are
replicated across the color components. This is no longer necessary with
programmable shaders.
It is also desirable to be able to render to one- and two-component format
textures using capabilities such as framebuffer objects (FBO), but
rendering to L/LA formats is under-specified (specifically how to map
R/G/B/A values to L/A texture channels).
This extension adds new base internal formats for one-component RED and
two-component RG (red green) textures as well as sized RED and RG internal
formats for renderbuffers. The RED and RG texture formats can be used for
both texturing and rendering into with framebuffer objects.
New Procedures and Functions
None
New Tokens
Accepted by the <internalformat> parameter of TexImage2D and CopyTexImage2D,
and the <format> parameter of TexImage2D, TexSubImage2D, and ReadPixels:
RED_EXT 0x1903
RG_EXT 0x8227
Accepted by the <internalformat> parameter of RenderbufferStorage and
RenderbufferStorageMultisampleAPPLE:
R8_EXT 0x8229
RG8_EXT 0x822B
Additions to Chapter 2 of the OpenGL ES 2.0 Specification (OpenGL ES Operation)
None
Additions to Chapter 3 of the OpenGL ES 2.0 Specification (Rasterization)
(Add the following to Table 3.3: "TexImage2D and ReadPixels formats")
Format Name Element Meaning and Order Target Buffer
----------- ------------------------- -------------
RED_EXT R Color
RG_EXT R, G Color
(Add the following to Table 3.4: "Valid pixel format and type combinations")
(as modified by OES_texture_float and OES_texture_half_float)
Format Type Bytes per Pixel
----------- ------------------------- ---------------
RED_EXT FLOAT 4
RED_EXT HALF_FLOAT_OES 2
RED_EXT UNSIGNED_BYTE 1
RG_EXT FLOAT 8
RG_EXT HALF_FLOAT_OES 4
RG_EXT UNSIGNED_BYTE 2
(Add the following to Table 3.8: "Conversion from RGBA and depth pixel
components to internal texture")
Base Internal Format RGBA Internal Components
-------------------- ------ -------------------
RED_EXT R R
RG_EXT R,G R,G
(Modify Table 3.9: "CopyTexImage internal format/color buffer combinations")
Texture Format
Color Buffer A L LA R RG RGB RGBA
------------ - - -- - -- --- ----
A X
R X X
RG X X X
RGB X X X X
RGBA X X X X X X X
(Add the following to Table 3.12: "Correspondence of filtered texture
components to texture source color components")
Texture Base Texture source color
Internal Format C_s A_s
--------------- ------------- ------
RED_EXT (R_t, 0, 0) 1
RG_EXT (R_t, G_t, 0) 1
Additions to Chapter 4 of the OpenGL ES 2.0 Specification (Per-Fragment
Operations and the Framebuffer)
In section 4.3.1 "Reading Pixels", subsection "Obtaining Pixels from the
Framebuffer", modify the last sentence to read:
"If the framebuffer does not support G, B, or A values then the G, B, and A
values that are obtained are 0.0, 0.0, and 1.0 respectively."
In section 4.4.5 "Framebuffer Completeness", modify the last sentence of
the second paragraph to read:
"Color-renderable formats contain red, and possibly green, blue, and alpha
components; depth-renderable formats contain depth components; and
stencil-renderable formats contain stencil components."
(Add the following to Table 4.5: "Renderbuffer image formats, showing their
renderable type (color-, depth-, or stencil-renderable) and the number of
bits each format contains for color (R, G, B, A), depth (D), and stencil
(S) components")
Sized Internal Renderable Type R bits G bits B bits A bits D bits S bits
Format
-------------- ---------------- ------ ------ ------ ------ ------ ------
R8_EXT color-renderable 8
RG8_EXT color-renderable 8 8
Additions to Chapter 5 of the OpenGL ES 2.0 Specification (Special Functions)
None
Additions to Chapter 6 of the OpenGL ES 2.0 Specification (State and State
Requests)
None
Dependencies on OES_texture_float
If OES_texture_float is not supported, then omit the rows of
Table 3.4 that have Type FLOAT.
Dependencies on OES_texture_half_float
If OES_texture_half_float is not supported, then omit the rows of
Table 3.4 that have Type HALF_FLOAT_OES.
Dependencies on APPLE_framebuffer_multisample
If APPLE_framebuffer_multisample is not supported, then all references to
RenderbufferStorageMultisampleAPPLE should be ignored.
Revision History
#1 February 22, 2011, khaughey
- initial version adapted from ARB_texture_rg.
#2 June 16, 2011, benj
- add interaction with APPLE_framebuffer_multisample
#3 July 22, 2011, benj
- rename from APPLE to EXT
extensions/EXT_texture_storage.txt deleted 100644 → 0
Name
EXT_texture_storage
Name Strings
GL_EXT_texture_storage
Contact
Bruce Merry (bmerry 'at' gmail.com)
Ian Romanick, Intel (ian.d.romanick 'at' intel.com)
Contributors
Jeremy Sandmel, Apple
Bruce Merry, ARM
Tom Olson, ARM
Benji Bowman, Imagination Technologies
Ian Romanick, Intel
Jeff Bolz, NVIDIA
Pat Brown, NVIDIA
Maurice Ribble, Qualcomm
Lingjun Chen, Qualcomm
Daniel Koch, Transgaming Inc
Status
Complete.
Version
Last Modified Date: November 11, 2011
Author Revision: 24
Number
OpenGL ES Extension #108
Dependencies
OpenGL ES 1.0, OpenGL ES 2.0 or OpenGL 1.2 is required.
OES_texture_npot, OES_texture_cube_map, OES_texture_3D,
OES_depth_texture, OES_packed_depth_stencil,
OES_compressed_paletted_texture, OES_texture_float, OES_texture_half_float
EXT_texture_type_2_10_10_10_REV, EXT_texture_format_BGRA8888,
EXT_texture3D, OES_texture_npot, APPLE_texture_2D_limited_npot,
ARB_texture_cube_map, ARB_texture_cube_map_array,
ARB_texture_rectangle, SGIS_generate_mipmap,
EXT_direct_state_access, OES_EGL_image, WGL_ARB_render_texture,
GLX_EXT_texture_from_pixmap, and core specifications that
incorporate these extensions affect the definition of this
extension.
This extension is written against the OpenGL 3.2 Core Profile
specification.
Overview
The texture image specification commands in OpenGL allow each level
to be separately specified with different sizes, formats, types and
so on, and only imposes consistency checks at draw time. This adds
overhead for implementations.
This extension provides a mechanism for specifying the entire
structure of a texture in a single call, allowing certain
consistency checks and memory allocations to be done up front. Once
specified, the format and dimensions of the image array become
immutable, to simplify completeness checks in the implementation.
When using this extension, it is no longer possible to supply texture
data using TexImage*. Instead, data can be uploaded using TexSubImage*,
or produced by other means (such as render-to-texture, mipmap generation,
or rendering to a sibling EGLImage).
This extension has complicated interactions with other extensions.
The goal of most of these interactions is to ensure that a texture
is always mipmap complete (and cube complete for cubemap textures).
IP Status
No known IP claims
New Procedures and Functions
void TexStorage1DEXT(enum target, sizei levels,
enum internalformat,
sizei width);
void TexStorage2DEXT(enum target, sizei levels,
enum internalformat,
sizei width, sizei height);
void TexStorage3DEXT(enum target, sizei levels,
enum internalformat,
sizei width, sizei height, sizei depth);
void TextureStorage1DEXT(uint texture, enum target, sizei levels,
enum internalformat,
sizei width);
void TextureStorage2DEXT(uint texture, enum target, sizei levels,
enum internalformat,
sizei width, sizei height);
void TextureStorage3DEXT(uint texture, enum target, sizei levels,
enum internalformat,
sizei width, sizei height, sizei depth);
New Types
None
New Tokens
Accepted by the <value> parameter of GetTexParameter{if}v:
TEXTURE_IMMUTABLE_FORMAT_EXT 0x912F
Accepted by the <internalformat> parameter of TexStorage* when
implemented on OpenGL ES:
ALPHA8_EXT 0x803C /* reuse tokens from EXT_texture */
LUMINANCE8_EXT 0x8040
LUMINANCE8_ALPHA8_EXT 0x8045
(if OES_texture_float is supported)
RGBA32F_EXT 0x8814 /* reuse tokens from ARB_texture_float */
RGB32F_EXT 0x8815
ALPHA32F_EXT 0x8816
LUMINANCE32F_EXT 0x8818
LUMINANCE_ALPHA32F_EXT 0x8819
(if OES_texture_half_float is supported)
RGBA16F_EXT 0x881A /* reuse tokens from ARB_texture_float */
RGB16F_EXT 0x881B
ALPHA16F_EXT 0x881C
LUMINANCE16F_EXT 0x881E
LUMINANCE_ALPHA16F_EXT 0x881F
(if EXT_texture_type_2_10_10_10_REV is supported)
RGB10_A2_EXT 0x8059 /* reuse tokens from EXT_texture */
RGB10_EXT 0x8052
(if EXT_texture_format_BGRA8888 is supported)
BGRA8_EXT 0x93A1
Additions to Chapter 2 of the OpenGL 3.2 Core Profile Specification
(OpenGL Operation)
None
Additions to Chapter 3 of the OpenGL 3.2 Core Profile Specification
(Rasterization)
After section 3.8.1 (Texture Image Specification) add a new
subsection called "Immutable-format texture images":
"An alterative set of commands is provided for specifying the
properties of all levels of a texture at once. Once a texture is
specified with such a command, the format and dimensions of all
levels becomes immutable, unless it is a proxy texture (since
otherwise it would no longer be possible to use the proxy). The
contents of the images and the parameters can still be modified.
Such a texture is referred to as an "immutable-format" texture. The
immutability status of a texture can be determined by calling
GetTexParameter with <pname> TEXTURE_IMMUTABLE_FORMAT_EXT.
Each of the commands below is described by pseudo-code which
indicates the effect on the dimensions and format of the texture.
For all of the commands, the following apply in addition to the
pseudo-code:
- If the default texture object is bound to <target>, an
INVALID_OPERATION error is generated.
- If executing the pseudo-code would lead to an error, the error is
generated and the command will have no effect.
- Any existing levels that are not replaced are reset to their
initial state.
- If <width>, <height>, <depth> or <levels> is less than 1, the
error INVALID_VALUE is generated.
- Since no pixel data are provided, the <format> and <type> values
used in the pseudo-code are irrelevant; they can be considered to
be any values that are legal to use with <internalformat>.
- If the command is successful, TEXTURE_IMMUTABLE_FORMAT_EXT becomes
TRUE.
- If <internalformat> is a specific compressed texture format, then
references to TexImage* should be replaced by CompressedTexImage*,
with <format>, <type> and <data> replaced by any valid <imageSize> and
<data>. If there is no <imageSize> for which this command would have
been valid, an INVALID_OPERATION error is generated [fn: This
condition is not required for OpenGL, but is necessary for OpenGL
ES which does not support on-the-fly compression.]
- If <internalformat> is one of the internal formats listed in table
3.11, an INVALID_ENUM error is generated. [fn: The corresponding table
in OpenGL ES 2.0 is table 3.8.]
The command
void TexStorage1DEXT(enum target, sizei levels,
enum internalformat,
sizei width);
specifies all the levels of a one-dimensional texture (or proxy) at
the same time. It is described by the pseudo-code below:
for (i = 0; i < levels; i++)
{
TexImage1D(target, i, internalformat, width, 0,
format, type, NULL);
width = max(1, floor(width / 2));
}
If <target> is not TEXTURE_1D or PROXY_TEXTURE_1D then INVALID_ENUM
is generated. If <levels> is greater than floor(log_2(width)) + 1
then INVALID_OPERATION is generated.
The command
void TexStorage2DEXT(enum target, sizei levels,
enum internalformat,
sizei width, sizei height);
specifies all the levels of a two-dimensional, cube-map,
one-dimension array or rectangle texture (or proxy) at the same
time. The pseudo-code depends on the <target>:
[PROXY_]TEXTURE_2D, [PROXY_]TEXTURE_RECTANGLE or
PROXY_TEXTURE_CUBE_MAP:
for (i = 0; i < levels; i++)
{
TexImage2D(target, i, internalformat, width, height, 0,
format, type, NULL);
width = max(1, floor(width / 2));
height = max(1, floor(height / 2));
}
TEXTURE_CUBE_MAP:
for (i = 0; i < levels; i++)
{
for face in (+X, -X, +Y, -Y, +Z, -Z)
{
TexImage2D(face, i, internalformat, width, height, 0,
format, type, NULL);
}
width = max(1, floor(width / 2));
height = max(1, floor(height / 2));
}
[PROXY_]TEXTURE_1D_ARRAY:
for (i = 0; i < levels; i++)
{
TexImage2D(target, i, internalformat, width, height, 0,
format, type, NULL);
width = max(1, floor(width / 2));
}
If <target> is not one of those listed above, the error INVALID_ENUM
is generated.
The error INVALID_OPERATION is generated if any of the following
conditions hold:
- <target> is [PROXY_]TEXTURE_1D_ARRAY and <levels> is greater than
floor(log_2(width)) + 1
- <target> is not [PROXY_]TEXTURE_1D_ARRAY and <levels> is greater
than floor(log_2(max(width, height))) + 1
The command
void TexStorage3DEXT(enum target, sizei levels, enum internalformat,
sizei width, sizei height, sizei depth);
specifies all the levels of a three-dimensional, two-dimensional
array texture, or cube-map array texture (or proxy). The pseudo-code
depends on <target>:
[PROXY_]TEXTURE_3D:
for (i = 0; i < levels; i++)
{
TexImage3D(target, i, internalformat, width, height, depth, 0,
format, type, NULL);
width = max(1, floor(width / 2));
height = max(1, floor(height / 2));
depth = max(1, floor(depth / 2));
}
[PROXY_]TEXTURE_2D_ARRAY, [PROXY_]TEXTURE_CUBE_MAP_ARRAY_ARB:
for (i = 0; i < levels; i++)
{
TexImage3D(target, i, internalformat, width, height, depth, 0,
format, type, NULL);
width = max(1, floor(width / 2));
height = max(1, floor(height / 2));
}
If <target> is not one of those listed above, the error INVALID_ENUM
is generated.
The error INVALID_OPERATION is generated if any of the following
conditions hold:
- <target> is [PROXY_]TEXTURE_3D and <levels> is greater than
floor(log_2(max(width, height, depth))) + 1
- <target> is [PROXY_]TEXTURE_2D_ARRAY or
[PROXY_]TEXTURE_CUBE_MAP_ARRAY_EXT and <levels> is greater than
floor(log_2(max(width, height))) + 1
After a successful call to any TexStorage* command with a non-proxy
target, the value of TEXTURE_IMMUTABLE_FORMAT_EXT for this texture
object is set to TRUE, and no further changes to the dimensions or
format of the texture object may be made. Other commands may only
alter the texel values and texture parameters. Using any of the
following commands with the same texture will result in the error
INVALID_OPERATION being generated, even if it does not affect the
dimensions or format:
- TexImage*
- CompressedTexImage*
- CopyTexImage*
- TexStorage*
The TextureStorage* commands operate identically to the
corresponding command where "Texture" is substituted for "Tex"
except, rather than updating the current bound texture for the
texture unit indicated by the current active texture state and the
target parameter, these "Texture" commands update the texture object
named by the initial texture parameter. The error INVALID_VALUE
is generated if <texture> is zero.
"
In section 3.8.6 (Texture Parameters), after the sentence
"In the remainder of section 3.8, denote by lod_min, lod_max,
level_base, and level_max the values of the texture parameters
TEXTURE_MIN_LOD, TEXTURE_MAX_LOD, TEXTURE_BASE_LEVEL, and
TEXTURE_MAX_LEVEL respectively."
add
"However, if TEXTURE_IMMUTABLE_FORMAT_EXT is
TRUE, then level_base is clamped to the range [0, <levels> - 1] and
level_max is then clamped to the range [level_base, <levels> - 1],
where <levels> is the parameter passed the call to TexStorage* for
the texture object.
In section 3.8.9 (Rendering feedback loops) replace all references
to TEXTURE_BASE_LEVEL by level_base.
In section 3.8.9 (Mipmapping), replace the paragraph starting "Each
array in a mipmap is defined..." by
"Each array in a mipmap is defined using TexImage3D, TexImage2D,
CopyTexImage2D, TexImage1D, CopyTexImage1D, or by functions that are
defined in terms of these functions. Level-of-detail numbers proceed
from level_base for the original texel array through the maximum
level p, with each unit increase indicating an array of half the
dimensions of the previous one (rounded down to the next integer if
fractional) as already described. For immutable-format textures,
p is one less than the <levels> parameter passed to TexStorage*;
otherwise p = floor(log_2(maxsize)) + level_base. All arrays from
level_base through q = min(p, level_max) must be defined, as
discussed in section 3.8.12."
In section 3.8.12 (Texture Completeness), modify the last sentence
to avoid refering to level_base and level_max:
"An implementation may allow a texture image array of level 1 or
greater to be created only if a mipmap complete set of image arrays
consistent with the requested array can be supported where the
values of TEXTURE_BASE_LEVEL and TEXTURE_MAX_LEVEL are 0 and 1000
respectively."
Modify section 3.8.13 (Texture State and Proxy State) to add the new
state:
"Each set consists of ..., and a boolean flag indicating whether the
format and dimensions of the texture are immutable."
Add
"The initial value of TEXTURE_IMMUTABLE_FORMAT_EXT is FALSE."
Additions to Chapter 4 of the OpenGL 3.2 Core Profile Specification
(Per-Fragment Operations and the Frame Buffer)
None
Additions to Chapter 5 of the OpenGL 3.2 Compatibility Profile Specification
(Special Functions)
In section 5.4.1 (Commands Not Usable in Display Lists), add
TexStorage* to the list of commands that cannot be used.
Additions to Chapter 6 of the OpenGL 3.2 Core Profile Specification
(State and State Requests)
Replace the following statement in 6.1.3 (Enumerated Queries):
"<value> must be one of the symbolic values in table 3.10."
with
"<value> must be TEXTURE_IMMUTABLE_FORMAT_EXT or one of the symbolic
values in table 3.22."
Additions to the AGL/EGL/GLX/WGL Specifications
None
Additions to OES_compressed_ETC1_RGB8_texture
Add the following to the additions to Chapter 3:
"Since ETC1 images are easily edited along 4x4 texel boundaries, the
limitations on CompressedTexSubImage2D are relaxed.
CompressedTexSubImage2D will result in an INVALID_OPERATION error
only if one of the following conditions occurs:
* <width> is not a multiple of four, and <width> plus <xoffset> is not
equal to the texture width;
* <height> is not a multiple of four, and <height> plus <yoffset> is
not equal to the texture height; or
* <xoffset> or <yoffset> is not a multiple of four.
Remove CompressedTexSubImage2D from this error:
"INVALID_OPERATION is generated by CompressedTexSubImage2D,
TexSubImage2D, or CopyTexSubImage2D if the texture image <level>
bound to <target> has internal format ETC1_RGB8_OES."
Add the following error:
"INVALID_OPERATION is generated by CompressedTexSubImage2D
if the region to be modified is not aligned to block boundaries
(refer to the extension text for details)."
Additions to AMD_compressed_ATC_texture and AMD_compressed_3DC_texture:
Apply the same changes as for OES_compressed_ETC1_RGB8_texture
above, substituting the appropriate internal format tokens from
these extensions.
Dependencies on EXT_direct_state_access
If EXT_direct_state_access is not present, references to
TextureStorage* should be ignored.
Dependencies on OpenGL ES
On OpenGL ES without extensions introducing TEXTURE_MAX_LEVEL,
mipmapped textures specified with TexStorage are required to have a
full set of mipmaps. If TEXTURE_MAX_LEVEL is not supported, this
extension is modified as follows:
- Where an upper bound is placed on <levels> in this extension (i.e.
the maximum number of mipmap levels for a texture of the given
target and dimensions), an INVALID_OPERATION error is generated if
<levels> is neither 1 nor this upper bound.
- q (the effective maximum number of levels) is redefined to clamp
to the number of levels present in immutable-format textures.
OpenGL ES does not accept sized internal formats (e.g., RGBA8) and
instead derives an internal format from the <format> and <type>
parameters of TexImage2D. Since TexStorage* does not specify texel
data, the API doesn't include <format> and <type> parameters.
On an OpenGL ES implementation, the values in the <internalformat>
column in the tables below are accepted as <internalformat>
parameters, and base internal formats are not accepted. The
TexImage* calls in the TexStorage* pseudocode are modified so that
the <internalformat>, <format> and <type> parameters are
taken from the <format>, <format> and <type> columns (respectively)
in the tables below, according to the <internalformat>
specified in the TexStorage* command.
<internalformat> <format> <type>
---------------- -------- ------
RGB565 RGB UNSIGNED_SHORT_5_6_5
RGBA4 RGBA UNSIGNED_SHORT_4_4_4_4
RGB5_A1 RGBA UNSIGNED_SHORT_5_5_5_1
RGB8_OES RGB UNSIGNED_BYTE
RGBA8_OES RGBA UNSIGNED_BYTE
LUMINANCE8_ALPHA8_EXT LUMINANCE_ALPHA UNSIGNED_BYTE
LUMINANCE8_EXT LUMINANCE UNSIGNED_BYTE
ALPHA8_EXT ALPHA UNSIGNED_BYTE
If OES_depth_texture is supported:
<internalformat> <format> <type>
---------------- -------- ------
DEPTH_COMPONENT16_OES DEPTH_COMPONENT UNSIGNED_SHORT
DEPTH_COMPONENT32_OES DEPTH_COMPONENT UNSIGNED_INT
If OES_packed_depth_stencil is supported:
<internalformat> <format> <type>
---------------- -------- ------
DEPTH24_STENCIL8_OES DEPTH_STENCIL_OES UNSIGNED_INT
If OES_texture_float is supported:
<internalformat> <format> <type>
---------------- -------- ------
RGBA32F_EXT RGBA FLOAT
RGB32F_EXT RGB FLOAT
LUMINANCE_ALPHA32F_EXT LUMINANCE_ALPHA FLOAT
LUMINANCE32F_EXT LUMINANCE FLOAT
ALPHA32F_EXT ALPHA FLOAT
If OES_texture_half_float is supported:
<internalformat> <format> <type>
---------------- -------- ------
RGBA16F_EXT RGBA HALF_FLOAT_OES
RGB16F_EXT RGB HALF_FLOAT_OES
LUMINANCE_ALPHA16F_EXT LUMINANCE_ALPHA HALF_FLOAT_OES
LUMINANCE16F_EXT LUMINANCE HALF_FLOAT_OES
ALPHA16F_EXT ALPHA HALF_FLOAT_OES
If EXT_texture_type_2_10_10_10_REV is supported:
<internalformat> <format> <type>
---------------- -------- ------
RGB10_A2_EXT RGBA UNSIGNED_INT_2_10_10_10_REV_EXT
RGB10_EXT RGB UNSIGNED_INT_2_10_10_10_REV_EXT
If EXT_texture_format_BGRA8888 is supported:
<internalformat> <format> <type>
---------------- -------- ------
BGRA8_EXT BGRA_EXT UNSIGNED_BYTE
Dependencies on texture targets
If a particular texture target is not supported by the
implementation, passing it as a <target> to TexStorage* will
generate an INVALID_ENUM error. If as a result, any of the commands
defined in this extension would no longer have any valid <target>,
all references to the command should be ignored.
In particular, note that OpenGL ES 1.x/2.0 do not have proxy textures,
1D textures, or 3D textures, and thus only the TexStorage2DEXT
entry point is required. If OES_texture_3D is supported, the
TexStorage3DEXT entry point is also required.
Dependencies on OES_texture_npot
If OpenGL ES 2.0 or APPLE_texture_2D_limited_npot is present but
OES_texture_npot is not present, then INVALID_OPERATION is
generated by TexStorage* and TexStorage3DEXT if <levels> is
not one and <width>, <height> or <depth> is not a power of
two.
Dependencies on WGL_ARB_render_texture, GLX_EXT_texture_from_pixmap, EGL
1.4 and GL_OES_EGL_image
The commands eglBindTexImage, wglBindTexImageARB, glXBindTexImageEXT or
EGLImageTargetTexture2DOES are not permitted on an immutable-format
texture.
They will generate the following errors:
- EGLImageTargetTexture2DOES: INVALID_OPERATION
- eglBindTexImage: EGL_BAD_MATCH
- wglBindTexImage: ERROR_INVALID_OPERATION
- glXBindTexImageEXT: BadMatch
Dependencies on OES_compressed_paletted_texture
The compressed texture formats exposed by
OES_compressed_paletted_texture are not supported by TexStorage*.
Passing one of these tokens to TexStorage* will generate an
INVALID_ENUM error.
Errors
Note that dependencies above modify the errors.
If TexStorage* is called with a <width>, <height>, <depth> or
<levels> parameter that is less than one, then the error
INVALID_VALUE is generated.
If the <target> parameter to TexStorage1DEXT is not
[PROXY_]TEXTURE_1D, then the error INVALID_ENUM is generated.
If the <target> parameter to TexStorage2DEXT is not
[PROXY_]TEXTURE_2D, [PROXY_]TEXTURE_CUBE_MAP,
[PROXY_]TEXTURE_RECTANGLE or [PROXY_]TEXTURE_1D_ARRAY, then the
error INVALID_ENUM is generated.
If the <target> parameter to TexStorage3DEXT is not
[PROXY_]TEXTURE_3D, [PROXY_]TEXTURE_2D_ARRAY or
[PROXY_]TEXTURE_CUBE_MAP_ARRAY then the error INVALID_ENUM is
generated.
If the <levels> parameter to TexStorage* is greater than the
<target>-specific value listed below then the error
INVALID_OPERATION is generated:
[PROXY_]TEXTURE_{1D,1D_ARRAY}:
floor(log_2(width)) + 1
[PROXY_]TEXTURE_{2D,2D_ARRAY,CUBE_MAP,CUBE_MAP_ARRAY}:
floor(log_2(max(width, height))) + 1
[PROXY_]TEXTURE_3D:
floor(log_2(max(width, height, depth))) + 1
[PROXY_]TEXTURE_RECTANGLE:
1
If the default texture object is bound to the <target> passed to
TexStorage*, then the error INVALID_OPERATION is generated.
If the <target> parameter to TextureStorage* does not match the
dimensionality of <texture>, then the error INVALID_OPERATION is
generated.
If the <texture> parameter to TextureStorage* is zero, then the
INVALID_VALUE is generated.
If any pseudo-code listed in this extension would generate an error,
then that error is generated.
Calling any of the following functions on a texture for which
TEXTURE_IMMUTABLE_FORMAT_EXT is TRUE will generate an
INVALID_OPERATION error:
- TexImage*
- CompressedTexImage*
- CopyTexImage*
New State
Additions to Table 6.8 Textures (state per texture object)
Initial
Get Value Type Get Command Value Description Sec.
--------- ---- ----------- ------- ----------- ----
TEXTURE_IMMUTABLE_FORMAT_EXT B GetTexParameter FALSE Size and format immutable 2.6
New Implementation Dependent State
None
Issues
1. What should this extension be called?
RESOLVED: EXT_texture_storage is chosen for consistency with the
glRenderbufferStorage entry point.
2. Should TexStorage* accept a border parameter?
RESOLVED: no.
DISCUSSION: Currently it does not, since borders are a deprecated
feature which is not supported by all hardware. Users of the
compatibility profile can continue to use the existing texture
specification functions, but there is an argument that users of
compatibility profile may also want to use this extension.
3. What is the correct error when <levels> specifies a partial
mipmap pyramid for OpenGL ES?
RESOLVED: INVALID_OPERATION, since it is an interaction between
parameters rather than a single value being invalid. It also makes
sense to relax this condition for desktop GL where it makes sense to
use a truncated pyramid with TEXTURE_MAX_LEVEL.
4. Should use of these entry-points make the metadata (format and
dimensions) immutable?
RESOLVED: Yes.
DISCUSSION: The benefits of knowing metadata can't change will
probably outweigh the extra cost of checking the
TEXTURE_IMMUTABLE_FORMAT_EXT flag on each texture specification
call.
5. Should it be legal to completely replace the texture using a new call
to TexStorage*?
RESOLVED. It will not be allowed.
DISCUSSION: This is useful to invalidate all levels of a texture.
Allowing the metadata to be changed here seems easier than trying to
define a portable definition of what it means to change the metadata
(e.g. what if you used an unsized internal format the first time and
the corresponding sized internal format the second time, or vice
versa)?
However, while this is largely similar to deleting the old texture
object and replacing it with a new one, it does lose some of the
advantages of immutability. Specifically, because doing so does not
reset bindings, it doesn't allow a migration path to an API that
validates the texture format at bind time.
6. Should it be legal to use TexImage* after TexStorage* if it doesn't
affect the metadata?
RESOLVED: No.
DISCUSSION: A potential use case is to allow a single level of a
texture to be invalidated using a NULL pointer. However, as noted
above it is non-trivial to determine what constitutes a change.
7. How does this extension interact with APPLE_texture_2D_limited_npot?
RESOLVED. APPLE_texture_2D_limited_npot is equivalent to the NPOT
support in OpenGL ES 2.0.
8. Should this extension be written to work with desktop OpenGL?
RESOLVED: Yes.
DISCUSSION: There has been been interest and it will future-proof it
against further additions to OpenGL ES.
9. Which texture targets should be supported?
RESOLVED. All targets except multisample and buffer textures are
supported.
Initially all targets except TEXTURE_BUFFER were supported. It was
noted that the entrypoints for multisample targets added no useful
functionality, since multisample textures have no completeness
checks beyond being non-empty.
Rectangle textures have completeness checks to prevent filtering of
integer textures. However, since we decided to only force mipmap
completeness, this becomes less useful.
10. Should this extension support proxy textures?
RESOLVED: Yes.
DISCUSSION: It should be orthogonal.
11. Are the <format> and <type> parameters necessary?
RESOLVED. No, they will be removed.
DISCUSSION: For OpenGL ES the type parameter was necessary to
determine the precision of the texture, but this can be solved by
having these functions accept sized internal formats (which are
already accepted by renderbuffers).
12. Should it be legal to make the default texture (id 0)
immutable-format?
RESOLVED: No.
DISCUSSION: This would make it impossible to restore the context to
it's default state, which is deemed undesirable. There is no good
reason not to use named texture objects.
13. Should we try to guarantee that textures made through this path
will always be complete?
RESOLVED: It should be guaranteed that the texture will be mipmap
complete.
DISCUSSION: Future separation between images and samplers will still
allow users to create combinations that are invalid, but
constraining the simple cases will make these APIs easier to use for
beginners.
14. Should these functions use a EXT_direct_state_access approach to
specifying the texture objects?
UNRESOLVED.
DISCUSSION: as a standalone extension, no DSA-like functions will be
added. However, interactions with EXT_direct_state_access and
ARB_direct_state_access need to be resolved.
15. Should these functions accept generic compressed formats?
RESOLVED: Yes. Note that the spec language will need to be modified
to allow this for ES, since the pseudocode is written in terms of
TexImage2D, which does not allow compressed texture formats in ES.
See also issues 23 and 27.
16. How should completeness be forced when TEXTURE_MAX_LEVEL is not
present?
RESOLVED. The maximum level q will be redefined to clamp to the
highest level available.
DISCUSSION: A single-level texture can be made complete either by
making it mipmap complete (by setting TEXTURE_MAX_LEVEL to 0) or by
turning off mipmapping (by choose an appropriate minification
filter).
Some options:
A: Specify that TexStorage* changes the default minification filter
for OpenGL ES. This makes it awkward to add TEXTURE_MAX_LEVEL
support to OpenGL ES later, since switching to match GL would break
compatibility. The two mechanisms also do not give identical
results, since the magnification threshold depends on the
minification filter.
B: Specify that the texture behaves as though TEXTURE_MAX_LEVEL were
zero. To specify this properly probably requires fairly intrusive
changes to the OpenGL ES full specification to add back all the
language relating to the max level. It also does not solve the
similar problem of what to do with NPOT textures; and it may have
hardware impacts due to the change in the min/mag crossover.
C: Specify that TexStorage* changes the default minification filter
for all implementations when a single-level texture is specified.
This may be slightly counter-intuitive to desktop GL users, but will
give consistent behaviour across variants of GL and avoids changing
the functional behaviour of this extension based on the presence or
absence of some other feature.
Currently B is specified. This has potential hardware implications
for OpenGL ES because of the effect of the minification filter on
the min/mag crossover. However, C has potential hardware implications
for OpenGL due to the separation of texture and sampler state.
17. How should completeness be forced when only ES2-style NPOT is
available?
RESOLVED. It is not worth trying to do this, in light of issue 13.
Previous revisions of this extension overrode the minification
filter and wrap modes, but that is no longer the case. Since
OES_texture_npot removes the caveats on NPOT textures anyway, it
might not be worth trying to "fix" this.
18. For OpenGL ES, how do the new sized internal formats interact
with OES_required_internal_format?
RESOLVED.
If OES_required_internal_format is not present, then the
<internalformat> parameter is intended merely to indicate what the
corresponding <format> and <type> would have been, had TexImage*
been used instead. If OES_required_internal_format is present, then
it is intended that the <internalformat> will be interpreted as if
it had been passed directly to TexImage*.
19. Should there be some hinting mechanism to indicate whether data
is coming immediately or later?
RESOLVED. No parameter is needed. An extension can be added to provide
a TexParameter value which is latched at TexStorage time.
DISCUSSION: Some members felt that this would be useful so that they
could defer allocation when suitable, particularly if higher-
resolution images will be streamed in later; or to choose a memory
type or layout appropriate to the usage. However, implementation
experience with BufferData is that developers frequently provide
wrong values and implementations have to guess anyway.
One option suggested was the <usage> parameter currently passed to
BufferData. Another option was to set it with TexParameter.
20. How should this extension interact with
EGLImageTargetTexture2DOES, eglBindTexImage, glXBindTexImage and
wglBindTexImage?
RESOLVED. These functions will not be permitted after glTexStorage*.
Several options are possible:
A) Disallow these functions.
B) Allow them, but have them reset the TEXTURE_IMMUTABLE_FORMAT_EXT
flag.
C) Allow them unconditionally.
C would violate the design principle that the dimensions and format
of the mipmap array are immutable. B does not so much modify the
dimension and formats as replace them with an entirely different
set.
21. Should there be a single function for specifying 1D, 2D and 3D
targets?
RESOLVED. No, we will stick with existing precedent.
22. Is it possible to use GenerateMipmap with an incomplete mipmap
pyramid?
RESOLVED. Yes, because the effective max level is limited to the
levels that were specified, and so GenerateMipmap does not generate
any new levels.
However, to make automatic mipmap generation work, it is necessary
to redefine p rather than q, since automatic mipmap generation
ignores the max level.
23. How should this extension interact with
OES_compressed_paletted_texture?
RESOLVED. Paletted textures will not be permitted, and will
generate INVALID_ENUM.
DISCUSSION: OES_compressed_paletted_texture supplies all the mipmaps
in a single function call, with the palette specified once. That's
incompatible with the upload model in this extension.
24. How can ETC1 textures be used with this extension?
RESOLVED. Add language in this extension to allow subregion uploads
for ETC1.
DISCUSSION: GL_OES_compressed_ETC1_RGB8_texture doesn't allow
CompressedTexSubImage*, so it would be impossible to use this
extension with ETC1. This is seen as an oversight in the ETC1
extension. While it cannot be fixed in that extension (since it is
already shipping), this extension can add that capability.
25. Should any other compressed formats be similarly modified?
RESOLVED. Yes, AMD_compressed_ATC_texture and
AMD_compressed_3DC_texture can be modified similarly to ETC1
(Maurice Ribble indicated that both formats use 4x4 blocks). Desktop
OpenGL requires that whole-image replacement is supported for any
compressed texture format, and the OpenGL ES extensions
EXT_texture_compression_dxt1 and IMG_texture_compression_pvrtc
already allow whole-image replacement, so it is not necessary to
modify them to be used with this extension.
26. Should these commands be permitted in display lists?
RESOLVED. No.
DISCUSSION: Display lists are most useful for repeating commands,
and TexStorage* commands cannot be repeated because the first call
makes the format immutable.
27. Should these commands accept unsized internal formats?
RESOLVED: No, for both OpenGL and OpenGL ES.
DISCUSSION: normally the <type> parameter to TexImage* can serve as
a hint to select a sized format (and in OpenGL ES, this is the only
mechanism available); since TexStorage* does not have a <type>
parameter, the implementation has no information on which to base a
decision.
Revision History
Revision 24, 2011/11/11 (dgkoch)
- Mark complete. Clarify ES clarifications.
Revision 23, 2011/11/10 (dgkoch)
- Add GLES clarifcations and interactions with more GLES extensions
Revision 22, 2011/11/10 (bmerry)
- Update my contact details
Revision 21, 2011/07/25 (bmerry)
- Remove dangling references to MultiTexStorage in Errors section
Revision 20, 2011/07/21 (bmerry)
- Remove dangling reference to <samples> in Errors section
Revision 19, 2011/05/02 (Jon Leech)
- Assign enum value
Revision 18, 2011/01/24 (bmerry)
- Disallow unsized internal formats (oversight in revision 17).
Revision 17, 2011/01/24 (bmerry)
- Added and resolved issue 26.
- Split issue 27 out from issue 15.
- Disallow TexStorage* in display lists.
- Use the term "immutable-format" consistently (bug 7281).
Revision 16, 2010/11/23 (bmerry)
- Disallowed TexStorage on an immutable-format texture
(resolves issue 5).
- Deleted MultiTexStorage* commands (other DSA functions still
unresolved).
- Some minor wording changes suggested by Pat Brown (bug 7002).
Revision 15, 2010/11/09 (bmerry)
- Reopened issue 5.
- Reopened issue 14, pending stabilisation of
ARB_direct_state_access.
- Marked issue 9 resolved, pending any objections.
- Fix references to no object being bound (was meant to refer to
the default object).
- Adding missing pseudocode for TEXTURE_1D_ARRAY.
- Corrected TEXTURE_2D_ARRAY -> TEXTURE_1D_ARRAY in error checks.
- Changed "levels... are removed" to "levels... are reset to their
init state", since desktop GL has per-level state apart from the
texels.
- Miscellaneous wording fixes.
Revision 14, 2010/09/25 (bmerry)
- Add issues 24-25 and alterations to
OES_compressed_ETC1_RGB8_texture, AMD_compressed_ATC_texture and
AMD_compressed_3DC_texture.
Revision 13, 2010/09/19 (bmerry)
- Two typo fixes from Daniel Koch
Revision 12, 2010/09/18 (bmerry)
- Changed resolution to issue 20
- Added and resolved issue 23
- Added explanation of how to upload data (in overview)
- Added spec language to implement resolution to issue 15
Revision 11, 2010/07/21 (bmerry)
- Resolved issue 16
- Reopen issue 20
- Fix some typos
Revision 10, 2010/07/15 (bmerry)
- Update some issues to match core text
- Resolved issue 17
Revision 9, 2010/05/24 (bmerry)
- Marked issue 2 as resolved
- Resolved issue 19 (as no change)
- Resolved issue 20
- Add issues 21-22
- Add in spec language to forbid use on default textures
- Redefine level_base, level_max to be clamped forms of
TEXTURE_BASE_LEVEL/TEXTURE_MAX_LEVEL when using immutable
textures
- Redefine p to also be clamped to the provided levels for
immutable textures, to support automatic mipmap generation
- Removed multisample functions
- Removed language stating that texture parameters were reset to
defaults
Revision 8, 2010/05/18 (bmerry)
- Added issue about EGLimage
- Marked issue 14 as resolved
Revision 7, 2010/05/04 (bmerry)
- Removed some lingering <format>, <type> parameters to the new
functions that should have been removed in revision 4
- Trivial typo fixes
Revision 6, 2010/02/18 (bmerry)
- Resolved issues 5, 6 and 18
- Added MultiTexStorage* functions for DSA interaction
- Added error for texture-target mismatch in DSA
- Allowed TexStorage* to be called again
Revision 5, 2010/01/25 (bmerry)
- Added to contributors list
- Require OpenGL 1.2, to simplify interactions with
TEXTURE_BASE_LEVEL/TEXTURE_MAX_LEVEL and CLAMP_TO_EDGE
- Change default wrap modes to always be CLAMP_TO_EDGE
- Change default filters to always be NEAREST
- Moved language about generating new levels into an interaction,
since it can only happen on OpenGL ES
- Added interaction with EXT_direct_state_access
- Added extra <internalformats> for GL ES when OES_depth_texture,
OES_packed_depth_stencil and EXT_texture_type_2_10_10_10_REV are
present.
- Minor non-functional wording fixes and typos
- Resolved issue 16
- Added issues 17-19
Revision 4, 2010/01/13 (bmerry)
- Changed suffix from ARM to EXT
- Added list of contributors
- Added language to force the texture to always be complete
- Removed <format> and <type> arguments
- Added issues 14-16
- Reopened issue 2
- Reformatted issues to separate resolution and discussion
- Resolved issues 1, 9 and 11-13
- Fixed the max number of levels in a cube map array
Revision 3, 2009/12/17 (bmerry)
- Added missing vendor suffix to TEXTURE_IMMUTABLE_FORMAT_ARM
- Rewritten to against desktop OpenGL
- Added prototypes for 1D and multisample storage functions
- Added issues 8-13
Revision 2, 2009/08/20 (bmerry)
- Resolved issue 2 (no border parameter)
- Resolved issue 4 (metadata becomes immutable)
- Added interaction with OES_texture_cube_map
- Added error if width != height in a cube map
- Added issues 5-7
Revision 1, 2009/05/06 (bmerry)
- First draft
extensions/KHR_parallel_shader_compile.txt deleted 100644 → 0
Name
KHR_parallel_shader_compile
Name Strings
GL_KHR_parallel_shader_compile
Contact
Geoff Lang, (geofflang 'at' google.com)
Contributors
Timothy Lottes, AMD
Graham Sellers, AMD
Eric Werness, NVIDIA
Geoff Lang, Google
Daniel Koch, NVIDIA
Notice
Copyright (c) 2015 The Khronos Group Inc. Copyright terms at
http://www.khronos.org/registry/speccopyright.html
Status
Complete
Version
Last Modified Date: 2017-04-24
Revision: 2
Number
ARB Extension #192
OpenGL ES Extension #288
Dependencies
This extension is written against OpenGL 4.5 (CoreProfile) dated
May 28 2015.
OpenGL ES 2.0 is required (for mobile).
Overview
Compiling GLSL into implementation-specific code can be a time consuming
process, so a GL implementation may wish to perform the compilation in a
separate CPU thread. This extension provides a mechanism for the application
to provide a hint to limit the number of threads it wants to be used to
compile shaders, as well as a query to determine if the compilation process
is complete.
New Procedures and Functions
void MaxShaderCompilerThreadsKHR(uint count);
New Tokens
Accepted by the <pname> parameter of GetBooleanv, GetIntegerv,
GetInteger64v, GetFloatv, and GetDoublev:
MAX_SHADER_COMPILER_THREADS_KHR 0x91B0
Accepted as part of the <pname> parameter to GetShaderiv and
accepted as part of the <pname> parameter to GetProgramiv:
COMPLETION_STATUS_KHR 0x91B1
IP Status
None.
Additions to Chapter 7 "Programs and Shaders",
Append to the end of 7.1 "Shader Objects",
Applications may use the following to hint to the driver the maximum
number background threads it would like to be used in the process of
compiling shaders or linking programs,
void MaxShaderCompilerThreadsKHR(uint count);
where <count> is the number of background threads. A <count> of zero
specifies a request for no parallel compiling or linking and a <count> of
0xFFFFFFFF requests an implementation-specific maximum.
An implementation may combine the maximum compiler thread request from
multiple contexts in a share group in an implementation-specific way.
An application can query the current MaxShaderCompilerThreadsKHR <count>
by calling GetIntegerv with <pname> set to MAX_SHADER_COMPILER_THREADS_KHR,
which returns the value of the current state (Table 23.51).
Add to 7.13 "Shader, Program, and Program Pipeline Queries" under the
descriptions for "pname" for "GetShaderiv",
If <pname> is COMPLETION_STATUS_KHR, TRUE is returned if the shader
compilation has completed, FALSE otherwise.
Add to 7.13 "Shader, Program, and Program Pipeline Queries" under the
descriptions for "pname" for "GetProgramiv",
If <pname> is COMPLETION_STATUS_KHR, TRUE is returned if the program
linking has completed, FALSE otherwise.
New State
Add to Table 23.51: Hints
Get Value Type Get Command Initial Value Description Sec
------------------------------- ---- ------------ ------------- -------------------- ----
MAX_SHADER_COMPILER_THREADS_KHR Z+ GetIntegerv 0xFFFFFFFF Max compile threads 7.13
Add to Table 23.32: Program Object State
Get Value Type Get Command Initial Value Description Sec
---------------------- ---- ------------ ------------- -------------------- ----
COMPLETION_STATUS_KHR B GetProgramiv TRUE Program linking has 7.13
completed
Add to Table 23.30: Shader Object State
Get Value Type Get Command Initial Value Description Sec
--------------------- ---- ------------ ------------- -------------------- ----
COMPLETION_STATUS_KHR B GetShaderiv TRUE Shader compilation 7.13
has completed
Interactions with OpenGL ES
If implemented in OpenGL ES ignore all references to GetDoublev.
If the supported ES version is less than 3.0, ignore all references to
GetInteger64v.
Issues
1) Where should the hint state be stored?
UNRESOLVED: Each context has its own value which may be specified and
queried, but an implementation may choose to combine the hints from multiple
contexts in an implementation-specific manner. There isn't really any
precedent for per-share group state.
2) Can we make the requirements more strict?
RESOLVED: We could, but making sure all of the error behavior is correct and
fully specified would likely take more time than we have. This spec allows
an application to clearly request its intent even if there aren't guarantees
that the implementation will exactly obey the request.
3) Does glGetIntegerv(MAX_SHADER_COMPILER_THREADS_KHR) just return the
value set by MaxShaderCompilerThreadsKHR? Or, if the state is 0xFFFFFFFF
("do something implementation specific"), does it return the number of
threads the implementation has actually chosen to use?
RESOLVED: As with other state queries, this returns the value that was last
set, or if no value was set by the application it returns the default state
value (0xFFFFFFFF).
Revision History
Rev Date Author Changes
--- ---------- -------- ---------------------------------------------
1 2017-03-23 glang Cast as KHR based on v6 of
ARB_parallel_shader_compile.
2 2017-04-24 dgkoch Spec clarifications, add issue 3.
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment