Name

    OES_required_internalformat

Name Strings

    GL_OES_required_internalformat

Contributors

    Aaftab Munshi
    Jeremy Sandmel
    Members of the Khronos OpenGL ES working group

Contact

    Benj Lipchak, Apple, Inc. (lipchak 'at' apple.com)
    
Notice

    Copyright (c) 2007-2013 The Khronos Group Inc. Copyright terms at
        http://www.khronos.org/registry/speccopyright.html

Status

    Complete.
    Approved by the Khronos Promoters on April 26, 2012.

Version

    Last Modified Date: January 29, 2010
    Author Revision: 0.19

Number

    XXX TBD

Dependencies

    OpenGL ES 1.0 is required.

    This extension is written against the OpenGL ES 1.1 specification.

    OpenGL ES 2.0 affects the definition of this extension.
    
    OES_framebuffer_object affects the definition of this extension.

    OES_depth_texture affects the definition of this extension.
    
    OES_depth24 and OES_depth32 affect the definition of this extension.
    
    OES_packed_depth_stencil affects the definition of this extension.

    OES_rgb8_rgba8 affects the definition of this extension.

    OES_stencil1, OES_stencil4, and OES_stencil8 affect the definition of this
    extension.
    
    OES_texture_3D affects the definition of this extension.
    
    EXT_texture_type_2_10_10_10_REV affects the definition of this extension.

Overview

    The ES 1.1 API allows an implementation to store texture data internally
    with arbitrary precision, regardless of the format and type of the data
    supplied by the application.  Similarly, ES allows an implementation to
    choose an arbitrary precision for the internal storage of image data
    allocated by glRenderbufferStorageOES.

    While this allows flexibility for implementations, it does mean that an 
    application does not have a reliable means to request the implementation 
    maintain a specific precision or to find out what precision the 
    implementation will maintain for a given texture or renderbuffer image.

    For reference, "Desktop" OpenGL uses the <internalformat> argument to 
    glTexImage*, glCopyTexImage* and glRenderbufferStorageEXT as a hint, 
    defining the particular base format and precision that the application wants 
    the implementation to maintain when storing the image data.  Further, the 
    application can choose an <internalformat> with a different base internal 
    format than the source format specified by <format>.  The implementation is
    not required to exactly match the precision specified by <internalformat>
    when choosing an internal storage precision, but it is required to match the 
    base internal format of <internalformat>.

    In addition, ES 1.1 does not allow an implementation to fail a request to
    glTexImage2D for any of the legal <format> and <type> combinations listed in
    Table 3.4, even if the implementation does not natively support data stored
    in that external <format> and <type>.  However, there are no additional
    requirements placed on the implementation.  The ES implementation is free to
    store the texture data with lower precision than originally specified, for
    instance.  Further, since ES removes the ability to query the texture object
    to find out what internal format it chose, there is no way for the
    application to find out that this has happened.

    This extension addresses the situation in two ways:
    
        1) This extension introduces the ability for an application to specify
        the desired "sized" internal formats for texture image allocation.
    
        2) This extension guarantees to maintain at least the specified
        precision of all available sized internal formats.
        
    An implementation that exports this extension is committing to support all
    of the legal values for <internalformat> in Tables 3.4, 3.4.x, and 3.4.y,
    subject to the extension dependencies described herein.  That is to say, the 
    implementation is guaranteeing that choosing an <internalformat> argument
    with a value from these tables will not cause an image allocation request to
    fail.  Furthermore, it is guaranteeing that for any sized internal format,
    the renderbuffer or texture data will be stored with at least the precision
    prescribed by the sized internal format.
    
