back  Return to list

GL_EXT_texture_integer
homeprevnext Name
  
    EXT_texture_integer  
  
homeprevnext Name Strings
  
    GL_EXT_texture_integer  
  
homeprevnext Contact
  
    Michael Gold, NVIDIA Corporation (gold 'at' nvidia.com)  
    Pat Brown, NVIDIA Corporation (pbrown 'at' nvidia.com)  
  
homeprevnext Status
  
    Shipping for GeForce 8 Series (November 2006)  
  
homeprevnext Version
  
    Last Modified Date:         07/15/2006  
    NVIDIA Revision:            5  
  
homeprevnext Number
  
    343  
  
homeprevnext Dependencies
  
    OpenGL 2.0 is required.  
  
    NV_gpu_program4 or EXT_gpu_shader4 is required.  
  
    ARB_texture_float affects the definition of this extension.  
  
    ARB_color_buffer_float affects the definition of this extension.  
  
    EXT_framebuffer_object affects the definition of this extension.  
  
    This extension is written against the OpenGL 2.0 specification.  
  
homeprevnext Overview
  
    Fixed-point textures in unextended OpenGL have integer components,  
    but those values are taken to represent floating-point values in  
    the range [0,1].  These integer components are considered  
    "normalized" integers.  When such a texture is accessed by a  
    shader or by fixed-function fragment processing, floating-point  
    values are returned.  
  
    This extension provides a set of new "unnormalized" integer texture  
    formats.  Formats with both signed and unsigned integers are provided.  In  
    these formats, the components are treated as true integers.  When such  
    textures are accessed by a shader, actual integer values are returned.  
  
    Pixel operations that read from or write to a texture or color  
    buffer with unnormalized integer components follow a path similar  
    to that used for color index pixel operations, except that more  
    than one component may be provided at once.  Integer values flow  
    through the pixel processing pipe, and no pixel transfer  
    operations are performed.  Integer format enumerants used for such  
    operations indicate unnormalized integer data.  
  
    Textures or render buffers with unnormalized integer formats may also be  
    attached to framebuffer objects to receive fragment color values written  
    by a fragment shader.  Per-fragment operations that require floating-point  
    color components, including multisample alpha operations, alpha test,  
    blending, and dithering, have no effect when the corresponding colors are  
    written to an integer color buffer.  The NV_gpu_program4 and  
    EXT_gpu_shader4 extensions add the capability to fragment programs and  
    fragment shaders to write signed and unsigned integer output values.  
  
    This extension does not enforce type consistency for texture accesses or  
    between fragment shaders and the corresponding framebuffer attachments.  
    The results of a texture lookup from an integer texture are undefined:  
  
      * for fixed-function fragment processing, or  
  
      * for shader texture accesses expecting floating-point return values.    
  
    The color components used for per-fragment operations and written into a  
    color buffer are undefined:  
  
      * for fixed-function fragment processing with an integer color buffer,  
  
      * for fragment shaders that write floating-point color components to an  
        integer color buffer, or  
  
      * for fragment shaders that write integer color components to a color  
        buffer with floating point or normalized integer components.  
  
  
homeprevnext New Procedures and Functions
  
    void ClearColorIiEXT ( int r, int g, int b, int a );  
    void ClearColorIuiEXT ( uint r, uint g, uint b, uint a );  
    void TexParameterIivEXT( enum target, enum pname, int *params );  
    void TexParameterIuivEXT( enum target, enum pname, uint *params );  
    void GetTexParameterIivEXT ( enum target, enum pname, int *params);  
    void GetTexParameterIuivEXT ( enum target, enum pname, uint *params);  
  
homeprevnext New Tokens
  
    Accepted by the <pname> parameters of GetBooleanv, GetIntegerv,  
    GetFloatv, and GetDoublev:  
