Name

    EXT_gpu_shader4

Name Strings

    GL_EXT_gpu_shader4

Contact

    Barthold Lichtenbelt, NVIDIA (blichtenbelt 'at' nvidia.com)
    Pat Brown, NVIDIA (pbrown 'at' nvidia.com)

Status

    Multi vendor extension
 
    Shipping for GeForce 8 Series (November 2006) 

Version

    Last Modified Date:         12/14/2009
    Author revision:            16

Number

    326

Dependencies

    OpenGL 2.0 is required.

    This extension is written against the OpenGL 2.0 specification and version
    1.10.59 of the OpenGL Shading Language specification.

    This extension trivially interacts with ARB_texture_rectangle.

    This extension trivially interacts with GL_EXT_texture_array.

    This extension trivially interacts with GL_EXT_texture_integer.

    This extension trivially interacts with GL_EXT_geometry_shader4

    This extension trivially interacts with GL_EXT_texture_buffer_object.

    NV_primitive_restart trivially affects the definition of this extension.

    ARB_color_buffer_float affects the definition of this extension.
    EXT_draw_instanced affects the definition of this extension.

Overview

    This extension provides a set of new features to the OpenGL Shading
    Language and related APIs to support capabilities of new hardware. In
    particular, this extension provides the following functionality:

       * New texture lookup functions are provided that allow shaders to
         access individual texels using integer coordinates referring to the
         texel location and level of detail. No filtering is performed. These
         functions allow applications to use textures as one-, two-, and
         three-dimensional arrays.

       * New texture lookup functions are provided that allow shaders to query
         the dimensions of a specific level-of-detail image of a texture
         object.

       * New texture lookup functions variants are provided that allow shaders
         to pass a constant integer vector used to offset the texel locations
         used during the lookup to assist in custom texture filtering
         operations.

       * New texture lookup functions are provided that allow shaders to
         access one- and two-dimensional array textures. The second, or third,
         coordinate is used to select the layer of the array to access.

       * New "Grad" texture lookup functions are provided that allow shaders
         to explicitely pass in derivative values which are used by the GL to
         compute the level-of-detail when performing a texture lookup.

       * A new texture lookup function is provided to access a buffer texture.

       * The existing absolute LOD texture lookup functions are no longer
         restricted to the vertex shader only.

       * The ability to specify and use cubemap textures with a
         DEPTH_COMPONENT internal format. This also enables shadow mapping on
         cubemaps. The 'q' coordinate is used as the reference value for
         comparisons. A set of new texture lookup functions is provided to
         lookup into shadow cubemaps.

       * The ability to specify if varying variables are interpolated in a
         non-perspective correct manner, if they are flat shaded or, if
         multi-sampling, if centroid sampling should be performed.

       * Full signed integer and unsigned integer support in the OpenGL
         Shading Language:

             - Integers are defined as 32 bit values using two's complement.

             - Unsigned integers and vectors thereof are added.

             - New texture lookup functions are provided that return integer
               values. These functions are to be used in conjunction with new
               texture formats whose components are actual integers, rather
               than integers that encode a floating-point value. To support
               these lookup functions, new integer and unsigned-integer
               sampler types are introduced.

             - Integer bitwise operators are now enabled.

             - Several built-in functions and operators now operate on
               integers or vectors of integers.

             - New vertex attribute functions are added that load integer
               attribute data and can be referenced in a vertex shader as
               integer data.

             - New uniform loading commands are added to load unsigned integer
               data.

             - Varying variables can now be (unsigned) integers. If declared
               as such, they have to be flat shaded.

             - Fragment shaders can define their own output variables, and
               declare them to be of type floating-point, integer or unsigned
               integer. These variables are bound to a fragment color index
               with the new API command BindFragDataLocationEXT(), and directed
               to buffers using the existing DrawBuffer or DrawBuffers API
               commands.

       * Added new built-in functions truncate() and round() to the shading
         language.

       * A new built-in variable accessible from within vertex shaders that
         holds the index <i> implicitly passed to ArrayElement to specify the
         vertex. This is called the vertex ID.

       * A new built-in variable accessible from within fragment and geometry
         shaders that hold the index of the currently processed
         primitive. This is called the primitive ID.

    This extension also briefly mentions a new shader type, called a geometry
    shader. A geometry shader is run after vertices are transformed, but
    before clipping. A geometry shader begins with a single primitive (point,
    line, triangle. It can read the attributes of any of the vertices in the
    primitive and use them to generate new primitives. A geometry shader has a
    fixed output primitive type (point, line strip, or triangle strip) and
    emits vertices to define a new primitive. Geometry shaders are discussed
    in detail in the GL_EXT_geometry_shader4 specification.

New Procedures and Functions

    void VertexAttribI1iEXT(uint index, int x);
    void VertexAttribI2iEXT(uint index, int x, int y);
    void VertexAttribI3iEXT(uint index, int x, int y, int z);
    void VertexAttribI4iEXT(uint index, int x, int y, int z, int w);

    void VertexAttribI1uiEXT(uint index, uint x);
    void VertexAttribI2uiEXT(uint index, uint x, uint y);
    void VertexAttribI3uiEXT(uint index, uint x, uint y, uint z);
    void VertexAttribI4uiEXT(uint index, uint x, uint y, uint z,
                            uint w);

    void VertexAttribI1ivEXT(uint index, const int *v);
    void VertexAttribI2ivEXT(uint index, const int *v);
    void VertexAttribI3ivEXT(uint index, const int *v);
    void VertexAttribI4ivEXT(uint index, const int *v);

    void VertexAttribI1uivEXT(uint index, const uint *v);
    void VertexAttribI2uivEXT(uint index, const uint *v);
    void VertexAttribI3uivEXT(uint index, const uint *v);
    void VertexAttribI4uivEXT(uint index, const uint *v);

    void VertexAttribI4bvEXT(uint index, const byte *v);
    void VertexAttribI4svEXT(uint index, const short *v);
    void VertexAttribI4ubvEXT(uint index, const ubyte *v);
    void VertexAttribI4usvEXT(uint index, const ushort *v);

    void VertexAttribIPointerEXT(uint index, int size, enum type,
                                sizei stride, const void *pointer);

    void GetVertexAttribIivEXT(uint index, enum pname, int *params);
    void GetVertexAttribIuivEXT(uint index, enum pname,
                               uint *params);

    void Uniform1uiEXT(int location, uint v0);
    void Uniform2uiEXT(int location, uint v0, uint v1);
    void Uniform3uiEXT(int location, uint v0, uint v1, uint v2);
    void Uniform4uiEXT(int location, uint v0, uint v1, uint v2,
                      uint v3);

    void Uniform1uivEXT(int location, sizei count, const uint *value);
    void Uniform2uivEXT(int location, sizei count, const uint *value);
    void Uniform3uivEXT(int location, sizei count, const uint *value);
    void Uniform4uivEXT(int location, sizei count, const uint *value);

    void GetUniformuivEXT(uint program, int location, uint *params);

    void BindFragDataLocationEXT(uint program, uint colorNumber,
                                const char *name);
    int GetFragDataLocationEXT(uint program, const char *name);

New Tokens

    Accepted by the <pname> parameters of GetVertexAttribdv,
    GetVertexAttribfv, GetVertexAttribiv, GetVertexAttribIuivEXT and
    GetVertexAttribIivEXT:

      VERTEX_ATTRIB_ARRAY_INTEGER_EXT                    0x88FD

    Returned by the <type> parameter of GetActiveUniform:

      SAMPLER_1D_ARRAY_EXT                               0x8DC0
      SAMPLER_2D_ARRAY_EXT                               0x8DC1
      SAMPLER_BUFFER_EXT                                 0x8DC2
      SAMPLER_1D_ARRAY_SHADOW_EXT                        0x8DC3
      SAMPLER_2D_ARRAY_SHADOW_EXT                        0x8DC4
      SAMPLER_CUBE_SHADOW_EXT                            0x8DC5
      UNSIGNED_INT                                       0x1405
      UNSIGNED_INT_VEC2_EXT                              0x8DC6
      UNSIGNED_INT_VEC3_EXT                              0x8DC7
      UNSIGNED_INT_VEC4_EXT                              0x8DC8
      INT_SAMPLER_1D_EXT                                 0x8DC9
      INT_SAMPLER_2D_EXT                                 0x8DCA
      INT_SAMPLER_3D_EXT                                 0x8DCB
      INT_SAMPLER_CUBE_EXT                               0x8DCC
      INT_SAMPLER_2D_RECT_EXT                            0x8DCD
      INT_SAMPLER_1D_ARRAY_EXT                           0x8DCE
      INT_SAMPLER_2D_ARRAY_EXT                           0x8DCF
      INT_SAMPLER_BUFFER_EXT                             0x8DD0
      UNSIGNED_INT_SAMPLER_1D_EXT                        0x8DD1
      UNSIGNED_INT_SAMPLER_2D_EXT                        0x8DD2
      UNSIGNED_INT_SAMPLER_3D_EXT                        0x8DD3
      UNSIGNED_INT_SAMPLER_CUBE_EXT                      0x8DD4
      UNSIGNED_INT_SAMPLER_2D_RECT_EXT                   0x8DD5
      UNSIGNED_INT_SAMPLER_1D_ARRAY_EXT                  0x8DD6
      UNSIGNED_INT_SAMPLER_2D_ARRAY_EXT                  0x8DD7
      UNSIGNED_INT_SAMPLER_BUFFER_EXT                    0x8DD8

    Accepted by the <pname> parameter of GetBooleanv, GetIntegerv, GetFloatv,
    and GetDoublev:

      MIN_PROGRAM_TEXEL_OFFSET_EXT                       0x8904
      MAX_PROGRAM_TEXEL_OFFSET_EXT                       0x8905

Additions to Chapter 2 of the OpenGL 2.0 Specification (OpenGL
Operation)

    Modify Section 2.7 "Vertex Specification", p.20

    Insert before last paragraph, p.22:

    The VertexAttrib* commands described so far should not be used to load
    data for vertex attributes declared as signed or unsigned integers or
    vectors thereof in a vertex shader. If they are used to load signed or
    unsigned integer vertex attributes, the value in those attributes are
    undefined. Instead use the commands

      void VertexAttribI[1234]{i,ui}EXT(uint index, T values);
      void VertexAttribI[1234]{i,ui}vEXT(uint index, T values);
      void VertexAttribI4{b,s,ub,us}vEXT(uint index, T values);

    to specify fixed-point attributes that are not converted to
    floating-point. These attributes can be accessed in vertex shaders that
    declare attributes as signed or unsigned integers or vectors.  The
    VertexAttribI4* commands extend the data passed in to a full signed or
    unsigned integer. If a VertexAttribI* command is used that does not match
    the type of the attribute declared in a vertex shader, the values in the
    attributes are undefined. This means that the unsigned versions of the
    VertexAttribI* commands need to be used to load data for unsigned integer
    vertex attributes or vectors, and the signed versions of the
    VertexAttribI* commands for signed integer vertex attributes or
    vectors. Note that this also means that the VertexAttribI* commands should
    not be used to load data for a vertex attribute declared as a float, float
    vector or matrix, otherwise their values are undefined.

    Insert at end of function list, p.24:

    void VertexAttribIPointerEXT(uint index, int size, enum type,
                                sizei stride, const void *pointer);

    (modify last paragraph, p.24) The <index> parameter in the
    VertexAttribPointer and VertexAttribIPointerEXT commands identify the
    generic vertex attribute array being described. The error INVALID_VALUE is
    generated if <index> is greater than or equal to
    MAX_VERTEX_ATTRIBS. Generic attribute arrays with integer <type> arguments
    can be handled in one of three ways:  converted to float by normalizing to
    [0,1] or [-1,1] as specified in table 2.9, converted directly to float, or
    left as integers. Data for an array specified by VertexAttribPointer will
    be converted to floating-point by normalizing if the <normalized>
    parameter is TRUE, and converted directly to floating-point
    otherwise. Data for an array specified by VertexAttribIPointerEXT will
    always be left as integer values.

    (modify Table 2.4, p. 25)
                                       Integer
    Command                   Sizes    Handling      Types
    ----------------------    -------  ---------     -----------------
    VertexPointer             2,3,4    cast          ...
    NormalPointer             3        normalize     ...
    ColorPointer              3,4      normalize     ...
    SecondaryColorPointer     3        normalize     ...
    IndexPointer              1        cast          ...
    FogCoordPointer           1        n/a           ...
    TexCoordPointer           1,2,3,4  cast          ...
    EdgeFlagPointer           1        integer       ...
    VertexAttribPointer       1,2,3,4  flag          ...
    VertexAttribIPointerEXT   1,2,3,4  integer       byte, ubyte,
                                                     short, ushort,
                                                     int, uint

    Table 2.4:  Vertex array sizes (values per vertex) and data types.  The
    "integer handling" column indicates how fixed-point data types are
    handled: "cast" means that they converted to floating-point directly,
    "normalize" means that they are converted to floating-point by normalizing
    to [0,1] (for unsigned types) or [-1,1] (for signed types), "integer"
    means that they remain as integer values, and "flag" means that either
    "cast" or "normalized" applies, depending on the setting of the
    <normalized> flag in VertexAttribPointer.

    (modify end of pseudo-code, pp. 27-28)

      for (j = 1; j < genericAttributes; j++) {
        if (generic vertex attribute j array enabled) {
          if (generic vertex attribute j array is a pure integer array)
          {
            VertexAttribI[size][type]vEXT(j, generic vertex attribute j
                                            array element i);
          } else if (generic vertex attribute j array normalization
                     flag is set and <type> is not FLOAT or DOUBLE) {
            VertexAttrib[size]N[type]v(j, generic verex attribute j
                                          array element i);
          } else {
            VertexAttrib[size][type]v(j, generic verex attribute j
                                         array element i);
          }
        }
      }

      if (generic vertex attribute 0 array enabled) {
        if (generic vertex attribute 0 array is a pure integer array) {
          VertexAttribI[size][type]vEXT(0, generic verex attribute 0
                                          array element i);
        } else if (generic vertex attribute 0 array normalization flag
                   is set and <type> is not FLOAT or DOUBLE) {
         VertexAttrib[size]N[type]v(0, generic verex attribute 0
                                       array element i);
        } else {
          VertexAttrib[size][type]v(0, generic verex attribute 0
                                       array element i);
        }
      }

    Modify section 2.14.7, "Flatshading", p. 69

    Add a new paragraph at the end of the section on p. 70 as follows:

    If a vertex or geometry shader is active, the flat shading control
    described so far applies to the built-in varying variables gl_FrontColor,
    gl_BackColor, gl_FrontSecondaryColor and gl_BackSecondaryColor. Through
    the OpenGL Shading Language varying qualifier flat any vertex attribute
    can be flagged to be flat-shaded. See the OpenGL Shading Language
    Specification section 4.3.6 for more information.

    Modify section 2.14.8, "Color and Associated Data Clipping", p. 71

    Add to the end of this section:

    For vertex shader varying variables specified to be interpolated without
    perspective correction (using the noperspective keyword), the value of t
    used to obtain the varying value associated with P will be adjusted to
    produce results that vary linearly in screen space.

    Modify section 2.15.3, "Shader Variables", page 75

    Add the following new return types to the description of GetActiveUniform
    on p. 81.

      SAMPLER_1D_ARRAY_EXT,
      SAMPLER_2D_ARRAY_EXT,
      SAMPLER_1D_ARRAY_SHADOW_EXT,
      SAMPLER_2D_ARRAY_SHADOW_EXT,
      SAMPLER_CUBE_SHADOW_EXT,
      SAMPLER_BUFFER_EXT,

      INT_SAMPLER_1D_EXT,
      INT_SAMPLER_2D_EXT,
      INT_SAMPLER_3D_EXT,
      INT_SAMPLER_CUBE_EXT,
      INT_SAMPLER_2D_RECT_EXT,
      INT_SAMPLER_1D_ARRAY_EXT,
      INT_SAMPLER_2D_ARRAY_EXT,
      INT_SAMPLER_BUFFER_EXT,

      UNSIGNED_INT,
      UNSIGNED_INT_VEC2_EXT,
      UNSIGNED_INT_VEC3_EXT,
      UNSIGNED_INT_VEC4_EXT,
      UNSIGNED_INT_SAMPLER_1D_EXT,
      UNSIGNED_INT_SAMPLER_2D_EXT,
      UNSIGNED_INT_SAMPLER_3D_EXT,
      UNSIGNED_INT_SAMPLER_CUBE_EXT,
      UNSIGNED_INT_SAMPLER_2D_RECT_EXT,
      UNSIGNED_INT_SAMPLER_1D_ARRAY_EXT,
      UNSIGNED_INT_SAMPLER_2D_ARRAY_EXT,
      UNSIGNED_INT_SAMPLER_BUFFER_EXT.
  
    Add the following uniform loading command prototypes on p. 81 as follows:

      void Uniform{1234}uiEXT(int location, T value);
      void Uniform{1234}uivEXT(int location, sizei count, T value);

    (add the following paragraph to the description of the above
    commands)

    The Uniform*ui{v} commands will load count sets of one to four unsigned
    integer values into a uniform location defined as a unsigned integer, an
    unsigned integer vector, an array of unsigned integers or an array of
    unsigned integer vectors.

    (change the first sentence of the last paragraph as follows)

    When loading values for a uniform declared as a Boolean, the Uniform*i{v},
    Uniform*ui{v} and Uniform*f{v} set of commands can be used to load boolean
    values.

    Modify section 2.15.4 Shader execution, p. 84.

    Add a new section "2.15.4.1 Shader Only Texturing" before the sub-
    section "Texture Access" on p. 85

    This section describes texture functionality that is only accessible
    through vertex, geometry or fragment shaders. Also refer to the OpenGL
    Shading Language Specification, section 8.7 and Section 3.8 of the OpenGL
    2.0 specification.

    Note: For unextended OpenGL 2.0 and the OpenGL Shading Language version
    1.20, all supported texture internal formats store unsigned integer values
    but return floating-point results in the range [0, 1] and are considered
    unsigned "normalized" integers.  The ARB_texture_float extension
    introduces floating-point internal format where components are both stored
    and returned as floating-point values, and are not clamped. The
    EXT_texture_integer extension introduces formats that store either signed
    or unsigned integer values.

    This extension defines additional OpenGL Shading Language texture lookup
    functions, see section 8.7 of the OpenGL Shading Language, that return
    either signed or unsigned integer values if the internal format of the
    texture is signed or unsigned, respectively.

    Texel Fetches

    The OpenGL Shading Language texel fetch functions provide the ability to
    extract a single texel from a specified texture image.  The integer
    coordinates passed to the texel fetch functions are used directly as the
    texel coordinates (i, j, k) into the texture image. This in turn means the
    texture image is point-sampled (no filtering is performed).

    The level of detail accessed is computed by adding the specified
    level-of-detail parameter <lod> to the base level of the texture,
    level_base.

    The texel fetch functions can not perform depth comparisons or access cube
    maps. Unlike filtered texel accesses, texel fetches do not support LOD
    clamping or any texture wrap mode, and require a mipmapped minification
    filter to access any level of detail other than the base level.

    The results of the texel fetch are undefined:

       * if the computed LOD is less than the texture's base level
         (level_base) or greater than the maximum level (level_max),

       * if the computed LOD is not the texture's base level and the texture's
         minification filter is NEAREST or LINEAR,

       * if the layer specified for array textures is negative or greater than
         the number of layers in the array texture,

       * if the texel at (i,j,k) coordinates refer to a border texel outside
         the defined extents of the specified LOD, where

                i < -b_s, j < -b_s, k < -b_s,
                i >= w_s - b_s, j >= h_s - b_s, or k >= d_s - b_s,

         where the size parameters (w_s, h_s, d_s, and b_s) refer to the
         width, height, depth, and border size of the image, as in equations
         3.15, 3.16, and 3.17, or

       . if the texture being accessed is not complete (or cube complete for
         cubemaps).

    Texture Size Query

    The OpenGL Shading Language texture size functions provide the ability to
    query the size of a texture image. The LOD value <lod> passed in as an
    argument to the texture size functions is added to the level_base of the
    texture to determine a texture image level.  The dimensions of that image
    level, excluding a possible border, are then returned. If the computed
    texture image level is outside the range [level_base, level_max], the
    results are undefined. When querying the size of an array texture, both
    the dimensions and the layer count are returned. Note that buffer textures
    do not support mipmapping, therefore the previous lod discussion does not
    apply to buffer textures

    Make the section "Texture Access" a subsection of 2.15.4.1

    Modify the first paragraph on p. 86 as follows:

    Texture lookups involving textures with depth component data can either
    return the depth data directly or return the results of a comparison with
    the R value (see section 3.8.14) used to perform the lookup. The
    comparison operation is requested in the shader by using any of the shadow
    sampler and in the texture using the TEXTURE COMPARE MODE parameter. These
    requests must be consistent; the results of a texture lookup are undefined
    if:

       * The sampler used in a texture lookup function is not one of the
         shadow sampler types, and the texture object's internal format is
         DEPTH COMPONENT, and the TEXTURE COMPARE MODE is not NONE.

       * The sampler used in a texture lookup function is one of the shadow
         sampler types, and the texture object's internal format is DEPTH
         COMPONENT, and the TEXTURE COMPARE MODE is NONE.

       * The sampler used in a texture lookup function is one of the shadow
         sampler types, and the texture object's internal format is not DEPTH
         COMPONENT.

    Add a new section "2.15.4.2 Shader Inputs" before "Position
    Invariance" on p. 86

    Besides having access to vertex attributes and uniform variables,
    vertex shaders can access the read-only built-in variables
    gl_VertexID and gl_InstanceID. The gl_VertexID variable holds the
    integer index <i> implicitly passed to ArrayElement() to specify
    the vertex. The variable gl_InstanceID holds the integer index of
    the current primitive in an instanced draw call.  See also section
    7.1 of the OpenGL Shading Language Specification.

    Add a new section "2.15.4.3 Shader Outputs"

    A vertex shader can write to built-in as well as user-defined varying
    variables. These values are expected to be interpolated across the
    primitive it outputs, unless they are specified to be flat shaded. Refer
    to section 2.15.3 and the OpenGL Shading Language specification sections
    4.3.6, 7.1 and 7.6 for more detail.

    The built-in output variables gl_FrontColor, gl_BackColor,
    gl_FrontSecondaryColor, and gl_BackSecondaryColor hold the front and back
    colors for the primary and secondary colors for the current vertex.

    The built-in output variable gl_TexCoord[] is an array and holds the set
    of texture coordinates for the current vertex.

    The built-in output variable gl_FogFragCoord is used as the "c" value, as
    described in section 3.10 "Fog" of the OpenGL 2.0 specification.

    The built-in special variable gl_Position is intended to hold the
    homogeneous vertex position. Writing gl_Position is optional.

    The built-in special variable gl_ClipVertex holds the vertex coordinate
    used in the clipping stage, as described in section 2.12 "Clipping" of the
    OpenGL 2.0 specification.

    The built in special variable gl_PointSize, if written, holds the size of
    the point to be rasterized, measured in pixels.

    Number section "Position Invariance", "Validation" and "Undefined
    Behavior" as sections 2.15.4.4, 2.15.4.5, and 2.15.4.6 respectively.

Additions to Chapter 3 of the OpenGL 2.0 Specification (Rasterization)

    Modify Section 3.8.1, Texture Image Specification, p. 150

    (modify 4th paragraph, p. 151 -- add cubemaps to the list of texture
    targets that can be used with DEPTH_COMPONENT textures)

    Textures with a base internal format of DEPTH_COMPONENT are supported by
    texture image specification commands only if <target> is TEXTURE_1D,
    TEXTURE_2D, TEXTURE_CUBE_MAP, TEXTURE_RECTANGLE_ARB, PROXY_TEXTURE_1D,
    PROXY_TEXTURE_2D, PROXY_TEXTURE_CUBE_MAP, or
    PROXY_TEXTURE_RECTANGLE_ARB. Using this format in conjunction with any
    other target will result in an INVALID_OPERATION error.


    Delete Section 3.8.7, Texture Wrap Modes.  (The language in this section
    is folded into updates to the following section, and is no longer needed
    here.)


    Modify Section 3.8.8, Texture Minification:

    (replace the last paragraph, p. 171):  Let s(x,y) be the function that
    associates an s texture coordinate with each set of window coordinates
    (x,y) that lie within a primitive; define t(x,y) and r(x,y) analogously.
    Let

      u(x,y) = w_t * s(x,y) + offsetu_shader,
      v(x,y) = h_t * t(x,y) + offsetv_shader, 
      w(x,y) = d_t * r(x,y) + offsetw_shader, and

    where w_t, h_t, and d_t are as defined by equations 3.15, 3.16, and 3.17
    with w_s, h_s, and d_s equal to the width, height, and depth of the image
    array whose level is level_base.  (offsetu_shader, offsetv_shader,
    offsetw_shader) is the texel offset specified in the OpenGL Shading
    Language texture lookup functions that support offsets. If the texture
    function used does not support offsets, or for fixed-function texture
    accesses, all three shader offsets are taken to be zero.  For
    fixed-function texture accesses, all three shader offsets are taken to be
    zero.  For a one-dimensional texture, define v(x,y) == 0 and w(x,y) === 0;
    for two-dimensional textures, define w(x,y) == 0.

    After u(x,y), v(x,y), and w(x,y) are generated, they are clamped if the
    corresponding texture wrap modes are CLAMP or MIRROR_CLAMP_EXT.  Let

      u'(x,y) = clamp(u(x,y), 0, w_t),      if TEXTURE_WRAP_S is CLAMP
                clamp(u(x,y), -w_t, w_t),   if TEXTURE_WRAP_S is
                                              MIRROR_CLAMP_EXT, or
                u(x,y),                     otherwise
      v'(x,y) = clamp(v(x,y), 0, w_t),      if TEXTURE_WRAP_T is CLAMP
                clamp(v(x,y), -w_t, w_t),   if TEXTURE_WRAP_T is
                                              MIRROR_CLAMP_EXT, or
                v(x,y),                     otherwise
      w'(x,y) = clamp(w(x,y), 0, w_t),      if TEXTURE_WRAP_R is CLAMP
                clamp(w(x,y), -w_t, w_t),   if TEXTURE_WRAP_R is
                                              MIRROR_CLAMP_EXT, or
                w(x,y),                     otherwise,

    where clamp(<a>,<b>,<c>) returns <b> if <a> is less than <b>, <c> if a is
    greater than <c>, and <a> otherwise.

    (start a new paragraph with "For a polygon, rho is given at a fragment
    with window coordinates...", and then continue with the original spec
    text.)

    (replace text starting with the last paragraph on p. 172, continuing to
    the end of p. 174)

    When lambda indicates minification, the value assigned to
    TEXTURE_MIN_FILTER is used to determine how the texture value for a
    fragment is selected.

    When TEXTURE_MIN_FILTER is NEAREST, the texel in the image array of level
    level_base that is nearest (in Manhattan distance) to that specified by
    (s,t,r) is obtained.  Let i, j, and k be integers such that:

      i = apply_wrap(floor(u'(x,y))),
      j = apply_wrap(floor(v'(x,y))), and
      k = apply_wrap(floor(w'(x,y))),

    where the coordinate returned by apply_wrap() is as defined by Table X.19.
    The values of i, j, and k are then modified according to the texture wrap
    modes, as described in Table 3.19, to produce new values (i', j', and k').
    For a three-dimensional texture, the texel at location (i,j,k) becomes the
    texture value.  For a two-dimensional texture, k is irrelevant, and the
    texel at location (i,j) becomes the texture value.  For a one-dimensional
    texture, j and k are irrelevant, and the texel at location i becomes the
    texture value.

      Wrap mode                   Result
      --------------------------  ------------------------------------------
      CLAMP_TO_EDGE               clamp(coord, 0, size-1)
      CLAMP_TO_BORDER             clamp(coord, -1, size)
      CLAMP                       { clamp(coord, 0, size-1), 
                                  {         for NEAREST filtering
                                  { clamp(coord, -1, size), 
                                  {         for LINEAR filtering
      REPEAT                      mod(coord, size)
      MIRROR_CLAMP_TO_EDGE_EXT    clamp(mirror(coord), 0, size-1)
      MIRROR_CLAMP_TO_BORDER_EXT  clamp(mirror(size), 0, size)
      MIRROR_CLAMP_EXT            { clamp(mirror(coord), 0, size-1), 
                                  {         for NEAREST filtering
                                  { clamp(mirror(size), 0, size), 
                                  {         for LINEAR filtering
      MIRRORED_REPEAT             (size-1) - mirror(mod(coord, 2*size)-size)

      Table X.19:  Texel location wrap mode application.  mod(<a>,<b>) is
      defined to return <a>-<b>*floor(<a>/<b>), and mirror(<a>) is defined to
      return <a> if <a> is greater than or equal to zero or -(1+<a>)
      otherwise.  The values of "wrap mode" and size are TEXTURE_WRAP_S and
      w_t, TEXTURE_WRAP_T and h_t, and TEXTURE_WRAP_R and d_t, for i, j, and k
      coordinates, respectively.  The coordinate clamp and MIRROR_CLAMP_EXT
      depends on the filtering mode (NEAREST or LINEAR).

    If the selected (i,j,k), (i,j), or i location refers to a border texel
    that satisfies any of the following conditions:

      i < -b_s,
      j < -b_s, 
      k < -b_s, 
      i >= w_t + b_s, 
      j >= h_t + b_s, or
      j >= d_t + b_s,
 
    then the border values defined by TEXTURE_BORDER_COLOR are used in place
    of the non-existent texel. 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. If
    the texture contains depth components, the first component of
    TEXTURE_BORDER_COLOR is interpreted as a depth value.

    When TEXTURE_MIN_FILTER is LINEAR, a 2x2x2 cube of texels in the image
    array of level level_base is selected.  Let:

      i_0   = apply_wrap(floor(u' - 0.5)),
      j_0   = apply_wrap(floor(v' - 0.5)),
      k_0   = apply_wrap(floor(w' - 0.5)),
      i_1   = apply_wrap(floor(u' - 0.5) + 1),
      j_1   = apply_wrap(floor(v' - 0.5) + 1),
      k_1   = apply_wrap(floor(w' - 0.5) + 1),
      alpha = frac(u' - 0.5),
      beta  = frac(v' - 0.5),
      gamma = frac(w' - 0.5),

    where frac(<x>) denotes the fractional part of <x>.

    For a three-dimensional texture, the texture value tau is found as...

    (replace last paragraph, p.174) For any texel in the equation above that
    refers to a border texel outside the defined range of the image, the texel
    value is taken from the texture border color as with NEAREST filtering.

    modify the last paragraph of section 3.8.8, p. 175, as follows:

    The rules for NEAREST or LINEAR filtering are then applied to the selected
    array. Specifically, the coordinate (u,v,w) is computed as in equation
    3.20a, with w_s, h_s, and d_s equal to the width, height, and depth of the
    image array whose level is 'd'.

    Modify the second paragraph on p. 176

    The rules for NEAREST or LINEAR filtering are then applied to each of the
    selected arrays, yielding two corresponding texture valutes Tau1 and
    Tau2. Specifically, for level d1, the coordinate (u,v,w) is computed as in
    equation 3.20a, with w_s, h_s, and d_s equal to the width, height, and
    depth of the image array whose level is 'd1'. For level d2 the coordinate
    (u', v', w') is computed as in equation 3.20a, with w_s, h_s, and d_s
    equal to the width, height, and depth of the image array whose level is
    'd2'.

    Modify the first paragraph of section 3.8.9 "Texture Magnification" as
    follows:

    When lambda indicates magnification, the value assigned to
    TEXTURE_MAG_FILTER determines how the texture value is obtained. There are
    two possible values for TEXTURE_MAG_FILTER: NEAREST and LINEAR.  NEAREST
    behaves exactly as NEAREST for TEXTURE_MIN_FILTER and LINEAR behaves
    exactly as LINEAR for TEXTURE_MIN_FILTER, as described in the previous
    section, including the wrapping calculations. The level-of-detail
    level_base texture array is always used for magnification.

    Modify Section 3.8.14, Texture Comparison Modes (p. 185)

    (modify 2nd paragraph, p. 188, indicating that the Q texture coordinate is
    used for depth comparisons on cubemap textures)

    Let D_t be the depth texture value, in the range [0, 1].  For
    fixed-function texture lookups, let R be the interpolated <r> texture
    coordinate, clamped to the range [0, 1].  For texture lookups generated by
    an OpenGL Shading Language lookup function, let R be the reference value
    for depth comparisons provided in the lookup function, also clamped to [0,
    1].  Then the effective texture value L_t, I_t, or A_t is computed as
    follows:

    Modify section 3.11, Fragment Shaders, p. 193

    Modify the third paragraph on p. 194 as follows:

    Additionally, when a vertex shader is active, it may define one or more
    varying variables (see section 2.15.3 and the OpenGL Shading Language
    Specification). These values are, if not flat shaded, interpolated across
    the primitive being rendered. The results of these interpolations are
    available when varying variables of the same name are defined in the
    fragment shader.

    Add the following paragraph to the end of section 3.11.1, p. 194

    A fragment shader can also write to varying out variables. Values written
    to these variables are used in the subsequent per-fragment operations.
    Varying out variables can be used to write floating-point, integer or
    unsigned integer values destined for buffers attached to a framebuffer
    object, or destined for color buffers attached to the default
    framebuffer. The subsection 'Shader Outputs' of the next section describes
    API how to direct these values to buffers.

    Add a new paragraph at the beginning of the section "Texture
    Access", p. 194

    Section 2.15.4.1 describes texture lookup functionality accessible to a
    vertex shader. The texel fetch and texture size query functionality
    described there also applies to fragment shaders.

    Modify the second paragraph on p. 195 as follows:

    Texture lookups involving textures with depth component data can either
    return the depth data directly or return the results of a comparison with
    the R value (see section 3.8.14) used to perform the lookup. The
    comparison operation is requested in the shader by using any of the shadow
    sampler and in the texture using the TEXTURE COMPARE MODE parameter. These
    requests must be consistent; the results of a texture lookup are undefined
    if:

       * The sampler used in a texture lookup function is not one of the
         shadow sampler types, and the texture object's internal format is
         DEPTH COMPONENT, and the TEXTURE COMPARE MODE is not NONE.

       * The sampler used in a texture lookup function is one of the shadow
         sampler types, and the texture object's internal format is DEPTH
         COMPONENT, and the TEXTURE COMPARE MODE is NONE.

       * The sampler used in a texture lookup function is one of the shadow
         sampler types, and the texture object's internal format is not DEPTH
         COMPONENT.

    Add the following paragraph to the section Shader Inputs, p. 196

    If a geometry shader is active, the built-in variable gl_PrimitiveID
    contains the ID value emitted by the geometry shader for the provoking
    vertex. If no geometry shader is active, gl_PrimitiveID is filled with the
    number of primitives processed by the rasterizer since the last time Begin
    was called (directly or indirectly via vertex array functions).  The first
    primitive generated after a Begin is numbered zero, and the primitive ID
    counter is incremented after every individual point, line, or polygon
    primitive is processed.  For polygons drawn in point or line mode, the
    primitive ID counter is incremented only once, even though multiple points
    or lines may be drawn.  For QUADS and QUAD_STRIP primitives that are
    decomposed into triangles, the primitive ID is incremented after each
    complete quad is processed.  For POLYGON primitives, the primitive ID
    counter is undefined.  The primitive ID is undefined for fragments
    generated by DrawPixels or Bitmap. Restarting a primitive topology using
    the primitive restart index has no effect on the primitive ID counter.

    Modify the first paragraph of the section Shader Outputs, p. 196 as
    follows

    The OpenGL Shading Language specification describes the values that may be
    output by a fragment shader. These outputs are split into two
    categories. User-defined varying out variables and built-in variables. The
    built-in variables are gl_FragColor, gl_FragData[n], and gl_FragDepth. If
    fragment clamping is enabled, the final fragment color values or the final
    fragment data values or the final varying out variable values written by a
    fragment shader are clamped to the range [0,1] and then may be converted
    to fixed-point as described in section 2.14.9. Only user-defined varying
    out variables declared as a floating-point type are clamped and may be
    converted. If fragment clamping is disabled, the final fragment color
    values or the final fragment data values or the final varying output
    variable values are not modified. The final fragment depth written...

    Modify the second paragraph of the section Shader Outputs, p. 196
    as follows

    ...A fragment shader may not statically assign values to more than one of
    gl_FragColor, gl_FragData or any user-defined varying output variable. In
    this case, a compile or link error will result. A shader statically...

    Add the following to the end of the section Shader Outputs, p. 197

    The values of user-defined varying out variables are directed to a color
    buffer in a two step process. First the varying out variable is bound to a
    fragment color by using its number. The GL will assign a number to each
    varying out variable, unless overridden by the command
    BindFragDataLocationEXT(). The number of the fragment color assigned for
    each user-defined varying out variable can be queried with
    GetFragDataLocationEXT(). Next, the DrawBuffer or DrawBuffers commands (see
    section 4.2.1) direct each fragment color to a particular buffer.

    The binding of a user-defined varying out variable to a fragment color
    number can be specified explicitly. The command

        void BindFragDataLocationEXT(uint program, uint colorNumber,
                                     const char *name);

    specifies that the varying out variable name in program should be bound to
    fragment color colorNumber when the program is next linked. If name was
    bound previously, its assigned binding is replaced with colorNumber. name
    must be a null terminated string.  The error INVALID_VALUE is generated if
    colorNumber is equal or greater than MAX_DRAW_BUFFERS.
    BindFragDataLocationEXT has no effect until the program is linked. In
    particular, it doesn't modify the bindings of varying out variables in a
    program that has already been linked. The error INVALID OPERATION is
    generated if name starts with the reserved "gl_" prefix.

    When a program is linked, any varying out variables without a binding
    specified through BindFragDataLocationEXT will automatically be bound to
    fragment colors by the GL. Such bindings can be queried using the command
    GetFragDataLocationEXT.  LinkProgram will fail if the assigned binding of a
    varying out variable would cause the GL to reference a non-existant
    fragment color number (one greater than or equal to MAX DRAW_BUFFERS).
    LinkProgram will also fail if more than one varying out variable is bound
    to the same number. This type of aliasing is not allowed.

    BindFragDataLocationEXT may be issued before any shader objects are
    attached to a program object. Hence it is allowed to bind any name (except
    a name starting with "gl_") to a color number, including a name that is
    never used as a varying out variable in any fragment shader
    object. Assigned bindings for variables that do not exist are ignored.

    After a program object has been linked successfully, the bindings of
    varying out variable names to color numbers can be queried. The command

        int GetFragDataLocationEXT(uint program, const char *name);

    returns the number of the fragment color that the varying out variable
    name was bound to when the program object program was last linked. name
    must be a null terminated string. If program has not been successfully
    linked, the error INVALID OPERATION is generated. If name is not a varying
    out variable, or if an error occurs, -1 will be returned.

Additions to Chapter 4 of the OpenGL 2.0 Specification (Per-Fragment
Operations and the Frame Buffer)

    Modify Section 4.2.1, Selecting a Buffer for Writing (p. 212)

    (modify next-to-last paragraph, p. 213) If a fragment shader writes to
    gl_FragColor, DrawBuffers specifies a set of draw buffers into which the
    single fragment color defined by gl_FragColor is written.  If a fragment
    shader writes to gl_FragData or a user-defined varying out variable,
    DrawBuffers specifies a set of draw buffers into which each of the
    multiple output colors defined by these variables are separately written.
    If a fragment shader writes to neither gl_FragColor, nor gl FragData, nor
    any user-defined varying out variables, the values of the fragment colors
    following shader execution are undefined, and may differ for each fragment
    color.

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

    Change section 5.4 Display Lists, p. 237

    Add the commands VertexAttribIPointerEXT and BindFragDataLocationEXT to
    the list of commands that are not compiled into a display list, but
    executed immediately, under "Program and Shader Objects", p. 241

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

    Modify section 6.1.14 "Shader and Program Queries", p. 256

    Modify 2nd paragraph, p.259:

    Add the following to the list of GetVertexAttrib* commands:

      void GetVertexAttribIivEXT(uint index, enum pname, int *params);
      void GetVertexAttribIuivEXT(uint index, enum pname, uint *params);

    obtain the...  <pname> must be one of VERTEX_ATTRIB_ARRAY_ENABLED ,.,
    VERTEX_ATTRIB_ARRAY_NORMALIZED, VERTEX_ATTRIB_ARRAY_INTEGER_EXT, or
    CURRENT_VERTEX_ATTRIB.  ...

    Split 3rd paragraph, p.259

    ... The size, stride, type, normalized flag, and unconverted integer flag
    are set by the commands VertexAttribPointer and VertexAttribIPointerEXT.
    The normalized flag is always set to FALSE by by VertexAttribIPointerEXT.
    The unconverted integer flag is always set to FALSE by VertexAttribPointer
    and TRUE by VertexAttribIPointerEXT.

    The query CURRENT_VERTEX_ATTRIB returns the current value for the generic
    attribute <index>.  GetVertexAttribdv and GetVertexAttribfv read and
    return the current attribute values as floating-point values;
    GetVertexAttribiv reads them as floating-point values and converts them
    to integer values; GetVertexAttribIivEXT reads and returns them as
    integers; GetVertexAttribIuivEXT reads and returns them as unsigned
    integers.  The results of the query are undefined if the current attribute
    values are read using one data type but were specified using a different
    one. The error INVALID_OPERATION is generated if <index> is zero.

    Change the prototypes in the first paragraph on page 260 as
    follows:

      void GetUniformfv(uint program, int location, float *params);
      void GetUniformiv(uint program, int location, int *params);
      void GetUniformuivEXT(uint program, int location, uint *params);

Additions to Appendix A of the OpenGL 2.0 Specification (Invariance)

    None.

Additions to the AGL/GLX/WGL Specifications

    None.

Interactions with GL_ARB_color_buffer_float

    If the GL_ARB_color_buffer_float extension is not supported then any
    reference to fragment clamping in section 3.11.2 "Shader Execution" needs
    to be deleted.

Interactions with GL_ARB_texture_rectangle

    If the GL_ARB_texture_rectangle extension is not supported then all
    references to texture lookup functions with 'Rect' in the name need to be
    deleted.

Interactions with GL_EXT_texture_array

    If the GL_EXT_texture_array extension is not supported, all references to
    one- and two-dimensional array texture sampler types (e.g.,
    sampler1DArray, sampler2DArray) and the texture lookup functions that use
    them need to be deleted.

Interactions with GL_EXT_geometry_shader4

    If the GL_EXT_geometry_shader4 extension is not supported, all references
    to a geometry shader need to be deleted.

Interactions with GL_NV_primitive_restart

    The spec describes the behavior that primitive restart does not affect the
    primitive ID counter, including for POLYGON primitives (where one could
    argue that the restart index starts a new primitive without a new Begin to
    reset the count). If NV_primitive_restart is not supported, references to
    that extension in the discussion of the primitive ID counter should be
    removed.

    If NV_primitive_restart is supported, index values causing a primitive
    restart are not considered as specifying an End command, followed by
    another Begin. Primitive restart is therefore not guaranteed to
    immediately update material properties when a vertex shader is active. The
    spec language on p.64 of the OpenGL 2.0 specification says "changes are
    not guaranteed to update material parameters, defined in table 2.11, until
    the following End command."

Interactions with EXT_texture_integer

    If the EXT_texture_integer spec is not supported, the discussion about
    this spec in section 2.15.4.1 needs to be removed. All texture lookup
    functions that return integers or unsigned integers, as discussed in
    section 8.7 of the OpenGL Shading Language specification, also need to be
    removed.

Interactions with EXT_texture_buffer_object

    If EXT_texture_buffer_object is not supported, references to buffer
    textures, as well as the texelFetchBuffer and texelSizeBuffer lookup
    functions and samplerBuffer types, need to be removed.

Interactions with EXT_draw_instanced

    If EXT_draw_instanced is not supported, the value of gl_InstanceID
    is always zero.

GLX Protocol

    The following rendering commands are sent to the server as part of a
    glXRender request:

    Uniform1uiEXT

        2           12               rendering command length
        2           269              rendering command opcode
        4           INT32            location
        4           CARD32           v0

    Uniform2uiEXT

        2           16               rendering command length
        2           270              rendering command opcode
        4           INT32            location
        4           CARD32           v0
        4           CARD32           v1

    Uniform3uiEXT

        2           20               rendering command length
        2           271              rendering command opcode
        4           INT32            location
        4           CARD32           v0
        4           CARD32           v1
        4           CARD32           v2

    Uniform4uiEXT

        2           24               rendering command length
        2           272              rendering command opcode
        4           INT32            location
        4           CARD32           v0
        4           CARD32           v1
        4           CARD32           v2
        4           CARD32           v3

    BindFragDataLocationEXT

        2           12+n+p           rendering command length
        2           273              rendering command opcode
        4           CARD32           program
        4           CARD32           color
        n           LISTofBYTE       name, n = strlen(name) + 1
        p                            padding, p=pad(n)

    The following rendering commands are sent sent to the server as part
    of a glXRender request or as a glXRenderLarge request.

    Uniform1uivEXT

        2           12+count*4       rendering command length
        2           274              rendering command opcode
        4           INT32            location
        4           CARD32           count
        4*count     LISTofCARD32     value

    If the command is encoded in a glXRenderLarge request, the
    command opcode and command length fields above are expanded to
    4 bytes each:

        4           16+count*4       rendering command length
        4           274              rendering command opcode

    Uniform2uivEXT

        2           12+count*4*2     rendering command length
        2           275              rendering command opcode
        4           INT32            location
        4           CARD32           count
        2*4*count   LISTofCARD32     value

    If the command is encoded in a glXRenderLarge request, the
    command opcode and command length fields above are expanded to
    4 bytes each:

        4           16+count*4*2     rendering command length
        4           275              rendering command opcode

    Uniform3uivEXT

        2           12+count*4*3     rendering command length
        2           276              rendering command opcode
        4           INT32            location
        4           CARD32           count
        3*4*count   LISTofCARD32     value

    If the command is encoded in a glXRenderLarge request, the
    command opcode and command length fields above are expanded to
    4 bytes each:

        4           16+count*4       rendering command length
        4           276              rendering command opcode

    Uniform4uivEXT

        2           12+count*4*4     rendering command length
        2           277              rendering command opcode
        4           INT32            location
        4           CARD32           count
        4*4*count   LISTofCARD32     value

    If the command is encoded in a glXRenderLarge request, the
    command opcode and command length fields above are expanded to
    4 bytes each:

        4           16+count*4*4     rendering command length
        4           277              rendering command opcode

    The following non-rendering commands are added.

    GetUniformuivEXT

        1           CARD8            opcode (X assigned)
        1           182              GLX opcode
        2           4                request length
        4           GLX_CONTEXT_TAG  context tag
        4           CARD32           program
        4           INT32            location
      =>
        1           1                reply
        1                            unused
        2           CARD16           sequence number
        4           m                reply length, m = (n == 1 ? 0 : n)
        4           CARD32           unused
        4           CARD32           n

        if  (n = 1) this follows:

        4           CARD32           params
        12                           unused

        otherwise this follows:

        16          CARD32           unused
        4*n         CARD32           params

    Note that n may be zero, indicating that a GL error occured.

    GetFragDataLocationEXT

        1           CARD8            opcode (X assigned)
        1           183              GLX opcode
        2           3+(n+p)/4        request length
        4           GLX_CONTEXT_TAG  context tag
        4           CARD32           program
        n           LISTofBYTE       name, n = strlen(name) + 1
        p                            padding, p=pad(n)
      =>
        1           1                reply
        1                            unused
        2           CARD16           sequence number
        4           0                reply length
        4           CARD32           retval
        20                           unused

    GLX protocol for following commands is defined in the
    NV_vertex_program4 extension:

        VertexAttribI1iEXT, VertexAttribI2iEXT, VertexAttribI3iEXT,
        VertexAttribI4iEXT, VertexAttribI1uiEXT, VertexAttribI2uiEXT,
        VertexAttribI3uiEXT, VertexAttribI4uiEXT, VertexAttribI1ivEXT,
        VertexAttribI2ivEXT, VertexAttribI3ivEXT, VertexAttribI4ivEXT,
        VertexAttribI1uivEXT, VertexAttribI2uivEXT, VertexAttribI3uivEXT,
        VertexAttribI4uivEXT, VertexAttribI4bvEXT, VertexAttribI4svEXT,
        VertexAttribI4ubvEXT, VertexAttribI4usvEXT, GetVertexAttribIivEXT,
        GetVertexAttribIuivEXT

    VertexAttribIPointerEXT is an entirely client-side command.

Errors

    The error INVALID_VALUE is generated by BindFragDataLocationEXT() if
    colorNumber is equal or greater than MAX_DRAW_BUFFERS.

    The error INVALID OPERATION is generated by BindFragDataLocationEXT() if
    name starts with the reserved "gl_" prefix.

    The error INVALID_OPERATION is generated by BindFragDataLocationEXT() or
    GetFragDataLocationEXT if program is not the name of a program object.

    The error INVALID_OPERATION is generated by GetFragDataLocationEXT() if
    program has not been successfully linked.

New State

    (add to table 6.7, p. 268)
                                                 Initial
    Get Value            Type    Get Command     Value   Description          Sec.    Attribute
    ---------            ----    --------------- ------- -------------------- ----    ---------
    VERTEX_ATTRIB_ARRAY  16+xB   GetVertexAttrib FALSE   vertex attrib array  2.8     vertex-array
      INTEGER_EXT                                        has unconverted ints

New Implementation Dependent State

                                                             Minimum
    Get Value                         Type  Get Command       Value   Description           Sec.   Attrib
    --------------------------------  ----  ---------------  -------  --------------------- ------ ------
    MIN_PROGRAM_TEXEL_OFFSET_EXT      Z     GetIntegerv        -8     minimum texel offset  2.x.4.4  -
                                                                      allowed in lookup
    MAX_PROGRAM_TEXEL_OFFSET_EXT      Z     GetIntegerv        +7     maximum texel offset  2.x.4.4  -
                                                                      allowed in lookup

Modifications to The OpenGL Shading Language Specification, Version 1.10.59

    Including the following line in a shader can be used to control the
    language features described in this extension:

      #extension GL_EXT_gpu_shader4 : <behavior>

    where <behavior> is as specified in section 3.3.

    A new preprocessor #define is added to the OpenGL Shading Language:

      #define GL_EXT_gpu_shader4 1

    Add to section 3.6 "Keywords"

    Add the following keywords:

      noperspective, flat, centroid

    Remove the unsigned keyword from the list of keywords reserved for future
    use, and add it to the list of keywords.

    The following new vector types are added:

      uvec2, uvec3, uvec4

    The following new sampler types are added:

      sampler1DArray, sampler2DArray, sampler1DArrayShadow,
      sampler2DArrayShadow, samplerCubeShadow

      isampler1D, isampler2D, isampler3D, isamplerCube, isampler2DRect,
      isampler1DArray, isampler2DArray

      usampler1D, usampler2D, usampler3D, usamplerCube, usampler2DRect,
      usampler1DArray, usampler2DArray

      samplerBuffer, isamplerBuffer, usamplerBuffer

    Add to section 4.1 "Basic Types"

    Break the table in this section up in several tables. The first table
    4.1.1 is named "scalar, vector and matrix data types". It includes the
    first row through the 'mat4" row.

    Add the following to the first section of this table:

      unsigned int           An unsigned integer
      uvec2                  A two-component unsigned integer vector
      uvec3                  A three-component unsigned integer vector
      uvec4                  A four-component unsigned integer vector

    Break out the sampler types in a separate table, and name that table 4.1.2
    "default sampler types". Add the following sampler types to this new
    table:

      sampler1DArray         handle for accessing a 1D array texture
      sampler2DArray         handle for accessing a 2D array texture
      sampler1DArrayShadow   handle for accessing a 1D array depth texture
                             with comparison
      sampler2DArrayShadow   handle for accessing a 2D array depth texture
                             with comparison
      samplerBuffer          handle for accessing a buffer texture

    Add a table 4.1.3 called "integer sampler types":

      isampler1D             handle for accessing an integer 1D texture
      isampler2D             handle for accessing an integer 2D texture
      isampler3D             handle for accessing an integer 3D texture
      isamplerCube           handle for accessing an integer cube map texture
      isampler2DRect         handle for accessing an integer rectangle texture
      isampler1DArray        handle for accessing an integer 1D array texture
      isampler2DArray        handle for accessing an integer 2D array texture
      isamplerBuffer         handle for accessing an integer buffer texture

    Add a table 4.1.4 called "unsigned integer sampler types":

      usampler1D             handle for accessing an unsigned integer 
                             1D texture
      usampler2D             handle for accessing an unsigned integer
                             2D texture
      usampler3D             handle for accessing an unsigned integer
                             3D texture
      usamplerCube           handle for accessing an unsigned integer
                             cube map texture
      usampler2DRect         handle for accessing an unsigned integer
                             rectangle texture
      usampler1DArray        handle for accessing an unsigned integer 1D
                             array texture 
      usampler2DArray        handle for accessing an unsigned integer 2D
                             array texture
      usamplerBuffer         handle for accessing an unsigned integer
                             buffer texture

    Change section 4.1.3 "Integers"

    Remove the first two paragraphs and replace with the following:

    Signed, as well as unsigned integers, are fully supported.  Integers hold
    whole numbers. Integers have at least 32 bits of precision, including a
    sign bit. Signed integers are stored using a two's complement
    representation.

    Integers are declared and optionally initialized with integer expressions
    as in the following example:

        int i, j = 42;
        unsigned int k = 3u;

    Literal integer constants can be expressed in decimal (base 10), octal
    (base 8), or hexadecimal (base 16) as follows.

          integer-constant:
                decimal-constant integer-suffix_opt
                octal-constant integer-suffix_opt
                hexadecimal-constant integer-suffix_opt

          integer-suffix:  one of
                u U

    Change section 4.3 "Type Qualifiers"

    Change the "varying" and "out" qualifier as follows:

    varying - linkage between a vertex shader and fragment shader, or between
    a fragment shader and the back end of the OpenGL pipeline.

    out - for function parameters passed back out of a function, but not
    initialized for use when passed in. Also for output varying variables
    (fragment only).

    In the qualifier table, add the following sub-qualifiers under the varying
    qualifier:

      flat varying
      noperspective varying
      centroid varying

    Change section 4.3.4 "Attribute"

    Change the sentence:

    The attribute qualifier can be used only with the data types float, vec2,
    vec3, vec4, mat2, mat3, and mat4.

    To:

    The attribute qualifier can be used only with the data types int, ivec2,
    ivec3, ivec4, unsigned int, uvec2, uvec3, uvec4, float, vec2, vec3, vec4,
    mat2, mat3, and mat4.

    Change the fourth paragraph to:

    It is expected that graphics hardware will have a small number of fixed
    locations for passing vertex attributes. Therefore, the OpenGL Shading
    language defines each non-matrix attribute variable as having space for up
    to four integer or floating-point values (i.e., a vec4, ivec4 or
    uvec4). There is an implementation dependent limit on the number of
    attribute variables that can be used and if this is exceeded it will cause
    a link error. (Declared attribute variables that are not used do not count
    against this limit.) A scalar attribute counts the same amount against
    this limit as a vector of size four, so applications may want to consider
    packing groups of four unrelated scalar attributes together into a vector
    to better utilize the capabilities of the underlying hardware. A mat4
    attribute will...

    Change section 4.3.6 "Varying"

    Change the first paragraph to:

    Varying variables provide the interface between the vertex shader, the
    fragment shader, and the fixed functionality between the vertex and
    fragment shader, as well as the interface from the fragment shader to the
    back-end of the OpenGL pipeline.

    The vertex shader will compute values per vertex (such as color, texture
    coordinates, etc.) and write them to variables declared with the varying
    qualifier. A vertex shader may also read varying variables, getting back
    the same values it has written. Reading a varying variable in a vertex
    shader returns undefined values if it is read before being written.

    The fragment shader will compute values per fragment and write them to
    variables declared with the varying out qualifier. A fragment shader may
    also read varying variables, getting back the same result it has
    written. Reading a varying variable in a fragment shader returns undefined
    values if it is read before being written.

    Varying variables may be written more than once. If so, the last value
    assigned is the one used.

    Change the second paragraph to:

    Varying variables that are set per vertex are interpolated by default in a
    perspective-correct manner over the primitive being rendered, unless the
    varying is further qualified with noperspective. Interpolation in a
    perspective correct manner is specified in equations 3.6 and 3.8 in the
    OpenGL 2.0 specification. When noperspective is specified, interpolation
    must be linear in screen space, as described in equation 3.7 and the
    approximation that follows equation 3.8.

    If single-sampling, the value is interpolated to the pixel's center, and
    the centroid qualifier, if present, is ignored. If multi-sampling, and the
    varying is not qualified with centroid, then the value must be
    interpolated to the pixel's center, or anywhere within the pixel, or to
    one of the pixel's samples. If multi-sampling and the varying is qualified
    with centroid, then the value must be interpolated to a point that lies in
    both the pixel and in the primitive being rendered, or to one of the
    pixel's samples that falls within the primitive.

    [NOTE: Language for centroid sampling taken from the GLSL 1.20.4
    specification]

    Varying variables, set per vertex, can be computed on a per-primitive
    basis (flat shading), or interpolated over a line or polygon primitive
    (smooth shading). By default, a varying variable is smooth shaded, unless
    the varying is further qualified with flat. When smooth shading, the
    varying is interpolated over the primitive. When flat shading, the varying
    is constant over the primitive, and is taken from the single provoking
    vertex of the primitive, as described in Section 2.14.7 of the OpenGL 2.0
    specification.

    Change the fourth paragraph to:

    The type and any qualifications (flat, noperspective, centroid) of varying
    variables with the same name declared in both the vertex and fragment
    shaders must match, otherwise the link command will fail. Note that
    built-in varying variables, which have names starting with "gl_", can not
    be further qualified with flat, noperspective or centroid. The flat
    keyword cannot be used together with either the noperspective or centroid
    keywords to further qualify a single varying variable, otherwise a compile
    error will occur. When using the keywords centroid, flat or noperspective,
    it must immediately precede the varying keyword.  When using both centroid
    and noperspective keywords, either one can be specified first. Only those
    varying variables used (i.e.  read) in the fragment shader must be written
    to by the vertex shader; declaring superfluous varying variables in the
    vertex shader is permissible. Varying out variables, set per fragment, can
    not be further qualified with flat, noperspective or centroid.

    Fragment shaders output values to the back-end of the OpenGL pipeline
    using either user-defined varying out variables or built-in variables, as
    described in section 7.2, unless the discard keyword is executed. If the
    back-end of the OpenGL pipeline consumes a user-defined varying out
    variable and an execution of a fragment shader does not write a value to
    that variable, then the value consumed is undefined. If the back-end of
    the OpenGL pipeline consumes a varying out variable and a fragment shader
    either writes values into less components of the variable, or if the
    variable is declared to have less components, than needed, the values of
    the missing component(s) are undefined. The OpenGL specification, section
    3.x.x, describes API to route varying output variables to color buffers.

    Add the following examples:

      noperspective varying float temperature;
      flat varying vec3 myColor;
      centroid varying vec2 myTexCoord;
      centroid noperspective varying vec2 myTexCoord;
      varying out ivec3 foo;

    Change the third paragraph on p. 25 as follows:

    The "varying" qualifier can be used only with the data types float, vec2,
    vec3, vec4, mat2, mat3, and mat4, int, ivec2, ivec3, ivec4, unsigned int,
    uvec2, uvec3, uvec4 or arrays of these.  Structures cannot be varying. If
    the varying is declared as one of the integer or unsigned integer data
    type variants, then it has to also be qualified as being flat shaded,
    otherwise a compile error will occur.

    The "varying out" qualifier can be used only with the data types float,
    vec2, vec3, vec4, int, ivec2, ivec3, ivec4, unsigned int, uvec2, uvec3 or
    uvec4. Structures or arrays cannot be declared as varying out.

    Change section 5.1 "Operators"

    Remove the "reserved" qualifications from the following operator
    precedence table entries:

      Precedence          Operator class
      ----------          -----------------------------------
          3               (tilde is reserved)
          4               (modulus reserved)
          6               bit-wise shift (reserved)
          9               bit-wise and (reserved)
         10               bit-wise exclusive or (reserved)
         11               bit-wise inclusive or (reserved)
         16               (modulus, shift, and bit-wise are reserved)

    Change section 5.8 "Assignments"

    Change the first bullet from:

       * The arithmetic assignments add into (+=)..

    To:

       * The arithmetic assignments add into (+=), subtract from (-
         =), multiply into (*=), and divide into (/=) as well as the
         assignments modulus into (%=), left shift by (<<=), right
         shift by (>>=), and into (&=), inclusive or into (|=),
         exclusive or into (^=). The expression

    Delete the last bullet in this paragraph.

    Remove the second bullet in the section starting with: The assignments
    modulus into..

    Change section 5.9 "Expressions"

    Change the bullet: The operator modulus (%) is reserved for future
    use to:

    * The arithmetic operator % that operates on signed or unsigned integer
      typed expressions (including vectors). The two operands must be of the
      same type, or one can be a signed or unsigned integer scalar and the
      other a signed or unsigned integer vector.  If the second operand is
      zero, results are undefined. If one operand is scalar and the other is a
      vector, the scalar is applied component-wise to the vector, resulting in
      the same type as the vector. If both operands are non-negative, then the
      remainder is non-negative. Results are undefined if one, or both,
      operands are negative.

    Change the last bullet: "Operators and (&), or (|), exclusive or (^), not
    (~), right-shift (>>), left shift (<<). These operators are reserved for
    future use." To the following bullets:

    * The one's complement operator ~. The operand must be of type signed or
      unsigned integer (including vectors), and the result is the one's
      complement of its operand. If the operand is a vector, the operator is
      applied component-wise to the vector. If the operand is unsigned, the
      result is computed by subtracting the value from the largest unsigned
      integer value. If the operand is signed, the result is computed by
      converting the operand to an unsigned integer, applying ~, and
      converting back to a signed integer.

    * The shift operators << and >>. For both operators, the operands must be
      of type signed or unsigned integer (including vectors). If the first
      operand is a scalar, the second operand has to be a scalar as well. The
      result is undefined if the right operand is negative, or greater than or
      equal to the number of bits in the left expression's type. The value of
      E1 << E2 is E1 (interpreted as a bit pattern) left-shifted by E2
      bits. The value of E1 >> E2 is E1 right-shifted by E2 bit positions.  If
      E1 is a signed integer, the right-shift will extend the sign bit. If E1
      is an unsigned integer, the right-shift will zero-extend.

    * The bitwise AND operator &. The operands must be of type signed or
      unsigned integer (including vectors). The two operands must be of the
      same type, or one can be a signed or unsigned integer scalar and the
      other a signed or unsigned integer vector. If one operand is a scalar
      and the other a vector, the scalar is applied component-wise to the
      vector, resulting in the same type as the vector. The result is the
      bitwise AND function of the operands.

    * The bitwise exclusive OR operator ^. The operands must be of type signed
      or unsigned integer (including vectors). The two operands must be of the
      same type, or one can be a signed or unsigned integer scalar and the
      other a signed or unsigned integer vector. If one operand is a scalar
      and the other a vector, the scalar is applied component-wise to the
      vector, resulting in the same type as the vector. The result is the
      bitwise exclusive OR function of the operands.

    * The bitwise inclusive OR operator |. The operands must be of type signed
      or unsigned integer (including vectors). The two operands must be of the
      same type, or one can be a signed or unsigned integer scalar and the
      other a signed or unsigned integer vector. If one operand is a scalar
      and the other a vector, the scalar is applied component-wise to the
      vector, resulting in the same type as the vector.  The result is the
      bitwise inclusive OR function of the operands.

    Change Section 7.1 "Vertex Shader Special Variables"

    Add the following definition to the list of built-in variable definitions:

          int gl_VertexID   // read-only
          int gl_InstanceID // read-only

    Add the following paragraph at the end of the section:

    The variable gl_VertexID is available as a read-only variable from within
    vertex shaders and holds the integer index <i> implicitly passed to
    ArrayElement() to specify the vertex. The value of gl_VertexID is defined
    if and only if:

      * the vertex comes from a vertex array command that specifies a complete
        primitive (e.g. DrawArrays, DrawElements),

      * all enabled vertex arrays have non-zero buffer object bindings, and

      * the vertex does not come from a display list, even if the display list
        was compiled using DrawArrays / DrawElements with data sourced from
        buffer objects.

    The variable gl_InstanceID is availale as a read-only variable from within
    vertex shaders and holds holds the integer index of the current primitive
    in an instanced draw call (DrawArraysInstancedEXT,
    DrawElementsInstancedEXT). If the current primitive does not come from an
    instanced draw call, the value of gl_InstanceID is zero.

    Change Section 7.2 "Fragment Shader Special Variables"

    Change the 8th and 9th paragraphs on p. 43 as follows:

    If a shader statically assigns a value to gl_FragColor, it may not assign
    a value to any element of gl_FragData nor to any user-defined varying
    output variable (section 4.3.6). If a shader statically writes a value to
    any element of gl_FragData, it may not assign a value to gl_FragColor nor
    to any user-defined varying output variable. That is, a shader may assign
    values to either gl_FragColor, gl_FragData, or any user-defined varying
    output variable, but not to a combination of the three options.

    If a shader executes the discard keyword, the fragment is discarded, and
    the values of gl_FragDepth, gl_FragColor, gl_FragData and any user-defined
    varying output variables become irrelevant.

    Add the following paragraph to the top of p. 44:

    The variable gl_PrimitiveID is available as a read-only variable from
    within fragment shaders and holds the id of the currently processed
    primitive. Section 3.11, subsection "Shader Inputs" of the OpenGL 2.0
    specification describes what value it holds based on the primitive type.

    Add the following prototype to the list of built-in variables accessible
    from a fragment shader:

         int gl_PrimitiveID;

    Change Chapter 8, sixth paragraph on page 50:

    Change the sentence:

    When the built-in functions are specified below, where the input arguments
    (and corresponding output)can be float, vec2, vec3, or vec4, genType is
    used as the argument.

    To:

    When the built-in functions are specified below, where the input arguments
    (and corresponding output) can be float, vec2, vec3, or vec4, genType is
    used as the argument. Where the input arguments (and corresponding output)
    can be int, ivec2, ivec3 or ivec4, genIType is used as the argument. Where
    the input arguments (and corresponding output) can be unsigned int, uvec2,
    uvec3, or uvec4, genUType is used as the argument.

    Add to section 8.3 "Common functions"

    Add integer versions of the abs, sign, min, max and clamp functions, as
    follows:

    Syntax:

      genIType abs(genIType x)

      genIType sign(genIType x)

      genIType min(genIType x, genIType y)
      genIType min(genIType x, int y)
      genUType min(genUType x, genUType y)
      genUType min(genUType x, unsigned int y)

      genIType max(genIType x, genIType y)
      genIType max(genIType x, int y)
      genUType max(genUType x, genUType y)
      genUType max(genUType x, unsigned int y)

      genIType clamp(genIType x, genIType minval, genIType maxval)
      genIType clamp(genIType x, int minval, int maxval)
      genUType clamp(genUType x, genUType minval, genUType maxval)
      genUType clamp(genUType x, unsigned int minval,
                     unsigned int maxval)

    Add the following new functions:

    Syntax:

      genType truncate(genType x)

    Description:

      Returns a value equal to the integer closest to x whose absolute value
      is not larger than the absolute value of x.

    Syntax:

      genType round(genType x)

    Description:

      Returns a value equal to the closest integer to x. If the fractional
      portion of the operand is 0.5, the nearest even integer is returned. For
      example, round (1.0) returns 1.0.  round(-1.5) returns -2.0. round(3.5)
      and round (4.5) both return 4.0.

    Add to section 8.6 "Vector Relational Functions"

    Change the sentence:

    Below, "bvec" is a placeholder for one of bvec2, bvec3, or bvec4, "ivec"
    is a placeholder for one of ivec2, ivec3, or ivec4, and "vec" is a
    placeholder for vec2, vec3, or vec4.

    To:

    Below, "bvec" is a placeholder for one of bvec2, bvec3, or bvec4, "ivec"
    is a placeholder for one of ivec2, ivec3, or ivec4, "uvec" is a
    placeholder for one of uvec2, uvec3 or uvec4 and "vec" is a placeholder
    for vec2, vec3, or vec4.

    Add uvec versions of all but the any, all and not functions to the table
    in this section, as follows:

       bvec lessThan(uvec x, uvec y)
       bvec lessThanEqual(uvec x, uvec y)

       bvec greaterThan(uvec x, uvec y)
       bvec greaterThanEqual(uvec x, uvec y)

       bvec equal(uvec x, uvec y)
       bvec notEqual(uvec x, uvec y)

    Add to section 8.7 "Texture Lookup Functions"

    Remove the first sentence in the last paragraph:

    "The built-ins suffixed with "Lod" are allowed only in a vertex shader.".

    Add to this section:

    Texture data can be stored by the GL as floating point, unsigned
    normalized integer, unsigned integer or signed integer data. This is
    determined by the type of the internal format of the texture.  Texture
    lookups on unsigned normalized integer and floating point data return
    floating point values in the range [0, 1]. See also section 2.15.4.1 of
    the OpenGL specification.

    Texture lookup functions are provided that can return their result as
    floating point, unsigned integer or signed integer, depending on the
    sampler type passed to the lookup function. Care must be taken to use the
    right sampler type for texture access. Table 8.xxx lists the supported
    combinations of sampler types and texture internal formats.

      texture
      internal      default (float) integer     unsigned integer
      format        sampler         sampler     sampler
      float         vec4            n/a          n/a
      normalized    vec4            n/a          n/a
      signed int    n/a             ivec4        n/a
      unsigned int  n/a             n/a          uvec4

    Table 8.xxx Valid combinations of the type of the internal format of a
    texture and the type of the sampler used to access the texture. Each cell
    in the table indicates the type of the return value of a texture
    lookup. N/a means this combination is not supported. A texture lookup
    using a n/a combination will return undefined values. The exceptions to
    this table are the "textureSize" lookup functions, which will return an
    integer or integer vector, regardless of the sampler type.

    If a texture with a signed integer internal format is accessed, one of the
    signed integer sampler types must be used. If a texture with an unsigned
    integer internal format is accessed, one of the unsigned integer sampler
    types must be used. Otherwise, one of the default (float) sampler types
    must be used. If the types of a sampler and the corresponding texture
    internal format do not match, the result of a texture lookup is undefined.

    If an integer sampler type is used, the result of a texture lookup is an
    ivec4. If an unsigned integer sampler type is used, the result of a
    texture lookup is a uvec4. If a default sampler type is used, the result
    of a texture lookup is a vec4, where each component is in the range [0,
    1].

    Integer and unsigned integer functions of all the texture lookup functions
    described in this section are also provided, except for the "shadow"
    versions, using function overloading. Their prototypes, however, are not
    listed separately. These overloaded functions use the integer or
    unsigned-integer versions of the sampler types and will return an ivec4 or
    an uvec4 respectively, except for the "textureSize" functions, which will
    always return an integer, or integer vector. Refer also to table 8.xxxx
    for valid combinations of texture internal formats and sampler types.  For
    example, for the texture1D function, the complete set of prototypes is:

       vec4 texture1D(sampler1D sampler, float coord
                      [, float bias])
       ivec4 texture1D(isampler1D sampler, float coord
                       [, float bias])
       uvec4 texture1D(usampler1D sampler, float coord
                       [, float bias])

    Add the following new texture lookup functions:

    Syntax:

      vec4 texelFetch1D(sampler1D sampler, int coord, int lod)
      vec4 texelFetch2D(sampler2D sampler, ivec2 coord, int lod)
      vec4 texelFetch3D(sampler3D sampler, ivec3 coord, int lod)
      vec4 texelFetch2DRect(sampler2DRect sampler, ivec2 coord)
      vec4 texelFetch1DArray(sampler1DArray sampler, ivec2 coord, int lod)
      vec4 texelFetch2DArray(sampler2DArray sampler, ivec3 coord, int lod)

    Description:

    Use integer texture coordinate <coord> to lookup a single texel from the
    level-of-detail <lod> on the texture bound to <sampler> as described in
    section 2.15.4.1 of the OpenGL specification "Texel Fetches". For the
    "array" versions, the layer of the texture array to access is either
    coord.t or coord.p, depending on the use of the 1D or 2D texel fetch
    lookup, respectively. Note that texelFetch2DRect does not take a
    level-of-detail input.

    Syntax:

      vec4 texelFetchBuffer(samplerBuffer sampler, int coord)

    Description:

    Use integer texture coordinate <coord> to lookup into the buffer texture
    bound to <sampler>.

    Syntax:

      int textureSizeBuffer(samplerBuffer sampler)
      int textureSize1D(sampler1D sampler, int lod)
      ivec2 textureSize2D(sampler2D sampler, int lod)
      ivec3 textureSize3D(sampler3D sampler, int lod)
      ivec2 textureSizeCube(samplerCube sampler, int lod)
      ivec2 textureSize2DRect(sampler2DRect sampler, int lod)
      ivec2 textureSize1DArray(sampler1DArray sampler, int lod)
      ivec3 textureSize2DArray(sampler2DArray sampler, int lod)

    Description:

    Returns the dimensions, width, height, depth, and number of layers, of
    level <lod> for the texture bound to <sampler>, as described in section
    2.15.4.1 of the OpenGL specification section "Texture Size Query". For the
    textureSize1DArray function, the first (".x") component of the returned
    vector is filled with the width of the texture image and the second
    component with the number of layers in the texture array. For the
    textureSize2DArray function, the first two components (".x" and ".y") of
    the returned vector are filled with the width and height of the texture
    image respectively. The third component (".z") is filled with the number
    of layers in the texture array.

    Syntax:

      vec4 texture1DArray(sampler1DArray sampler, vec2 coord
                          [, float bias])
      vec4 texture1DArrayLod(sampler1DArray sampler, vec2 coord,
                             float lod)

    Description:

    Use the first element (coord.s) of texture coordinate coord to do a
    texture lookup in the layer indicated by the second coordinate coord.t of
    the 1D texture array currently bound to sampler. The layer to access is
    computed by layer = max (0, min(d - 1, floor (coord.t + 0.5)) where 'd' is
    the depth of the texture array.

    Syntax:

      vec4 texture2DArray(sampler2DArray sampler, vec3 coord
                            [, float bias])
      vec4 texture2DArrayLod(sampler2DArray sampler, vec3 coord,
                               float lod)
    Description:

    Use the first two elements (coord.s, coord.t) of texture coordinate coord
    to do a texture lookup in the layer indicated by the third coordinate
    coord.p of the 2D texture array currently bound to sampler. The layer to
    access is computed by layer = max (0, min(d - 1, floor (coord.p + 0.5))
    where 'd' is the depth of the texture array.

    Syntax:

      vec4 shadow1DArray(sampler1DArrayShadow sampler, vec3 coord,
                         [float bias])
      vec4 shadow1DArrayLod(sampler1DArrayShadow sampler,
                            vec3 coord, float lod)
    Description:

    Use texture coordinate coord.s to do a depth comparison lookup on an array
    layer of the depth texture bound to sampler, as described in section
    3.8.14 of version 2.0 of the OpenGL specification. The layer to access is
    indicated by the second coordinate coord.t and is computed by layer = max
    (0, min(d - 1, floor (coord.t + 0.5)) where 'd' is the depth of the
    texture array. The third component of coord (coord.p) is used as the R
    value. The texture bound to sampler must be a depth texture, or results
    are undefined.

    Syntax:

      vec4 shadow2DArray(sampler2DArrayShadow sampler, vec4 coord)

    Description:

    Use texture coordinate (coord.s, coord.t) to do a depth comparison lookup
    on an array layer of the depth texture bound to sampler, as described in
    section 3.8.14 of version 2.0 of the OpenGL specification. The layer to
    access is indicated by the third coordinate coord.p and is computed by
    layer = max (0, min(d - 1, floor (coord.p + 0.5)) where 'd' is the depth
    of the texture array. The fourth component of coord (coord.q) is used as
    the R value. The texture bound to sampler must be a depth texture, or
    results are undefined.

    Syntax:

        vec4 shadowCube(samplerCubeShadow sampler, vec4 coord)

    Description:

    Use texture coordinate (coord.s, coord.t, coord.p) to do a depth
    comparison lookup on the depth cubemap bound to sampler, as described in
    section 3.8.14. The direction of the vector (coord.s, coord.t, coord.p) is
    used to select which face to do a two-dimensional texture lookup in, as
    described in section 3.8.6 of the OpenGL 2.0 specification. The fourth
    component of coord (coord.q) is used as the R value. The texture bound to
    sampler must be a depth cubemap, otherwise results are undefined.

    Syntax:

      vec4 texture1DGrad(sampler1D sampler, float coord, 
                         float ddx, float ddy);
      vec4 texture1DProjGrad(sampler1D sampler, vec2 coord, 
                             float ddx, float ddy);
      vec4 texture1DProjGrad(sampler1D sampler, vec4 coord, 
                             float ddx, float ddy);
      vec4 texture1DArrayGrad(sampler1DArray sampler, vec2 coord, 
                              float ddx, float ddy);

      vec4 texture2DGrad(sampler2D sampler, vec2 coord,
                         vec2 ddx, vec2 ddy);
      vec4 texture2DProjGrad(sampler2D sampler, vec3 coord,
                             vec2 ddx, vec2 ddy);
      vec4 texture2DProjGrad(sampler2D sampler, vec4 coord,
                             vec2 ddx, vec2 ddy);
      vec4 texture2DArrayGrad(sampler2DArray sampler, vec3 coord,
                              vec2 ddx, vec2 ddy);

      vec4 texture3DGrad(sampler3D sampler, vec3 coord,
                         vec3 ddx, vec3 ddy);
      vec4 texture3DProjGrad(sampler3D sampler, vec4 coord,
                             vec3 ddx, vec3 ddy);

      vec4 textureCubeGrad(samplerCube sampler, vec3 coord,
                           vec3 ddx, vec3 ddy);

      vec4 shadow1DGrad(sampler1DShadow sampler, vec3 coord,
                        float ddx, float ddy);
      vec4 shadow1DProjGrad(sampler1DShadow sampler, vec4 coord,
                            float ddx, float ddy);
      vec4 shadow1DArrayGrad(sampler1DArrayShadow sampler, vec3 coord,
                             float ddx, float ddy);

      vec4 shadow2DGrad(sampler2DShadow sampler, vec3 coord,
                        vec2 ddx, vec2 ddy);
      vec4 shadow2DProjGrad(sampler2DShadow sampler, vec4 coord,
                            vec2 ddx, vec2 ddy);
      vec4 shadow2DArrayGrad(sampler2DArrayShadow sampler, vec4 coord,
                             vec2 ddx, vec2 ddy);

      vec4 texture2DRectGrad(sampler2DRect sampler, vec2 coord,
                             vec2 ddx, vec2 ddy);
      vec4 texture2DRectProjGrad(sampler2DRect sampler, vec3 coord,
                                 vec2 ddx, vec2 ddy);
      vec4 texture2DRectProjGrad(sampler2DRect sampler, vec4 coord,
                                 vec2 ddx, vec2 ddy);

      vec4 shadow2DRectGrad(sampler2DRectShadow sampler, vec3 coord,
                            vec2 ddx, vec2 ddy);
      vec4 shadow2DRectProjGrad(sampler2DRectShadow sampler, vec4 coord,
                                vec2 ddx, vec2 ddy);

      vec4 shadowCubeGrad(samplerCubeShadow sampler, vec4 coord,
                          vec3 ddx, vec3 ddy);

    Description:

    The "Grad" functions map the partial derivatives ddx and ddy to ds/dx,
    dt/dx, dr/dx, and ds/dy, dt/dy, dr/dy respectively and use texture
    coordinate "coord" to do a texture lookup as described for their non
    "Grad" counterparts. The derivatives ddx and ddy are used as the explicit
    derivate of "coord" with respect to window x and window y respectively and
    are used to compute lambda_base(x,y) as in equation 3.18 in the OpenGL 2.0
    specification. For the "Proj" versions, it is assumed that the partial
    derivatives ddx and ddy are already projected. I.e. the GL assumes that
    ddx and ddy represent d(s/q)/dx, d(t/q)/dx, d(r/q)/dx and d(s/q)/dy,
    d(t/q)/dy, d(r/q)/dy respectively. For the "Cube" versions, the partial
    derivatives ddx and ddy are assumed to be in the coordinate system used
    before texture coordinates are projected onto the appropriate cube
    face. The partial derivatives of the post-projection texture coordinates,
    which are used for level-of-detail and anisotropic filtering
    calculations, are derived from coord, ddx and ddy in an
    implementation-dependent manner.

    NOTE: Except for the "array" and shadowCubeGrad() functions, these
    functions are taken from the ARB_shader_texture_lod spec and are
    functionally equivalent.

    Syntax:

      vec4 texture1DOffset(sampler1D sampler, float coord,
                           int offset [,float bias])
      vec4 texture1DProjOffset(sampler1D sampler, vec2 coord,
                               int offset [,float bias])
      vec4 texture1DProjOffset(sampler1D sampler, vec4 coord,
                               int offset [,float bias])
      vec4 texture1DLodOffset(sampler1D sampler, float coord,
                              float lod, int offset)
      vec4 texture1DProjLodOffset(sampler1D sampler, vec2 coord,
                                  float lod, int offset)
      vec4 texture1DProjLodOffset(sampler1D sampler, vec4 coord,
                                  float lod, int offset)

      vec4 texture2DOffset(sampler2D sampler, vec2 coord,
                           ivec2 offset [,float bias])
      vec4 texture2DProjOffset(sampler2D sampler, vec3 coord,
                               ivec2 offset [,float bias])
      vec4 texture2DProjOffset(sampler2D sampler, vec4 coord,
                               ivec2 offset [,float bias])
      vec4 texture2DLodOffset(sampler2D sampler, vec2 coord,
                              float lod, ivec2 offset)
      vec4 texture2DProjLodOffset(sampler2D sampler, vec3 coord,
                                  float lod, ivec2 offset)
      vec4 texture2DProjLodOffset(sampler2D sampler, vec4 coord,
                                  float lod, ivec2 offset)

      vec4 texture3DOffset(sampler3D sampler, vec3 coord,
                           ivec3 offset [,float bias])
      vec4 texture3DProjOffset(sampler3D sampler, vec4 coord,
                               ivec3 offset [,float bias])
      vec4 texture3DLodOffset(sampler3D sampler, vec3 coord,
                              float lod, ivec3 offset)
      vec4 texture3DProjLodOffset(sampler3D sampler, vec4 coord,
                                  float lod, ivec3 offset)

      vec4 shadow1DOffset(sampler1DShadow sampler, vec3 coord,
                          int offset [,float bias])
      vec4 shadow2DOffset(sampler2DShadow sampler, vec3 coord,
                          ivec2 offset [,float bias])
      vec4 shadow1DProjOffset(sampler1DShadow sampler, vec4 coord,
                              int offset [,float bias])
      vec4 shadow2DProjOffset(sampler2DShadow sampler, vec4 coord,
                              ivec2 offset [,float bias])
      vec4 shadow1DLodOffset(sampler1DShadow sampler, vec3 coord, 
                             float lod, int offset)
      vec4 shadow2DLodOffset(sampler2DShadow sampler, vec3 coord,
                             float lod, ivec2 offset)
      vec4 shadow1DProjLodOffset(sampler1DShadow sampler, vec4 coord,
                                 float lod, int offset)
      vec4 shadow2DProjLodOffset(sampler2DShadow sampler, vec4 coord,
                                 float lod, ivec2 offset)

      vec4 texture2DRectOffset(sampler2DRect sampler, vec2 coord,
                               ivec2 offset)
      vec4 texture2DRectProjOffset(sampler2DRect sampler, vec3 coord,
                                   ivec2 offset)
      vec4 texture2DRectProjOffset(sampler2DRect sampler, vec4 coord,
                                   ivec2 offset)
      vec4 shadow2DRectOffset(sampler2DRectShadow sampler, vec3 coord,
                              ivec2 offset)
      vec4 shadow2DRectProjOffset(sampler2DRectShadow sampler, vec4 coord, 
                                  ivec2 offset)

      vec4 texelFetch1DOffset(sampler1D sampler, int coord, int lod,
                              int offset)
      vec4 texelFetch2DOffset(sampler2D sampler, ivec2 coord, int lod, 
                              ivec2 offset)
      vec4 texelFetch3DOffset(sampler3D sampler, ivec3 coord, int lod, 
                              ivec3 offset)
      vec4 texelFetch2DRectOffset(sampler2DRect sampler, ivec2 coord, 
                                  ivec2 offset)
      vec4 texelFetch1DArrayOffset(sampler1DArray sampler, ivec2 coord, 
                                   int lod, int offset)
      vec4 texelFetch2DArrayOffset(sampler2DArray sampler, ivec3 coord, 
                                   int lod, ivec2 offset)

      vec4 texture1DArrayOffset(sampler1DArray sampler, vec2 coord,
                                int offset [, float bias])
      vec4 texture1DArrayLodOffset(sampler1DArray sampler, vec2 coord,
                                   float lod, int offset)

      vec4 texture2DArrayOffset(sampler2DArray sampler, vec3 coord,
                                ivec2 offset [, float bias])
      vec4 texture2DArrayLodOffset(sampler2DArray sampler, vec3 coord,
                                   float lod, ivec2 offset)

      vec4 shadow1DArrayOffset(sampler1DArrayShadow sampler, vec3 coord,
                               int offset, [float bias])
      vec4 shadow1DArrayLodOffset(sampler1DArrayShadow sampler, vec3 coord,
                                  float lod, int offset)

      vec4 shadow2DArrayOffset(sampler2DArrayShadow sampler,
                               vec4 coord, ivec2 offset)

      vec4 texture1DGradOffset(sampler1D sampler, float coord,
                               float ddx, float ddy, int offset);
      vec4 texture1DProjGradOffset(sampler1D sampler, vec2 coord,
                                   float ddx, float ddy, int offset);
      vec4 texture1DProjGradOffset(sampler1D sampler, vec4 coord,
                                   float ddx, float ddy, int offset);
      vec4 texture1DArrayGradOffset(sampler1DArray sampler, vec2 coord,
                                    float ddx, float ddy, int offset);

      vec4 texture2DGradOffset(sampler2D sampler, vec2 coord,
                               vec2 ddx, vec2 ddy, ivec2 offset);
      vec4 texture2DProjGradOffset(sampler2D sampler, vec3 coord,
                                   vec2 ddx, vec2 ddy, ivec2 offset);
      vec4 texture2DProjGradOffset(sampler2D sampler, vec4 coord,
                                   vec2 ddx, vec2 ddy, ivec2 offset);
      vec4 texture2DArrayGradOffset(sampler2DArray sampler, vec3 coord,
                                    vec2 ddx, vec2 ddy, ivec2 offset);

      vec4 texture3DGradOffset(sampler3D sampler, vec3 coord,
                               vec3 ddx, vec3 ddy, ivec3 offset);
      vec4 texture3DProjGradOffset(sampler3D sampler, vec4 coord,
                                   vec3 ddx, vec3 ddy, ivec3 offset);

      vec4 shadow1DGradOffset(sampler1DShadow sampler, vec3 coord,
                              float ddx, float ddy, int offset);
      vec4 shadow1DProjGradOffset(sampler1DShadow sampler,
                                  vec4 coord, float ddx, float ddy,
                                  int offset);
      vec4 shadow1DArrayGradOffset(sampler1DArrayShadow sampler,
                                   vec3 coord, float ddx, float ddy,
                                   int offset);

      vec4 shadow2DGradOffset(sampler2DShadow sampler, vec3 coord,
                              vec2 ddx, vec2 ddy, ivec2 offset);
      vec4 shadow2DProjGradOffset(sampler2DShadow sampler, vec4 coord, 
                                  vec2 ddx, vec2 ddy, ivec2 offset);
      vec4 shadow2DArrayGradOffset(sampler2DArrayShadow sampler, 
                                   vec4 coord, vec2 ddx, vec2 ddy, 
                                   ivec2 offset);

      vec4 texture2DRectGradOffset(sampler2DRect sampler, vec2 coord,
                                   vec2 ddx, vec2 ddy, ivec2 offset);
      vec4 texture2DRectProjGradOffset(sampler2DRect sampler, vec3 coord, 
                                       vec2 ddx, vec2 ddy, ivec2 offset);
      vec4 texture2DRectProjGradOffset(sampler2DRect sampler, vec4 coord,
                                       vec2 ddx, vec2 ddy, ivec2 offset);

      vec4 shadow2DRectGradOffset(sampler2DRectShadow sampler, 
                                  vec3 coord, vec2 ddx, vec2 ddy, 
                                  ivec2 offset);
      vec4 shadow2DRectProjGradOffset(sampler2DRectShadow sampler, 
                                      vec4 coord, vec2 ddx, vec2 ddy, 
                                      ivec2 offset);

    Description:

    The "offset" version of each function provides an extra parameter <offset>
    which is added to the (u,v,w) texel coordinates before looking up each
    texel. The offset value must be a constant expression.  A limited range
    of offset values are supported; the minimum and maximum offset values are
    implementation-dependent and given by MIN_PROGRAM_TEXEL_OFFSET_EXT and
    MAX_PROGRAM_TEXEL_OFFSET_EXT, respectively. Note that <offset> does not
    apply to the layer coordinate for texture arrays. This is explained in
    detail in section 3.8.7 of the OpenGL Specification. Note that texel
    offsets are also not supported for cubemaps or buffer textures.

    Add to section 9 "Grammar"

      type_qualifer:
          CONST
          ATTRIBUTE  // Vertex only
          varying-modifier_opt VARYING
          UNIFORM

      varying-modifier:
          FLAT
          CENTROID
          NOPERSPECTIVE

      type_specifier:
          VOID
          FLOAT
          INT
          UNSIGNED_INT
          BOOL

Issues

    1. Should we support shorts in GLSL?

     DISCUSSION:

     RESOLUTION: UNRESOLVED

    2. Do bitwise shifts, AND, exclusive OR and inclusive OR support all
       combinations of scalars and vectors for each operand?

     DISCUSSION: It seems sense to support scalar OP scalar, vector OP scalar
     and vector OP vector. But what about scalar OP vector?  Should the scalar
     be promoted to a vector first?

     RESOLUTION: RESOLVED. Yes, this should work essentially as the '+'
     operator. The scalar is applied to each component of the vector.

   3. Which built-in functions should also operate on integers?

     DISCUSSION: There are several that don't make sense to define to operate
     on integers at all, but the following can be debated: pow, sqrt, dot (and
     the functions that use dot), cross.

     RESOLUTION: RESOLVED. Integer versions of the abs, sign, min, max and
     clamp functions are defined. Note that the modulus operator % has been
     defined for integer operands.

   4. Do we need to support integer matrices?

     DISCUSSION:

     RESOLUTION: RESOLVED No, not at the moment.

   5. Which texture array lookup functions do we need to support?

     DISCUSSION: We don't want to support lookup functions that need more than
     four components passed as parameters. Components can be used for texture
     coordinates, layer selection, 'R' depth compare and the 'q' coordinate
     for projection. However, texture projection might be relatively easy to
     support through code-generation, thus we might be able to support
     functions that need five components, as long as one of them is 'q' for
     projective texturing.  Specifically, should we support:

       vec4 texture2DArrayProjLod(sampler2DArray sampler, vec4 coord,
                                  float lod)
       vec4 shadow1DArray(sampler1DArrayShadow sampler, vec3 coord,
                        [float bias])
       vec4 shadow1DArrayProj(sampler1DArrayShadow sampler, vec4 coord,
                              [float bias])
       vec4 shadow1DArrayLod(sampler1DArrayShadow sampler, vec3 coord,
                             float lod)
       vec4 shadow1DArrayProjLod(sampler1DArrayShadow sampler,
                                 vec4 coord, float lod)
       vec4 shadow2DArray(sampler2DArrayShadow sampler, vec4 coord)
       vec4 shadow2DArrayProj(sampler2DArrayShadow sampler, vec4 coord,
                              float refValue)

      RESOLUTION: RESOLVED, We'll support all but the "Proj" versions.  The
      assembly spec (NV_gpu_program4) doesn't support the equivalent
      functionality, either.

    6. How do we handle conversions between integer and unsigned
    integers?

      DISCUSSION: Do we allow automatic type conversions between signed and
      unsigned integers?

      RESOLUTION: RESOLVED. We will not add this until GLSL version 1.20 has
      been defined, and the implicit conversion rules have been established
      there. If we do this, we would likely only support implicit conversion
      from int to unsigned int, just like C does.

    7. Should varying modifiers (flat, noperspective) apply to built-in
       varying variables also?

      DISCUSSION: There is API to control flat vs smooth shading for colors
      through glShadeModel(). There is also API to hint if colors should be
      interpolated perspective correct, or not, through glHint(). These API
      commands apply to the built-in color varying variables (gl_FrontColor
      etc). If the varying modifiers in a shader also apply to the color
      built-ins, which has precedence?

      RESOLUTION: RESOLVED. It is simplest and cleanest to only allow the
      varying modifiers to apply to user-defined varying variables.  The
      behavior of the built-in color varying variables can still be controlled
      through the API.

    8. How should perspective-incorrect interpolation (linear in screen space)
       and clipping interact?

      RESOLVED:  Primitives with attributes specified to be perspective-
      incorrect should be clipped so that the vertices introduced by clipping
      should have attribute values consistent with the interpolation mode.  We
      do not want to have large color shifts introduced by clipping a
      perspective-incorrect attribute.  For example, a primitive that
      approaches, but doesn't cross, a frustum clip plane should look pretty
      much identical to a similar primitive that just barely crosses the clip
      plane.

      Clipping perspective-incorrect interpolants that cross the W==0 plane is
      very challenging.  The attribute clipping equation provided in the spec
      effectively projects all the original vertices to screen space while
      ignoring the X and Y frustum clip plane.  As W approaches zero, the
      projected X/Y window coordinates become extremely large.  When clipping
      an edge with one vertex inside the frustum and the other out near
      infinity (after projection, due to W approaching zero), the interpolated
      attribute for the entire visible portion of the edge should almost
      exactly match the attribute value of the visible vertex.

      If an outlying vertex approaches and then goes past W==0, it can be said
      to go "to infinity and beyond" in screen space.  The correct answer for
      screen-linear interpolation is no longer obvious, at least to the author
      of this specification.  Rather than trying to figure out what the
      "right" answer is or if one even exists, the results of clipping such
      edges is specified as undefined.

    9. Do we need to support a non-MRT fragment shader writing to (unsigned)
       integer outputs?

      DISCUSSION: Fragment shaders with only one fragment output are
      considered non-MRT shaders. This means that the output of the shader
      gets smeared across all color buffers attached to the
      framebuffer. Fragment shaders with multiple fragment outputs are MRT
      shaders. Each output is directed to a color buffer using the DrawBuffers
      API (for gl_FragData) and a combination of the BindFragDataLocationEXT
      and DrawBuffers API (for varying out variables). Before this extension,
      a non-MRT shader would write to gl_Color only. A shader writing to
      gl_FragData[] is a MRT shader.  With the addition of varying out
      variables in this extension, any shader writing to a variable out
      variable is a MRT shader. It is not possible to construct a non-MRT
      shader writing to varying out variables. Varying out variables can be
      declared to be of type integer or unsigned integer. In order to support
      a non-MRT shader that can write to (unsigned) integer outputs, we could
      define two new built-in variables:

        ivec4 gl_FragColorInt;
        uvec4 gl_FragColorUInt;

      Or we could add a special rule stating that if the program object writes
      to exactly one varying out variable, it is considered to be non-MRT.

      RESOLUTION: NO. We don't care enough to support this.

   10. Is section 2.14.8, "Color and Associated Data Clipping" in the core
       specification still correct?

      DISCUSSION: This section is in need of some updating, now that varying
      variables can be interpolated without perspective correction. Some (not
      so precise) language has been added in the spec body, suggesting that
      the interpolation needs to be performed in such a way as to produce
      results that vary linearly in screen space. However, we could define the
      exact interpolation method required to achieve this. A suggested updated
      paragraph follows, but we'll leave updating section 2.14.8 to a future
      edit of the core specification, not this extension.

      Replace Section 2.14.8, and rename it to "Vertex Attribute Clipping"

      After lighting, clamping or masking and possible flatshading, vertex
      attributes, including colors, texture and fog coordinates, shader
      varying variables, and point sizes computed on a per vertex basis, are
      clipped. Those attributes associated with a vertex that lies within the
      clip volume are unaffected by clipping.  If a primitive is clipped,
      however, the attributes assigned to vertices produced by clipping are
      produced by interpolating attributes along the clipped edge.

      Let the attributes assigned to the two vertices P_1 and P_2 of an
      unclipped edge be a_1 and a_2.  The value of t (section 2.12) for a
      clipped point P is used to obtain the attribute associated with P as

          a = t * a_1 + (1-t) * a_2

      unless the attribute is specified to be interpolated without perspective
      correction in a shader (using the noperspective keyword).  In that case,
      the attribute associated with P is

          a = t' * a_1 + (1-t') * a_2

      where

          t' = (t * w_1) / (t * w_1 + (1-t) * w_2)

      and w_1 and w_2 are the w clip coordinates of P_1 and P_2,
      respectively. If w_1 or w_2 is either zero or negative, the value of the
      associated attribute is undefined.

      For a color index color, multiplying a color by a scalar means
      multiplying the index by the scalar. For a vector attribute, it means
      multiplying each vector component by the scalar. Polygon clipping may
      create a clipped vertex along an edge of the clip volume's
      boundary. This situation is handled by noting that polygon clipping
      proceeds by clipping against one plane of the clip volume's boundary at
      a time. Attribute clipping is done in the same way, so that clipped
      points always occur at the intersection of polygon edges (possibly
      already clipped) with the clip volume's boundary.

  11. When and where in the texture filtering process are texel offsets
      applied?

      DISCUSSION: Texel offsets are applied to the (u,v,w) coordinates of the
      base level of the texture if the texture filter mode does not indicate
      mipmapping. Otherwise, texel offsets are applied to the (u,v,w)
      coordinates of the mipmap level 'd', as found by equation 3.27 or to
      mipmap levels 'd1' and 'd2' as found by equation 3.28 in the OpenGL 2.0
      specification.  In other words, texel offsets are applied to the
      (u,v,w) coordinate of whatever mipmap level is accessed.

  12. Why is writing to the built-in output variable "gl_Position" in a vertex
      shader now optional?

      DISCUSSION: Before this specification, writing to gl_Position in a
      vertex shader was mandatory. The GL pipeline required a vertex position
      to be written in order to produce well-defined output. This is still the
      case if the GL pipeline indeed needs a vertex position. However, with
      fourth-generation programmable hardware there are now cases where the GL
      pipeline no longer requires a vertex position in order to produce
      well-defined results. If a geometry shader is present, the vertex shader
      does not need to write to gl_Position anymore. Instead, the geometry
      shader can compute a vertex position and write to its gl_Position
      output. In case of transform-feedback, where the output of a vertex or
      geometry shader is streamed to one or more buffer objects, perfectly
      valid results can be obtained without either the vertex shader nor
      geometry shader writing to gl_Position. The transform-feedback
      specification adds a new enable to discard primitives right before
      rasterization, making it potentially unnecessary to write to
      gl_Position.

  13. How does this extension interact with ARB_shader_texture_lod?

      DISCUSSION:  This extension adds "Grad" functions which are functionally
      equivalent to those defined by ARB_shader_texture_lod, but do not have
      an ARB suffix.
      
      RESOLUTION: There is no interaction. If both extensions are supported,
      both sets of functions are available and can be controlled independently
      via the #extension mechanism.


Revision History

    Rev.    Date    Author    Changes
    ----  --------  --------  -----------------------------------------
     16   12/14/09  mgodse    Added GLX protocol.

     15   04/09/09  pbrown    Fixed a typo in the texture size query spec
                              language - returns a layer count, not "index".

     14   07/29/08  pbrown    Discovered additional issues with texture wrap 
                              handling, replaced with logic that applies wrap
                              modes per sample.

     13   04/04/08  pbrown    Added issue 13, concerning the (non-)interaction
                              with ARB_shader_texture_lod.

     12   02/04/08  pbrown    Fix errors in texture wrap mode handling.
                              Added a missing clamp to avoid sampling border
                              in REPEAT mode.  Fixed incorrectly specified
                              weights for LINEAR filtering.

     11   05/08/07  pbrown    Add VertexAttribIPointerEXT to the list of
                              commands that can't go in display lists.

     10   01/23/07  pbrown    Fix prototypes for a variety of functions 
                              that were specified with an incorrect sampler
                              type.

      9   12/15/06  pbrown    Documented that the '#extension' token
                              for this extension should begin with "GL_",
                              as apparently called for per convention.

      8      --               Pre-release revisions.