Issues

    1.  What API should we use to allow an application to indicate it wants 
        storage of at least a certain precision for a particular source format/
        type combination?
        
        RESOLVED
        
        We use the "sized" <internalformat> enums to indicate that an
        application desires some minimum precision for internal storage and 
        that the GL should not use less than the specified precision.

        We originally had considered using a new "UNPACK" parameter for
        glPixelStorei that indicated the external <format> and <type> arguments 
        must be supported with no "downsampling" of the precision.

        However, this latter approach ran into the problem that glCopyTexImage2D 
        and glRenderbufferStorageOES don't use the pixel store "UNPACK" state 
        nor do they have external <format> or <type> arguments to indicate the 
        application's requested precision.

        Another option was to create a new set of glTexImage*, glCopyTexImage*,
        and glRenderbufferStorageOES entry points that implied a minimum
        required precision.

        However, it seems the simplest thing to do is to just use the
        <internalformat> argument for this purpose and keep the existing entry 
        points.  It's also the most compatible with desktop OpenGL code.

    2.  Should this specification make any mention of "optionally supported"
        <internalformat> values at all?  Or should we just move all of those to 
        separate defined extensions?
        
        RESOLVED, all the values for <internalformat> in Tables 3.4, 3.4.x, and
        3.4.y in this extension must be accepted by their respective commands.
        All sized formats in these tables must be stored with at least the
        corresponding minimum precision.

        Other extensions may introduce new values for <internalformat>.  If they
        do, they should modify Tables 3.4, 3.4.x, and 3.4.y.  If an 
        implementation can support the new <internalformat> values, it will
        export the extension.
        
        The primary motivation for moving "optionally supported" formats to
        their own extensions is so that a well-behaved application never gets 
        the idea that it is supposed to check for errors in order to query for 
        available functionality.  Well-behaved applications should always query
        for extension strings and other implementation-dependent state to check
        for available functionality on a particular implementation.

    3.  What should be the recommended way to add new formats in the future?
    
        RESOLVED
        
        Just like before, new extensions can add new values for <internalformat> 
        for *TexImage* and RenderbufferStorageOES.  Unless otherwise stated by
        future extensions, new sized internal formats will provide the same kind
        of minimum precision guarantees as the formats described herein.

    4.  How should we handle render vs. texture buffers?
    
        RESOLVED
        
        We have three tables in the spec, one for textures specified with 
        TexImage*, one for textures specified with CopyTexImage2D, and one for 
        renderbuffers allocated with RenderbufferStorageOES.
        
    5.  Should this extension require RGBA8?  For both texture and render?
    
        RESOLVED
        
        Yes, for both.  OpenGL ES 2.0 implementations are very likely to have 
        this support anyway, and OpenGL ES 1.x implementations can choose to 
        export this extension or not, depending on whether they support 8 bit/
        component for textures and renderbuffers.
        
        Note, this extension does not require RGB8 for renderbuffers.  
        Availability of RGB8 renderbuffers is still based on presence of the
        OES_rgb8_rgba8 extension.
        
    6.  What should this extension say, if anything, about depth and stencil
        internal formats for RenderbufferStorageOES?
        
        RESOLVED
        
        Stencil and depth formats are listed in the Table 3.4.x.  If an
        implementation that supports this extension doesn't support one or more
        of the stencil/depth format extensions then this extension behaves as if 
        those enums are NOT listed in Table 3.4.x.
        
    7.  Should we allow every combination of <format>, <type>, and
        <internalformat>?
    
        RESOLVED
        
        No, we specifically disallow conversions between "base" formats (between 
        RGBA and LUMINANCE_ALPHA, for instance).  Further, we also disallow 
        requested "expansions" to larger data types.  That is, Table 3.4.x 
        allows the user to request that the GL use a lower precision than the 
        external <type> would require, but that table does not include any 
        entries that would require the GL to use more precision than the 
        external <type> would require.

        We intentionally don't include this feature here because the
        <internalformat> represents a required minimum precision for the GL.  We
        don't want to allow an application to require more precision internally
        than they provide externally because it would necessitate a format
        conversion.  If some implementation really wants to add this 
        functionality, it would need to create an additional extension, say 
        FOO_expanded_internalformat.

        Note that in the opposite situation where an application provides higher
        precision source data and asks it to be stored at lower precision, an
        implementation is still free to store at the higher precision, thereby
        avoiding format conversion.

    8.  Should we split this extension into multiple extensions?
    
        RESOLVED

        No.  No vendor has expressed interest in subsetting these 3 features:
        
            Feature 1:  This extension allows an application to specify sized 
            <internalformats> enums for texture and render buffer image 
            allocation.

            Feature 2:  This extension allows the implementation to export a 
            list of sized <internalformats> for which it will guarantee to 
            maintain the specified minimum precision when those formats are used 
            for texture or renderbuffer image allocation.

            Feature 3:  This extension defines a minimum set of sized
            <internalformat> enums that are required to be exported by the query 
            mechanism in #2 above.

    9.  Should we add a query that lets the implementation advertise which 
        sized internal formats it supports with minimum precision?

        RESOLVED 

        No, we'll leave it to a future extension to add this mechanism if
        necessary.  Today all sized internal formats have guaranteed minimum
        precision.  For posterity, we were close to choosing query mechanism 'c'
        from the list below before we dropped the query entirely:
         
            a) a query for a single format's support like this:
         
            boolean QuerySupportOES(enum param, int count, const enum* list); 

            which takes a <list> of <count> sized internal format enums and 
            returns GL_FALSE if any of them, when used as a sized internal 
            format with the currently bound context, would result in an internal 
            format of lower precision than requested.  The <param> could be
            GL_SUPPORTED_TEXTURE_INTERNALFORMAT for querying supported texture 
            precisions and GL_SUPPORTED_RENDERBUFFER_INTERNALFORMAT for querying
            supported renderbuffer precisions.
        
            b) a query for all supported formats that the implementation can 
               guarantee minimum precision, like this:
        
            void GetSupportedInternalFormatsOES(enum param, 
                                                int* count, 
                                                enum* list);
        
            where <param> must be TEXTURE_INTERNALFORMAT or
            RENDERBUFFER_INTERNALFORMAT.  On input <count> is the maximum
            number of internal formats to return, and on output <count>
            is the number of internal formats in <list>.  On output, <list> 
            contains all the values of <internalformat> for which the 
            implementation will guarantee specified precision.  <list> will 
            contain <count> entries.
            
            c) a query of a single internalformat providing a yes/no answer:

            boolean IsPreciseInternalformatOES(enum param, enum internalformat);

            where <param> must be TEXTURE or RENDERBUFFER_OES, and
            <internalformat> is the internal format for which the app is
            checking the minimum precision storage guarantee.

    10. What is the OES_framebuffer_object interaction?  Are FBOs a 
        prerequisite (even on ES 1.1), or should we strike mention of
        renderbuffers if FBOs aren't available?

        RESOLVED

        Sized format hints and minimum precision guarantees for textures are
        useful even on implementations where FBOs aren't supported.  We won't
        make FBOs a prerequisite. 

    11. Should we add retroactive support for EXT_texture_type_2_10_10_10_REV?

        RESOLVED

        Yes.  We introduced two new sized internal formats, RGB10_A2_EXT and
        RGB10_EXT.  This format continues to be unrenderable, consistent with
        the EXT_texture_type_2_10_10_10_REV spec.  These formats join the rest
        of existing sized internal formats on the required list of formats for
        which precision is guaranteed.

    12. Do we need different token values from OpenGL?

        RESOLVED

        No. Initially some new tokens (such as ALPHA8_OES) were given new
        values, which was due to a difference in the meaning relative to
        OpenGL: in OpenGL 2.1, sized internal formats were purely hints,
        whereas in this extension they are lower bounds. However, OpenGL
        now specifies a number of formats as being "required" in the
        same sense of a lower bound on precision, and the token values
        are not changed.