D  
        RGBA_INTEGER_MODE_EXT                           0x8D9E  
  
    Accepted by the <internalFormat> parameter of TexImage1D,  
    TexImage2D, and TexImage3D:  
  
        RGBA32UI_EXT                                    0x8D70  
        RGB32UI_EXT                                     0x8D71  
        ALPHA32UI_EXT                                   0x8D72  
        INTENSITY32UI_EXT                               0x8D73  
        LUMINANCE32UI_EXT                               0x8D74  
        LUMINANCE_ALPHA32UI_EXT                         0x8D75  
  
        RGBA16UI_EXT                                    0x8D76  
        RGB16UI_EXT                                     0x8D77  
        ALPHA16UI_EXT                                   0x8D78  
        INTENSITY16UI_EXT                               0x8D79  
        LUMINANCE16UI_EXT                               0x8D7A  
        LUMINANCE_ALPHA16UI_EXT                         0x8D7B  
  
        RGBA8UI_EXT                                     0x8D7C  
        RGB8UI_EXT                                      0x8D7D  
        ALPHA8UI_EXT                                    0x8D7E  
        INTENSITY8UI_EXT                                0x8D7F  
        LUMINANCE8UI_EXT                                0x8D80  
        LUMINANCE_ALPHA8UI_EXT                          0x8D81  
  
        RGBA32I_EXT                                     0x8D82  
        RGB32I_EXT                                      0x8D83  
        ALPHA32I_EXT                                    0x8D84  
        INTENSITY32I_EXT                                0x8D85  
        LUMINANCE32I_EXT                                0x8D86  
        LUMINANCE_ALPHA32I_EXT                          0x8D87  
  
        RGBA16I_EXT                                     0x8D88  
        RGB16I_EXT                                      0x8D89  
        ALPHA16I_EXT                                    0x8D8A  
        INTENSITY16I_EXT                                0x8D8B  
        LUMINANCE16I_EXT                                0x8D8C  
        LUMINANCE_ALPHA16I_EXT                          0x8D8D  
  
        RGBA8I_EXT                                      0x8D8E  
        RGB8I_EXT                                       0x8D8F  
        ALPHA8I_EXT                                     0x8D90  
        INTENSITY8I_EXT                                 0x8D91  
        LUMINANCE8I_EXT                                 0x8D92  
        LUMINANCE_ALPHA8I_EXT                           0x8D93  
  
    Accepted by the <format> parameter of TexImage1D, TexImage2D,  
    TexImage3D, TexSubImage1D, TexSubImage2D, TexSubImage3D,  
    DrawPixels and ReadPixels:  
  
        RED_INTEGER_EXT                                 0x8D94  
        GREEN_INTEGER_EXT                               0x8D95  
        BLUE_INTEGER_EXT                                0x8D96  
        ALPHA_INTEGER_EXT                               0x8D97  
        RGB_INTEGER_EXT                                 0x8D98  
        RGBA_INTEGER_EXT                                0x8D99  
        BGR_INTEGER_EXT                                 0x8D9A  
        BGRA_INTEGER_EXT                                0x8D9B  
        LUMINANCE_INTEGER_EXT                           0x8D9C  
        LUMINANCE_ALPHA_INTEGER_EXT                     0x8D9D  
  
