aboutsummaryrefslogtreecommitdiff
path: root/extensions
diff options
context:
space:
mode:
authordaniel@transgaming.com <daniel@transgaming.com@736b8ea6-26fd-11df-bfd4-992fa37f6226>2011-11-12 04:44:03 +0000
committerdaniel@transgaming.com <daniel@transgaming.com@736b8ea6-26fd-11df-bfd4-992fa37f6226>2011-11-12 04:44:03 +0000
commite1301a3c08371bdd4391147ff744022166a18856 (patch)
treed9646f91c56b79f46434a27695240738aa2d8cb8 /extensions
parent43911ec8e68342c86c720af59305231969a79166 (diff)
downloadangle-e1301a3c08371bdd4391147ff744022166a18856.tar.gz
Add extension specifications
git-svn-id: https://angleproject.googlecode.com/svn/trunk@878 736b8ea6-26fd-11df-bfd4-992fa37f6226
Diffstat (limited to 'extensions')
-rw-r--r--extensions/ANGLE_texture_usage.txt202
-rw-r--r--extensions/EGL_EXT_create_context_robustness.txt169
-rw-r--r--extensions/EXT_robustness.txt365
-rw-r--r--extensions/EXT_texture_storage.txt1090
4 files changed, 1826 insertions, 0 deletions
diff --git a/extensions/ANGLE_texture_usage.txt b/extensions/ANGLE_texture_usage.txt
new file mode 100644
index 00000000..8c504237
--- /dev/null
+++ b/extensions/ANGLE_texture_usage.txt
@@ -0,0 +1,202 @@
+Name
+
+ ANGLE_texture_usage
+
+Name Strings
+
+ GL_ANGLE_texture_usage
+
+Contributors
+
+ Nicolas Capens, TransGaming
+ Daniel Koch, TransGaming
+
+Contact
+
+ Daniel Koch, TransGaming (daniel 'at' transgaming.com)
+
+Status
+
+ Complete
+
+Version
+
+ Last Modified Date: November 10, 2011
+ Version: 2
+
+Number
+
+ TBD
+
+Dependencies
+
+ This extension is written against the OpenGL ES 2.0 Specification.
+
+Overview
+
+ In some implementations it is advantageous to know the expected
+ usage of a texture before the backing storage for it is allocated.
+ This can help to inform the implementation's choice of format
+ and type of memory used for the allocation. If the usage is not
+ known in advance, the implementation essentially has to make a
+ guess as to how it will be used. If it is later proven wrong,
+ it may need to perform costly re-allocations and/or reformatting
+ of the texture data, resulting in reduced performance.
+
+ This extension adds a texture usage flag that is specified via
+ the TEXTURE_USAGE_ANGLE TexParameter. This can be used to
+ indicate that the application knows that this texture will be
+ used for rendering.
+
+IP Status
+
+ No known IP claims.
+
+New Procedures and Functions
+
+ None
+
+New Tokens
+
+ Accepted as a value for <pname> for the TexParameter{if} and
+ TexParameter{if}v commands and for the <value> parameter of
+ GetTexParameter{if}v:
+
+ TEXTURE_USAGE_ANGLE 0x93A2
+
+ Accepted as a value to <param> for the TexParameter{if} and
+ to <params> for the TexParameter{if}v commands with a <pname> of
+ TEXTURE_USAGE_ANGLE; returned as possible values for <data> when
+ GetTexParameter{if}v is queried with a <value> of TEXTURE_USAGE_ANGLE:
+
+ NONE 0x0000
+ FRAMEBUFFER_ATTACHMENT_ANGLE 0x93A3
+
+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 a new row to Table 3.10 (Texture parameters and their values):
+
+ Name | Type | Legal Values
+ ------------------------------------------------------------
+ TEXTURE_USAGE_ANGLE | enum | NONE, FRAMEBUFFER_ATTACHMENT_ANGLE
+
+ Add a new section 3.7.x (Texture Usage) before section 3.7.12 and
+ renumber the subsequent sections:
+
+ "3.7.x Texture Usage
+
+ Texture usage can be specified via the TEXTURE_USAGE_ANGLE value
+ for the <pname> argument to TexParameter{if}[v]. In order to take effect,
+ the texture usage must be specified before the texture contents are
+ defined either via TexImage2D or TexStorage2DEXT.
+
+ The usage values can impact the layout and type of memory used for the
+ texture data. Specifying incorrect usage values may result in reduced
+ functionality and/or significantly degraded performance.
+
+ Possible values for <params> when <pname> is TEXTURE_USAGE_ANGLE are:
+
+ NONE - the default. No particular usage has been specified and it is
+ up to the implementation to determine the usage of the texture.
+ Leaving the usage unspecified means that the implementation may
+ have to reallocate the texture data as the texture is used in
+ various ways.
+
+ FRAMEBUFFER_ATTACHMENT_ANGLE - this texture will be attached to a
+ framebuffer object and used as a desination for rendering or blits."
+
+ Modify section 3.7.12 (Texture State) and place the last 3 sentences
+ with the following:
+
+ "Next, there are the three sets of texture properties; each consists of
+ the selected minification and magnification filters, the wrap modes for
+ <s> and <t>, and the usage flags. In the initial state, the value assigned
+ to TEXTURE_MIN_FILTER is NEAREST_MIPMAP_LINEAR, and the value for
+ TEXTURE_MAG_FILTER is LINEAR. <s> and <t> wrap modes are both set to
+ REPEAT. The initial value for TEXTURE_USAGE_ANGLE is NONE."
+
+
+Additions to Chapter 4 of the OpenGL ES 2.0 Specification (Per-Fragment
+Operations and the Framebuffer)
+
+ None
+
+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 EXT_texture_storage
+
+ If EXT_texture_storage is not supported, omit any references to
+ TexStorage2DEXT.
+
+Errors
+
+ If TexParameter{if} or TexParamter{if}v is called with a <pname>
+ of TEXTURE_USAGE_ANGLE and the value of <param> or <params> is not
+ NONE or FRAMEBUFFER_ATTACHMENT_ANGLE the error INVALID_VALUE is
+ generated.
+
+Usage Example
+
+ /* create and bind texture */
+ glGenTextures(1, &texture);
+ glActiveTexture(GL_TEXTURE0);
+ glBindTexture(GL_TEXTURE_2D, texture);
+
+ /* specify texture parameters */
+ glTexParameteri(GL_TEXTURE_2D, GL_*, ...); /* as before */
+
+ /* specify that we'll be rendering to the texture */
+ glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_USAGE_ANGLE, GL_FRAMEBUFFER_ATTACHMENT_ANGLE);
+
+ glTexStorage2DEXT(GL_TEXTURE_2D, levels, ...); // Allocation
+ for(int level = 0; level < levels; ++level)
+ glTexSubImage2D(GL_TEXTURE_2D, level, ...); // Initialisation
+
+Issues
+
+ 1. Should there be a dynamic usage value?
+
+ DISCUSSION: We could accept a dynamic flag to indicate that a texture will
+ be updated frequently. We could map this to D3D9 dynamic textures. This would
+ allow us to avoid creating temporary surfaces when updating the texture.
+ However renderable textures cannot be dynamic in D3D9, which eliminates the
+ primary use case for this. Furthermore, the memory usage of dynamic textures
+ typically increases threefold when you lock it.
+
+ 2. Should the texture usage be an enum or a bitfield?
+
+ UNRESOLVED. Using a bitfield would allow combination of values to be specified.
+ On the other hand, if combinations are really required, additional <pnames>
+ could be added as necessary. Querying a bitfield via the GetTexParameter command
+ feels a bit odd.
+
+ 3. What should happen if TEXTURE_USAGE_ANGLE is set/changed after the texture
+ contents have been specified?
+
+ RESOLVED: It will have no effect. However, if the texture is redefined (for
+ example by TexImage2D) the new allocation will use the updated usage.
+ GetTexParameter is used to query the value of the TEXTURE_USAGE_ANGLE
+ state that was last set by TexParameter for the currently bound texture, or
+ the default value if it has never been set. There is no way to determine the
+ usage that was in effect at the time the texture was defined.
+
+Revision History
+
+ Rev. Date Author Changes
+ ---- ----------- --------- ----------------------------------------
+ 1 10 Nov 2011 dgkoch Initial revision
+ 2 10 Nov 2011 dgkoch Add overview
+
+
diff --git a/extensions/EGL_EXT_create_context_robustness.txt b/extensions/EGL_EXT_create_context_robustness.txt
new file mode 100644
index 00000000..5b627d50
--- /dev/null
+++ b/extensions/EGL_EXT_create_context_robustness.txt
@@ -0,0 +1,169 @@
+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
+
+ TBD
+
+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
diff --git a/extensions/EXT_robustness.txt b/extensions/EXT_robustness.txt
new file mode 100644
index 00000000..6f9f7056
--- /dev/null
+++ b/extensions/EXT_robustness.txt
@@ -0,0 +1,365 @@
+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
+
+ TBD
+
+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
diff --git a/extensions/EXT_texture_storage.txt b/extensions/EXT_texture_storage.txt
new file mode 100644
index 00000000..6631bae1
--- /dev/null
+++ b/extensions/EXT_texture_storage.txt
@@ -0,0 +1,1090 @@
+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
+
+ XXX - not assigned yet
+
+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