New Procedures and Functions

    None.

New Types

    None.

New Tokens
    
     Accepted by the <internalformat> argument of TexImage2D, TexImage3DOES, and 
     CopyTexImage2D:
         
         ALPHA8_OES                       0x803C
         LUMINANCE8_OES                   0x8040
         LUMINANCE8_ALPHA8_OES            0x8045
         LUMINANCE4_ALPHA4_OES            0x8043
         RGB565_OES                       0x8D62
         RGB8_OES                         0x8051
         RGBA4_OES                        0x8056
         RGB5_A1_OES                      0x8057
         RGBA8_OES                        0x8058
         DEPTH_COMPONENT16_OES            0x81A5
         DEPTH_COMPONENT24_OES            0x81A6
         DEPTH_COMPONENT32_OES            0x81A7
         DEPTH24_STENCIL8_OES             0x88F0
         RGB10_EXT                        0x8052
         RGB10_A2_EXT                     0x8059
         
     Accepted by the <internalformat> argument of RenderbufferStorageOES:
         
         RGBA8_OES                        0x8058
         
Additions to Chapter 2 of the OpenGL ES 1.1 Specification (OpenGL ES Operation)

    None.

Additions to Chapter 3 of the OpenGL ES 1.1 Specification (Rasterization)

    In section 3.6.2 ("Unpacking"), p.69 (p. 60/61 of ES 2.0 spec), modify
    Table 3.4 and replace the preceding paragraph as follows:


            Format            Type                            External Bytes per Pixel Internal format
            ------            ----                            ------------------------ ---------------
            RGBA              UNSIGNED_INT_2_10_10_10_REV_EXT 4                        RGBA, RGB10_A2_EXT, RGB5_A1
            RGBA              UNSIGNED_BYTE                   4                        RGBA, RGBA8, RGB5_A1, RGBA4  
            RGB               UNSIGNED_INT_2_10_10_10_REV_EXT 4                        RGB,  RGB10_EXT, RGB8, RGB565 
            RGB               UNSIGNED_BYTE                   3                        RGB,  RGB8, RGB565         
            RGBA              UNSIGNED_SHORT_4_4_4_4          2                        RGBA, RGBA4
            RGBA              UNSIGNED_SHORT_5_5_5_1          2                        RGBA, RGB5_A1
            RGB               UNSIGNED_SHORT_5_6_5            2                        RGB,  RGB565
            LUMINANCE_ALPHA   UNSIGNED_BYTE                   2                        LUMINANCE_ALPHA, LUMINANCE8_ALPHA8, LUMINANCE4_ALPHA4
            LUMINANCE         UNSIGNED_BYTE                   1                        LUMINANCE,  LUMINANCE8
            ALPHA             UNSIGNED_BYTE                   1                        ALPHA, ALPHA8
            DEPTH_COMPONENT   UNSIGNED_SHORT                  2                        DEPTH_COMPONENT, DEPTH_COMPONENT16_OES 
            DEPTH_COMPONENT   UNSIGNED_INT                    4                        DEPTH_COMPONENT, DEPTH_COMPONENT32_OES, DEPTH_COMPONENT24_OES, DEPTH_COMPONENT16_OES
            DEPTH_STENCIL_OES UNSIGNED_INT_24_8_OES           4                        DEPTH_STENCIL_OES, DEPTH24_STENCIL8_OES

            Table 3.4: Valid combinations of <format>, <type>, and
            <internalformat> for TexImage2D and TexImage3DOES

        When calling TexImage2D or TexImage3DOES, not all combinations of 
        <format>, <type>, and <internalformat> are valid.  The valid 
        combinations accepted by the GL are defined in Table 3.4.  If TexImage2D 
        or TexImage3DOES is called with a combination of <format>, <type>, and 
        <internalformat> not listed in Table 3.4, then INVALID_OPERATION is 
        generated.
        
        In addition, only certain values for <internalformat> are valid when 
        calling RenderbufferStorageOES and CopyTexImage2D.  The valid values of 
        <internalformat> are listed in Tables 3.4.x and 3.4.y.  If
        RenderbufferStorageOES is called with a value of <internalformat> not
        listed in Table 3.4.x then INVALID_ENUM is generated.  Similarly, if
        CopyTexImage2D is called with a value of <internalformat> not listed in
        Table 3.4.y, then INVALID_ENUM is generated.

            Internal format
            ---------------
            RGBA4_OES
            RGB5_A1_OES
            RGBA8_OES
            RGB565_OES
            RGB8_OES
            STENCIL_INDEX1_OES
            STENCIL_INDEX4_OES
            STENCIL_INDEX8_OES
            DEPTH_COMPONENT16_OES
            DEPTH_COMPONENT24_OES
            DEPTH_COMPONENT32_OES
            DEPTH24_STENCIL8_OES

            Table 3.4.x:  Legal values of <internalformat> for
            RenderbufferStorageOES

            Internal format
            ---------------    
            RGBA
            RGBA4_OES
            RGB5_A1_OES
            RGBA8_OES
            RGB10_A2_EXT
            RGB
            RGB565_OES
            RGB8_OES
            RGB10_EXT
            LUMINANCE_ALPHA
            LUMINANCE4_ALPHA4_OES
            LUMINANCE8_ALPHA8_OES
            LUMINANCE
            LUMINANCE8_OES
            ALPHA
            ALPHA8_OES

            Table 3.4.y:  Legal values of <internalformat> for CopyTexImage2D

        An implementation must accept all of the values for <internalformat> 
        specified in Tables 3.4, 3.4.x, 3.4.y.  Furthermore, an implementation
        must respect the minimum precision requirements of sized internal
        formats -- those with explicit component resolutions -- by storing each
        component with at least the number of bits prescribed.

        If one of the base "unsized" formats (RGBA, RGB, LUMINANCE_ALPHA, 
        LUMINANCE, ALPHA, DEPTH_COMPONENT, or DEPTH_STENCIL_OES) is specified
        for <internalformat> to TexImage2D, TexImage3DOES, or CopyTexImage2D,
        the GL is free to choose the precision that it will maintain for the
        texture.  ES implementations are still encouraged, however, to maintain
        as much precision as possible, given the source arguments to those
        commands.

    In section 3.7.9 (3.7.10 for ES 2.0), update the definition of texture
    completeness (and cube completeness for ES 2.0 or in the presence of
    OES_texture_cube_map) to read:

        "... were each specified with the same format, type, and internal
        format."
        