homeprevnext Additions to Chapter 3 of the OpenGL 2.0 Specification (Rasterization)
  
    Modify Section 3.6.4 (Rasterization of Pixel Rectangles), p. 126:  
  
    (modify the last paragraph, p. 126)  
    Pixels are drawn using  
  
        void DrawPixels( sizei width, sizei height, enum format,  
            enum type, void *data );  
  
    <format> is a symbolic constant indicating what the values in  
    memory represent.  <width> and <height> are the width and height,  
    respectively, of the pixel rectangle to be drawn. <data> is a  
    pointer to the data to be drawn. These data are represented with  
    one of seven GL data types, specified by <type>. The  
    correspondence between the twenty type token values and the GL  
    data types they indicate is given in table 3.5. If the GL is in  
    color index mode and <format> is not one of COLOR_INDEX,  
    STENCIL_INDEX, or DEPTH_COMPONENT, then the error  
    INVALID_OPERATION occurs.  If the GL is in RGBA mode and the color  
    buffer is an integer format and no fragment shader is active, the  
    error INVALID_OPERATION occurs.  If <type> is BITMAP and <format>  
    is not COLOR_INDEX or STENCIL_INDEX then the error INVALID_ENUM  
    occurs.  If <format> is one of the integer component formats as  
    defined in table 3.6, and <type> is FLOAT, then the error  
    INVALID_ENUM occurs.  Some additional constraints on the  
    combinations of format and type values that are accepted is  
    discussed below.  
  
    (add the following to table 3.6, p. 129)  
    Format Name                  Element Meaning and Order      Target Buffer  
    ------ ----                  ------- ------- --- -----      ------ ------  
    RED_INTEGER_EXT              iR                             Color  
    GREEN_INTEGER_EXT            iG                             Color  
    BLUE_INTEGER_EXT             iB                             Color  
    ALPHA_INTEGER_EXT            iA                             Color  
    RGB_INTEGER_EXT              iR, iG, iB                     Color  
    RGBA_INTEGER_EXT             iR, iG, iB, iA                 Color  
    BGR_INTEGER_EXT              iB, iG, iR                     Color  
    BGRA_INTEGER_EXT             iB, iG, iR, iA                 Color  
    LUMINANCE_INTEGER_EXT        iLuminance                     Color  
    LUMINANCE_ALPHA_INTEGER_EXT  iLuminance, iA                 Color  
  
    Table 3.6: DrawPixels and ReadPixels formats. The second column  
    gives a description of and the number and order of elements in a  
    group. Unless specified as an index, formats yield components.  
    Components are floating-point unless prefixed with the letter 'i'  
    which indicates they are integer.  
  
    (modify first paragraph, p. 129)  
    Data are taken from host memory as a sequence of signed or  
    unsigned bytes (GL data types byte and ubyte), signed or unsigned  
    short integers (GL data types short and ushort), signed or  
    unsigned integers (GL data types int and uint), or floating point  
    values (GL data type float). These elements are grouped into sets  
    of one, two, three, or four values, depending on the format, to  
    form a group.  Table 3.6 summarizes the format of groups obtained  
    from memory; it also indicates those formats that yield indices  
    and those that yield floating-point or integer components.  
  
    (modify the last paragraph, p. 135)  
  
    Conversion to floating-point  
  
    This step applies only to groups of floating-point components. It  
    is not performed on indices or integer components.  
  
    (modify the third paragraph, p. 136)  
    Final Expansion to RGBA  
  
    This step is performed only for non-depth component groups. Each  
    group is converted to a group of 4 elements as follows: if a group  
    does not contain an A element, then A is added and set to 1 for  
    integer components or 1.0 for floating-point components. If any of  
    R, G, or B is missing from the group, each missing element is  
    added and assigned a value of 0 for integer components or 0.0 for  
    floating-point components.  
  
    (modify the last paragraph, p. 136)  
    Final Conversion  
  
    For a color index, final conversion consists of masking the bits  
    of the index to the left of the binary point by 2^n - 1, where n is  
    the number of bits in an index buffer.  For floating-point RGBA  
    components, each element is clamped to [0, 1]. The resulting  
    values are converted to fixed-point according to the rules given  
    in section 2.14.9 (Final Color Processing).  For integer RGBA  
    components, no conversion is applied.  For a depth component, an  
    element is first clamped to [0, 1] and then converted to  
    fixed-point as if it were a window z value (see section 2.11.1,  
    Controlling the Viewport).  Stencil indices are masked by 2^n - 1,  
    where n is the number of bits in the stencil buffer.  
  
    Modify Section 3.6.5 (Pixel Transfer Operations), p. 137  
  
    (modify last paragraph, p. 137)  
    The GL defines five kinds of pixel groups:  
  
    1. Floating-point RGBA component: Each group comprises four color  
       components in floating point format: red, green, blue, and  
       alpha.  
  
    2. Integer RGBA component: Each group comprises four color  
       components in integer format: red, green, blue, and alpha.  
  
    3. Depth component: Each group comprises a single depth component.  
  
    4. Color index: Each group comprises a single color index.  
  
    5. Stencil index: Each group comprises a single stencil index.  
  
    (modify second paragraph, p. 138)  
    Each operation described in this section is applied sequentially  
    to each pixel group in an image. Many operations are applied only  
    to pixel groups of certain kinds; if an operation is not  
    applicable to a given group, it is skipped.  None of the  
    operations defined in this section affect integer RGBA component  
    pixel groups.  
  
    Modify Section 3.8 (Texturing), p. 149  
  
    (insert between the first and second paragraphs, p. 150)  
    The internal data type of a texture may be fixed-point,  
    floating-point, signed integer or unsigned integer, depending on  
    the internalformat of the texture.  The correspondence between  
    internalformat and the internal data type is given in table 3.16.  
    Fixed-point and floating-point textures return a floating-point  
    value and integer textures return signed or unsigned integer  
    values.  When a fragment shader is active, the shader is  
    responsible for interpreting the result of a texture lookup as the  
    correct data type, otherwise the result is undefined.  Fixed  
    functionality assumes floating-point data, hence the result of  
    using fixed functionality with integer textures is undefined.  
  
    Modify Section 3.8.1 (Texture Image Specification), p. 150  
  
    (modify second paragraph, p. 151) The selected groups are  
    processed exactly as for DrawPixels, stopping just before final  
    conversion.  If the <internalformat> of the texture is integer,  
    the components are clamped to the representable range of the  
    internal format: for signed formats, this is [-2^(n-1), 2^(n-1)-1]  
    where n is the number of bits per component; for unsigned formats,  
    the range is [0, 2^n-1].  For R, G, B, and A, if the  
    <internalformat> of the texture is fixed-point, the components are  
    clamped to [0, 1].  Otherwise, the components are not modified.  
  
    (insert between paragraphs five and six, p. 151)  
    Textures with integer internal formats (table 3.16) require  
    integer data.  The error INVALID_OPERATION is generated if the  
    internal format is integer and <format> is not one of the integer  
    formats listed in table 3.6, or if the internal format is not  
    integer and <format> is an integer format, or if <format> is an  
    integer format and <type> is FLOAT.  
  
    (add the following to table 3.16, p. 154)  
    Sized                   Base              R    G    B    A    L    I  
    Internal Format         Internal Format  bits bits bits bits bits bits  
    ----------------------- ---------------  ---- ---- ---- ---- ---- ----  
    ALPHA8I_EXT             ALPHA                             i8  
    ALPHA8UI_EXT            ALPHA                            ui8  
    ALPHA16I_EXT            ALPHA                            i16  
    ALPHA16UI_EXT           ALPHA                           ui16  
    ALPHA32I_EXT            ALPHA                            i32  
    ALPHA32UI_EXT           ALPHA                           ui32  
    LUMINANCE8I_EXT         LUMINANCE                              i8  
    LUMINANCE8UI_EXT        LUMINANCE                             ui8  
    LUMINANCE16I_EXT        LUMINANCE                             i16  
    LUMINANCE16UI_EXT       LUMINANCE                            ui16  
    LUMINANCE32I_EXT        LUMINANCE                             i32  
    LUMINANCE32UI_EXT       LUMINANCE                            ui32  
    LUMINANCE_ALPHA8I_EXT   LUMINANCE_ALPHA                   i8   i8  
    LUMINANCE_ALPHA8UI_EXT  LUMINANCE_ALPHA                  ui8  ui8  
    LUMINANCE_ALPHA16I_EXT  LUMINANCE_ALPHA                  i16  i16  
    LUMINANCE_ALPHA16UI_EXT LUMINANCE_ALPHA                 ui16 ui16  
    LUMINANCE_ALPHA32I_EXT  LUMINANCE_ALPHA                  i32  i32  
    LUMINANCE_ALPHA32UI_EXT LUMINANCE_ALPHA                 ui32 ui32  
    INTENSITY8I_EXT         INTENSITY                                   i8  
    INTENSITY8UI_EXT        INTENSITY                                  ui8  
    INTENSITY16I_EXT        INTENSITY                                  i16  
    INTENSITY16UI_EXT       INTENSITY                                 ui16  
    INTENSITY32I_EXT        INTENSITY                                  i32  
    INTENSITY32UI_EXT       INTENSITY                                 ui32  
    RGB8I_EXT               RGB                i8   i8   i8  
    RGB8UI_EXT              RGB               ui8  ui8  ui8  
    RGB16I_EXT              RGB               i16  i16  i16  
    RGB16UI_EXT             RGB              ui16 ui16 ui16  
    RGB32I_EXT              RGB               i32  i32  i32  
    RGB32UI_EXT             RGB              ui32 ui32 ui32  
    RGBA8I_EXT              RGBA               i8   i8   i8   i8  
    RGBA8UI_EXT             RGBA              ui8  ui8  ui8  ui8  
    RGBA16I_EXT             RGBA              i16  i16  i16  i16  
    RGBA16UI_EXT            RGBA             ui16 ui16 ui16 ui16  
    RGBA32I_EXT             RGBA              i32  i32  i32  i32  
    RGBA32UI_EXT            RGBA             ui32 ui32 ui32 ui32  
  
    Table 3.16: Correspondence of sized internal formats to base  
    internal formats, internal data type and desired component  
    resolutions for each sized internal format.  The component  
    resolution prefix indicates the internal data type: <f> is  
    floating point, <i> is signed integer, <ui> is unsigned integer,  
    and no prefix is fixed-point.  
  
  
    Modify Section 3.8.2 (Alternate Texture Image Specification  
    Commands), p. 159:  
  
    (modify the second paragraph, p. 159)  
    The error INVALID_OPERATION is generated if depth component data  
    is required and no depth buffer is present, or if integer RGBA  
    data is required and the format of the current color buffer is not  
    integer, or if floating-point or fixed-point RGBA data is required  
    and the format of the current color buffer is integer.  
  
    Modify Section 3.8.4 (Texture Parameters), p. 166:  
  
    Various parameters control how the texture array is treated when  
    specified or changed, and when applied to a fragment. Each  
    parameter is set by calling  
  
        void TexParameter{if}( enum target, enum pname, T param );  
        void TexParameter{if}v( enum target, enum pname, T params );  
        void TexParameterIivEXT( enum target, enum pname, int *params );  
        void TexParameterIuivEXT( enum target, enum pname, uint *params );  
  
    <target> is the target, either TEXTURE_1D, TEXTURE_2D, TEXTURE_3D,  
    or TEXTURE_CUBE_MAP. <pname> is a symbolic constant indicating the  
    parameter to be set; the possible constants and corresponding  
    parameters are summarized in table 3.19. In the first form of the  
    command, <param> is a value to which to set a single-valued  
    parameter; in the second and third forms of the command, <params>  
    is an array of parameters whose type depends on the parameter  
    being set.  
  
    If the value for TEXTURE_PRIORITY is specified as an integer, the  
    conversion for signed integers from table 2.9 is applied to  
    convert the value to floating-point.  The floating point value of  
    TEXTURE_PRIORITY is clamped to lie in [0, 1].  
  
    If the values for TEXTURE_BORDER_COLOR are specified with  
    TexParameterIivEXT or TexParameterIuivEXT, the values are  
    unmodified and stored with an internal data type of integer.  If  
    specified with TexParameteriv, the conversion for signed integers  
    from table 2.9 is applied to convert these values to  
    floating-point.  Otherwise the values are unmodified and stored as  
    floating-point.  
  
  
  
    (modify table 3.19, p. 167)  
    Name                  Type         Legal Values  
    ----                  ----         ------------  
    TEXTURE_BORDER_COLOR  4 floats or  any 4 values  
                          4 ints or  
                          4 uints  
  
    Table 3.19: Texture parameters and their values.  
  
    Modify Section 3.8.8 (Texture Minification), p. 170  
  
    (modify last paragraph, p. 174)  
  
    ... If the texture contains color components, the values of  
    TEXTURE_BORDER_COLOR are interpreted as an RGBA color to match the  
    texture's internal format in a manner consistent with table 3.15.  
    The internal data type of the border values must be consistent  
    with the type returned by the texture as described in section 3.8,  
    or the result is undefined.  The border values for texture  
    components stored as fixed-point values are clamped to [0, 1]  
    before they are used.  If the texture contains depth components,  
    the first component of TEXTURE_BORDER_COLOR is interpreted as a  
    depth value  
  
    Modify Section 3.8.10 (Texture Completeness), p. 177:  
  
    (add to the requirements for one-, two-, or three-dimensional  
    textures)  
    If the internalformat is integer, TEXTURE_MAG_FILTER must be  
    NEAREST and TEXTURE_MIN_FILTER must be NEAREST or  
    NEAREST_MIPMAP_NEAREST.  
      
    Modify Section 3.11.2 (Shader Execution), p. 194  
  
    (modify Shader Outputs, first paragraph, p. 196)  
    ... These are gl_FragColor, gl_FragData[n], and gl_FragDepth.  If  
    fragment clamping is enabled and the color buffer has a  
    fixed-point or floating-point format, the final fragment color  
    values or the final fragment data values written by a fragment  
    shader are clamped to the range [0, 1].  If fragment clamping is  
    disabled or the color buffer has an integer format, the final  
    fragment color values or the final fragment data values are not  
    modified.  The final fragment depth...  
  
    (insert between the first paragraph and second paragraphs of  
    "Shader Outputs", p. 196)  
    Colors values written by the fragment shader may be floating-  
    point, signed integer or unsigned integer.  If the color buffer  
    has a fixed-point format, the color values are assumed to be  
    floating-point and are converted to fixed-point as described in  
    section 2.14.9; otherwise no type conversion is applied.  If the  
    values written by the fragment shader do not match the format(s)  
    of the corresponding color buffer(s), the result is undefined.  
  
  
