Add extension specifications

extensions/ANGLE_texture_usage.txt

+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
+   
+

extensions/EGL_EXT_create_context_robustness.txt

+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

extensions/EXT_robustness.txt

+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

extensions/EXT_texture_storage.txt

+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

src/common/version.h

 #define MAJOR_VERSION 0
 #define MINOR_VERSION 0
 #define BUILD_VERSION 0
-#define BUILD_REVISION 877
+#define BUILD_REVISION 878
 
 #define STRINGIFY(x) #x
 #define MACRO_STRINGIFY(x) STRINGIFY(x)