Additions to Chapter 4 of the OpenGL ES 1.1 Specification (Per-Fragment 
Operations and the Frame Buffer)

    None.

Additions to Chapter 5 of the OpenGL ES 1.1 Specification (Special Functions)

    None.

Additions to Chapter 6 of the OpenGL ES 1.1 Specification (State and State 
Requests)

    None.

Additions to Appendix A of the OpenGL ES 1.1 Specification (Invariance)

    None.

Additions to the AGL/EGL/GLX/WGL Specifications

    None.

GLX Protocol

    XXX TBD

Errors

   If TexImage2D or TexImage3DOES is called with a combination of <format>, 
   <type>, and <internalformat> not listed in Table 3.4, then INVALID_OPERATION
   is generated.

   If RenderbufferStorageOES or CopyTexImage2D is called with a value of
   <internalformat> not listed in Table 3.4.x or 3.4.y, respectively, then 
   INVALID_ENUM is generated.
   
New State

    None.

New Implementation Dependent State

    None.
    
Dependencies on OpenGL ES 2.0

    If OpenGL ES 2.0 is supported, the following tokens do not have the
    "_OES" suffix: RGB565, RGBA4, RGB5_A1, DEPTH_COMPONENT16, STENCIL_INDEX8,
    and RENDERBUFFER.  Also, RenderbufferStorage does not have the "OES" suffix.