homeprevnext Additions to Chapter 4 of the OpenGL 2.0 Specification (Per-Fragment Operations and the Frame Buffer)
  
    Modify Chapter 4 Introduction, (p. 198)  
  
    (modify third paragraph, p. 198)  
    Color buffers consist of unsigned integer color indices, R, G, B  
    and optionally A floating-point components represented as  
    fixed-point unsigned integer or floating-point values, or R, G, B  
    and optionally A integer components represented as signed or  
    unsigned integer values.  The number of bitplanes...  
  
    Modify Section 4.1.3 (Multisample Fragment Operations), p. 200  
  
    (modify the second paragraph in this section)  
    ... If SAMPLE_ALPHA_TO_COVERAGE is enabled and the color buffer  
    has a fixed-point or floating-point format, a temporary coverage  
    value is generated ...  
  
    Modify Section 4.1.4 (Alpha Test), p. 201  
  
    (modify the first paragraph in this section)      
    This step applies only in RGBA mode and only if the color buffer  
    has a fixed-point or floating-point format. In color index mode or  
    if the color buffer has an integer format, proceed to the next  
    operation. The alpha test discards ...  
  
    Modify Section 4.1.8 (Blending), p. 205  
  
    (modify the second paragraph, p. 206)  
    ... Blending is dependent on the incoming fragment's alpha value  
    and that of the corresponding currently stored pixel. Blending  
    applies only in RGBA mode and only if the color buffer has a  
    fixed-point or floating-point format; in color index mode or if  
    the color buffer has an integer format, it is bypassed. ...  
  
    Modify Section 4.2.3 (Clearing the Buffers), p. 215  
  
       void ClearColor(float r, float g, float b, float a);  
  
    sets the clear value for fixed-point and floating-point color  
    buffers in RGBA mode.  The specified components are stored as  
    floating-point values.  
  
       void ClearColorIiEXT(int r, int g, int b, int a);  
       void ClearColorIuiEXT(uint r, uint g, uint b, uint a);  
  
    set the clear value for signed integer and unsigned integer color  
    buffers, respectively, in RGBA mode.  The specified components are  
    stored as integer values.  
  
    (add to the end of first partial paragraph, p. 217) ... then a  
    Clear directed at that buffer has no effect.  When fixed-point  
    RGBA color buffers are cleared, the clear color values are assumed  
    to be floating-point and are clamped to [0,1] before being  
    converted to fixed-point according to the rules of section 2.14.9.  
    The result of clearing fixed-point or floating-point color buffers  
    is undefined if the clear color was specified as integer values.  
    The result of when clearing integer color buffers is undefined if  
    the clear color was specified as floating-point values.  
  
    Modify Section 4.3.2 (Reading Pixels), p. 219  
  
    (append to the last paragraph, p. 221)  
    The error INVALID_OPERATION occurs if <format> is an integer  
    format and the color buffer is not an integer format, or if the  
    color buffer is an integer format and <format> is not.  The error  
    INVALID_ENUM occurs if <format> is an integer format and <type> is  
    FLOAT.  
  
    (modify the first paragraph, p. 222)  
    ... For a fixed-point color buffer, each element is taken to be a  
    fixed-point value in [0, 1] with m bits, where m is the number of  
    bits in the corresponding color component of the selected buffer  
    (see section 2.14.9).  For an integer or floating-point color  
    buffer, the elements are unmodified.  
  
    (modify the section labeled "Conversion to L", p. 222)  
    This step applies only to RGBA component groups.  If the format is  
    either LUMINANCE or LUMINANCE_ALPHA, a value L is computed as  
  
        L = R + G + B  
  
    otherwise if the format is either LUMINANCE_INTEGER_EXT or  
    LUMINANCE_ALPHA_INTEGER_EXT, L is computed as  
  
        L = R  
  
    where R, G, and B are the values of the R, G, and B  
    components. The single computed L component replaces the R, G, and  
    B components in the group.  
  
    (modify the section labeled "Final Conversion", p. 222)  
  
    For a floating-point RGBA color, each component is first clamped  
    to [0, 1]. Then the appropriate conversion formula from table 4.7  
    is applied to the component.  For an integer RGBA color, each  
    component is clamped to the representable range of <type>.  
  
  