Dependencies on OES_depth_texture
    
    If OES_depth_texture is not supported, then all references to
    DEPTH_COMPONENT as a legal value for <format> when calling TexImage2D and 
    TexImage3DOES should be deleted.

Dependencies on OES_depth24 and OES_depth32

    If OES_depth24 is not supported, then all references to
    DEPTH_COMPONENT24_OES should be deleted.

    If OES_depth32 is not supported, then all references to
    DEPTH_COMPONENT32_OES should be deleted.

Dependencies on OES_framebuffer_object

    If OES_framebuffer_object is not supported and OpenGL ES 2.0 is not 
    supported, then all references to RENDERBUFFER_OES and renderbuffers should
    be deleted, including Table 3.4.x.

Dependencies on OES_packed_depth_stencil
    
    If OES_packed_depth_stencil is not supported, then all references to
    DEPTH_STENCIL_OES, DEPTH24_STENCIL8_OES, and UNSIGNED_INT_24_8_OES should be 
    deleted.

Dependencies on OES_rgb8_rgba8

    If OES_rgb8_rgba8 is not supported, then references to RGB8_OES as a 
    renderbuffer format in Table 3.4.x should be deleted.

Dependencies on OES_stencil1, OES_stencil4, and OES_stencil8 

    If OES_stencil1 is not supported, then all references to STENCIL_INDEX1_OES
    should be deleted.

    If OES_stencil4 is not supported, then all references to STENCIL_INDEX4_OES
    should be deleted.

    If OES_stencil8 is not supported and OpenGL ES 2.0 is not supported, then 
    all references to STENCIL_INDEX8_OES should be deleted.