homeprevnext Additions to Chapter 6 of the OpenGL 2.0 Specification (State and State Requests)
  
    Modify Section 6.1.3 (Enumerated Queries), p. 246  
  
    (insert in the list of query functions, p. 246)  
    void GetTexParameterIivEXT( enum target, enum value, int *data );  
    void GetTexParameterIuivEXT( enum target, enum value, uint *data );  
  
    (modify the second paragraph, p. 247)  
    ... For GetTexParameter, value must be either TEXTURE_RESIDENT, or  
    one of the symbolic values in table 3.19.  Querying <value>  
    TEXTURE_BORDER_COLOR with GetTexParameterIivEXT or  
    GetTexParameterIuivEXT returns the border color values as signed  
    integers or unsigned integers, respectively; otherwise the values  
    are returned as described in section 6.1.2.  If the border color  
    is queried with a type that does not match the original type with  
    which it was specified, the result is undefined.  The <lod>  
    argument ...  
  
    (add to end of third paragraph, p. 247) Queries with a <value> of  
    TEXTURE_RED_TYPE_ARB, TEXTURE_GREEN_TYPE_ARB, TEXTURE_BLUE_TYPE_ARB,  
    TEXTURE_ALPHA_TYPE_ARB, TEXTURE_LUMINANCE_TYPE_ARB,  
    TEXTURE_INTENSITY_TYPE_ARB, or TEXTURE_DEPTH_TYPE_ARB, return the data  
    type used to store the component.  Values of NONE,  
    UNSIGNED_NORMALIZED_ARB, FLOAT, INT, or UNSIGNED_INT, indicate missing,  
    unsigned normalized integer, floating-point, signed unnormalized integer,  
    and unsigned unnormalized integer components, respectively.  
  
  
homeprevnext GLX Protocol
  
    TBD  
  
homeprevnext Dependencies on ARB_texture_float
  
    The following changes should be made if ARB_texture_float is not  
    supported:  
  
    The references to floating-point data types in section 3.8, p. 150  
    should be deleted.  
  
    The language in section 3.8.1 should indicate that final  
    conversion always clamps when the internalformat is not integer.  
  
    The description of table 3.16 should not mention the <f>  
    floating-point formats.  
  
    Section 3.8.4 should indicate that border color values should be  
    clamped to [0,1] before being stored, if not specified with one of  
    the TexParameterI* functions.  
  
    Section 3.8.8 should not mention clamping border color values to  
    [0,1] for fixed-point textures, since this occurs in 3.8.4 at  
    TexParameter specification.  
  
homeprevnext Dependencies on ARB_color_buffer_float
  
    The following changes should be made if ARB_color_buffer_float is  
    not supported:  
  
    Section 3.11.2, subsection "Shader Outputs: p. 196 should not  
    mention fragment clamping or color buffers with floating-point  
    formats.  
  
    Chapter 4, p. 198 should not mention components represented as  
    floating-point values.  
  
    Section 4.1.3, p. 200, section 4.1.4 p. 205, section 4.1.8 p. 206,  
    section 4.2.3 p. 215 and section 4.3.2 p. 222 should not mention  
    color buffers with a floating-point format.  
  
    Section 4.2.3 p. 217 should not mention clamping the clear color  
    values to [0,1].  
  