Dependencies on OES_texture_3D

    If OES_texture_3D is not supported, then all references to TexImage3DOES 
    should be deleted.

Dependencies on EXT_texture_type_2_10_10_10_REV

    If EXT_texture_type_2_10_10_10_REV is not supported, then all references to
    RGB10_A2_EXT, RGB10_EXT, and UNSIGNED_INT_2_10_10_10_REV_EXT should be
    deleted.

Sample Code

    // ====================================================================
    // Example 1: 
    // An application that requires support for RGBA with >= 8888 storage
    // can indicate so by simply checking for the OES_required_internalformat
    // extension string, since RGBA8_OES availability is a prerequisite.
    // ====================================================================
    
    // First, check for presence of this extension.
    bool reqSupportAvailable = 
        MyExtensionQuery("GL_OES_required_internalformat");
    if (!reqSupportAvailable)
    {
        printf("No support for GL_OES_required_internalformat!\n");
        exit(1);
    }

    // This texture is guaranteed to be stored with at least 8-bit per component
    glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA8_OES, 32, 32, 0,
                 GL_RGBA, GL_UNSIGNED_BYTE, myTexelData);

    // ====================================================================
    // Example 2: 
    // An application that requires support for DEPTH_COMPONENT with >= 32 bit
    // storage can indicate so by checking for both OES_required_internalformat
    // and OES_depth32 extension strings.  That will guarantee minimum precision
    // for 32-bit depth values stored in renderbuffers.  If the application also
    // needs 32-bit depth stored in textures, it can check for the 
    // OES_depth_texture extension, too.
    // ====================================================================

    // First, check for presence of this extension.
    bool reqSupportAvailable = CheckExtension("GL_OES_required_internalformat");
    if (!reqSupportAvailable)
    {
        printf("No support for GL_OES_required_internalformat.\n");
        printf("Minimum precision guarantees cannot be made!\n");
        exit(1);
    }
    
    // Now check for the presence of the depth32 extension.
    bool depth32_available = CheckExtension("GL_OES_depth32");
    if (!depth32_available)
    {
        printf("No support for OES_depth32.\n");
        printf("32-bit depth renderbuffers not available!\n");
        exit(1);
    }

    // We're now guaranteed minimum 32-bit depth renderbuffers
    glRenderbufferStorageOES(GL_RENDERBUFFER_OES, GL_DEPTH_COMPONENT32_OES,
                             32, 32);

    // Now check for the presence of the depth texture extension.
    bool depth_texture_available = CheckExtension("GL_OES_depth_texture");
    if (!depth_texture_available)
    {
        printf("No support for OES_depth_texture.\n");
        printf("32-bit depth textures not available!\n");
        exit(1);
    }

    // We're now guaranteed minimum 32-bit depth textures
    glTexImage2D(GL_TEXTURE_2D, 0, GL_DEPTH_COMPONENT32_OES, 32, 32, 0,
                 GL_DEPTH_COMPONENT, GL_UNSIGNED_INT, myD32TexelData);