homeprevnext Errors
  
    INVALID_OPERATION is generated by Begin, DrawPixels, Bitmap,  
    CopyPixels, or a command that performs an explicit Begin if the  
    color buffer has an integer RGBA format and no fragment shader is  
    active.  
  
    INVALID_ENUM is generated by DrawPixels, TexImage* and  
    SubTexImage* if <format> is one of the integer component formats  
    described in table 3.6 and <type> is FLOAT.  
  
    INVALID_OPERATION is generated by TexImage* and SubTexImage* if  
    the texture internalformat is an integer format as described in  
    table 3.16 and <format> is not one of the integer component  
    formats described in table 3.6, or if the internalformat is not an  
    integer format and <format> is an integer format.  
  
    INVALID_OPERATION is generated by CopyTexImage* and  
    CopyTexSubImage* if the texture internalformat is an integer  
    format and the read color buffer is not an integer format, or if  
    the internalformat is not an integer format and the read color  
    buffer is an integer format.  
  
    INVALID_ENUM is generated by ReadPixels if <format> is an integer  
    format and <type> is FLOAT.  
  
    INVALID_OPERATON is generated by ReadPixels if <format> is an  
    integer format and the color buffer is not an integer format, or  
    if <format> is not an integer format and the color buffer is an  
    integer format.  
  
homeprevnext New State
  
    (modify table 6.33, p. 294)  
  
                                                    Minimum  
    Get Value                  Type   Get Command   Value    Description       Sec.   Attribute  
    ------------------------   ----   -----------   -------  ----------------  ----   ----------  
    RGBA_INTEGER_MODE_EXT        B    GetBooleanv   -        True if RGBA      2.7    -  
                                                             components are  
                                                             integers  
  
homeprevnext Issues
  
    How should the integer pixel path be triggered: by the destination  
    type, new source types, or new source formats?  
  
        RESOLVED: New source formats, based on the precedence of  
        COLOR_INDEX and STENCIL_INDEX formats which invoke distinct  
        pixel path behavior with identical data types and independent  
        of the destination.  
  
    Should pixel transfer operations be defined for the integer pixel  
    path?  
  
        RESOLVED: No.  Fragment shaders can achieve similar results  
        with more flexibility.  There is no need to aggrandize this  
        legacy mechanism.  
  
    What happens if a shader reads a float texel from an integer  
    texture or vice-versa?  
  
        RESOLVED: The result is undefined.  The shader must have  
        knowledge of the texture internal data type.  
  
    How do integer textures behave in fixed function fragment  
    processing?  
  
        RESOLVED: The fixed function texture pipeline assumes textures  
        return floating-point values, hence the return value from an  
        integer texture will not be in a meaningful format.  
  
    How does TEXTURE_BORDER_COLOR work with integer textures?  
  
        RESOLVED: The internal storage of border values effectively  
        becomes a union, and the returned values are interpreted as  
        the same type as the texture.  New versions of TexParameter  
        allow specification of signed and unsigned integer border  
        values.  
  
    How does logic op behave with RGBA mode rendering into integer  
    color buffer?  
  
        RESOLVED: The color logic op operates when enabled when  
        rendering into integer color buffers.  
  
        Logic op operations make sense for integer color buffers so the  
        COLOR_LOGIC_OP enable is respected when rendering into integer  
        color buffers.  
  
        Blending does not apply to RGBA mode rendering when rendering  
        into integer color buffers (as section 4.1.8 is updated to say).  
        The color logic op (described in section 4.1.10) is not a blending  
        operation (though it does take priority over the blending enable).  
  
homeprevnext Revision History
  
    Rev.    Date    Author    Changes  
    ----  --------  --------  -----------------------------------------  
      5   07/15/07  pbrown    Fix typo in GetTexParameterIuivEXT function  
                              name in "New Procedures and Functions".  
  
      4      --               Pre-release revisions.  
  
  
Valid XHTML 1.1! Valid CSS! Last update: November 14, 2006.
Cette page doit être lue avec un navigateur récent respectant le standard XHTML 1.1.