Revision History

    0.19, 01/29/2010, bmerry
    - changed token values for six formats where they were different
      from equivalent OpenGL tokens, and added issue 12

    0.18, 11/26/2008, benj
    - RGBA8 is mandated as a renderbuffer format, while RGB8 is only available
      if OES_rgb8_rgba8 is present.

    0.17, 11/19/2008, benj
    - treat OES_rgb8_rgba8 as optional like other renderbuffer format extensions
    - update Dependencies section
    - assign enum values for new tokens
    - fix minor typos

    0.16, 11/03/2008, benj
    - remove query mechanism since all sized internal formats have guaranteed
      minimum precision today
    - mention OES_rgb8_rgba8 requirement under Dependencies section
    - remove more tokens introduced by other extensions from New Tokens
    - update overview, issues list, and sample code

    0.15, 10/29/2008, benj
    - fix sample code bugs reported by Acorn
    - firm up the definition of texture completeness, requested by Acorn

    0.14, 10/29/2008, benj
    - fix spec bug reported by Ben in New Tokens section: split up token list
    - remove unrenderable RGB10_A2_EXT and RGB10_EXT formats from Table 3.4.x
    - get rid of gl, GL, and GL_ prefixes
    - switch query mechanism to new glIsRespectedInternalFormat
    - update issues list and sample code

    0.13, 10/28/2008, benj
    - major overhaul
    - remove double pointer from query command
    - fix extension names for depth and stencil extensions
    - sync up with latest 10/10/10/2 texture and depth texture extensions
    - don't allow RGBA8 or RGBA4 internal formats for 10/10/10/2 textures
      since that would require expanding the alpha channel
    - add OES suffix to most tokens, EXT for 10/10/10/2 tokens
    - remove tokens that aren't introduced by this extension from New Tokens
    - add missing ALPHA8_OES and DEPTH_COMPONENT16_OES to New Tokens
    - remove unsized formats from Table 3.4.x, add missing DEPTH_COMPONENT16
    - remove L, A, and LA formats from Table 3.4.x and Table 3.6.x
      RENDERBUFFER_OES section
    - add interactions with ES 2.0 and OES_framebuffer_object
    - change error for invalid combination of format/type/internalformat from
      INVALID_ENUM to INVALID_OPERATION
    - reformat for 80 columns
    - update issues list and sample code

    0.12, 02/27/2008, jsandmel
    - added glGetSupportedInternalFormatsOES to new procedures section
    - fixed typo in argument name for <internalformatlist>

    0.11, 02/05/2008, jsandmel
    - reworked API after the Portland F2F
    - added query for supported internal formats
    - updated section 3.6.2.1 on how the required list works
    - added table 3.6.x for the list of required <internalformats>
    - added a sample code example of the query for supported <internalformats>
    - added dependency on packed depth stencil

    0.10, 10/16/2007, jsandmel
    - fixed several typos and non-ascii characters, no functional changes

    0.9, 10/15/2007, jsandmel
    - added issues 12 and 13
    - included Acorn's suggestion for a query for supported formats that
      respect the minimum precision guarantee

    0.8, 05/27/2007, jsandmel
    - added contributors section
    - updated spec with recent group decisions
    - added explicit dependencies on OES_stencil, OES_depth extensions
    - split table 3.4.x into two tables: one for RenderbufferStorageOES
      and one for CopyTexImage since you can create a depth/stencil
      renderbuffer but not texture.

    0.7, 05/21/2007, jsandmel
    - updated spec with recent group decisions
    - removed concept of "optionally supported" extensions
    - added second table for RenderBuffer storage

    0.6, 05/03/2007, jsandmel
    - fixed some typos refering to OpenGL 1.5 spec that should be ES 1.1 spec

    0.5, 4/28/2007, jsandmel
    - changed a few more references to LUMINANCE/ALPHA instead of L/A
    - also clarified overview wrt to required <internalformat> semantics

    0.4, 4/25/2007, jsandmel
    - corrected table 3.4 and 3.4x to use LUMINANCE/ALPHA instead of L/A

    0.3, 4/24/2007, jsandmel
    - added issue 5 to discuss whether we should move all the "optionally
      supported" <internalformat> values to their own extensions

    0.2, 4/24/2007, jsandmel
    - fixed up a few typos and lingering references to UNPACK state

    0.1, 4/23/2007, jsandmel
    - switch to start using <internalformat> instead of adding a new
      UNPACK parameter.
    
    0.0, 4/17/2007, jsandmel
    - initial revision