Name

    ARB_fragment_shader

Name Strings

    GL_ARB_fragment_shader

Contributors

    Dave Baldwin
    Pat Brown
    Evan Hart
    Phil Huxley
    Dale Kirkland
    John Kessenich
    Steve Koren
    Jon Leech
    Bill Licea-Kane
    Benjamin Lipchak
    Barthold Lichtenbelt
    Kent Lin
    Jeremy Morris
    Teri Morrison
    Glenn Ortner
    Randi Rost
    Jeremy Sandmel

    The ARB_fragment_program working group members. Several concepts and
    chunks of text are copied from the ARB_fragment_program specification.

Contact

    Barthold Lichtenbelt, 3Dlabs, Inc. (barthold 'at' 3dlabs.com)
    Randi Rost, 3Dlabs, Inc. (rost 'at' 3dlabs.com)

Notice

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

Specification Update Policy

    Khronos-approved extension specifications are updated in response to
    issues and bugs prioritized by the Khronos OpenGL Working Group. For
    extensions which have been promoted to a core Specification, fixes will
    first appear in the latest version of that core Specification, and will
    eventually be backported to the extension document. This policy is
    described in more detail at
        https://www.khronos.org/registry/OpenGL/docs/update_policy.php

IP Status

    As described in the Contributor License, which can be found at
    http://www.3dlabs.com/support/developer/ogl2/specs/3dlabs_contributor.pdf.

Status

    Complete. Approved by the ARB on June 11, 2003.
    Updated revision 0.79 approved by the ARB on June 17, 2004.

Version

    Last Modified Date: December 12, 2006
    Author Revision: 0.80

Number

    ARB Extension #32

Dependencies

    OpenGL 1.0 is required.

    This extension is written against version 1.10 of the OpenGL Shading
    Language Specification.

    The extension is written against the OpenGL 1.4 Specification.

    The ARB_shader_objects extension is required.

    This extension interacts with the ARB_vertex_shader extension.

Overview

    This extension adds functionality to define fragment shader objects. A
    fragment shader object is a shader object (see the ARB_shader_objects
    extension) that, when attached to a program object, can be compiled and
    linked to produce an executable that runs on the fragment processor in
    OpenGL. The fragment processor is a programmable unit that replaces the
    OpenGL 1.4 fixed-function texturing, color sum and fog stages. This
    extension also defines how such an executable interacts with the fixed
    functionality fragment processing of OpenGL 1.4. The language used to
    write fragment shaders is not discussed here. That language is defined
    in the OpenGL Shading Language specification as the Fragment Shading
    Language.

Issues
    1) Can you clarify texture unit, texture image unit and texture
       coordinate sets please?

    DISCUSSION: In 'old style' GL a texture unit consists of a texture
    coordinate processing unit (consisting of a texture matrix stack and
    texture coordinate generation state), and a texture image unit, with all
    the texture state defined in section 3.8, as well as texture environment
    state, as defined in section 3.8.12. The implementation dependent number
    of supported texture units in 'old style' GL is MAX_TEXTURE_UNITS.

    In this specification a texture unit consist of one or both of a texture
    image unit, and a texture coordinate set. The implementation dependent
    number of supported texture image units is MAX_TEXTURE_IMAGE_UNITS_ARB
    and the number of supported texture coordinate sets is
    MAX_TEXTURE_COORDS_ARB.

    The maximum available multi-texture stages (to the fixed-function
    pipeline) are MAX_TEXTURE_UNITS. A fragment shader has access to at
    least MAX_TEXTURE_UNITS texture image units, and possibly more, up to
    MAX_TEXTURE_IMAGE_UNITS_ARB. Where MAX_TEXTURE_IMAGE_UNITS_ARB is equal
    or greater than MAX_TEXTURE_UNITS.

    RESOLUTION: Yes

    2) Should we split the number of available texture coordinate sets and
       texture units?

    DISCUSSION: Some implementations might provide for more texture image
    units than texture coordinate sets. Texture coordinates for the 'new'
    texture image units can be derived from other texture coordinates, or
    provided through a texture lookup. These new texture coordinates can be
    used to index different textures bound to different texture image units.

    RESOLUTION: YES, splitting this is useful.

    3) Is the texture environment state associated with all texture image
       units?

    DISCUSSION: A fragment shader has access to the texture environment
    color through the shader built-in array gl_TexEnvColor. This array has
    MAX_TEXTURE_IMAGE_UNITS_ARB elements. It is also possible, and useful,
    to set the texture environment state TEXTURE_LOD_BIAS for all texture
    image units. All other texture environment state is not accessible to a
    fragment shader (for example, TEXTURE_ENV_MODE, COMBINE_RGB etc).
    However, an application can still set this state (and query it).

    Note that fixed-function GL caps the number of supported texture stages
    to MAX_TEXTURE_UNITS. This limit is generally below the number of
    texture image units available to a fragment shader. Each of these
    MAX_TEXTURE_UNITS texture stages need all texture environment state for
    the multi-texture pipeline to function correctly. Texture units above
    this limit still have all the texture environment state associated with
    it, even although this state is not accessible in a fragment shader.

    Note that ARB_fragment_program also does this, except that it caps
    access to the texture environment state to the first MAX_TEXTURE_UNITS
    texture image units.

    RESOLUTION: Yes.

    4) What to do about invariance rules (Appendix A)?

    DISCUSSION: Numerous rules and proposals have been discussed. In the
    end, simplicity is an important goal. It is always possible to later add
    more invariance rules, if it turns out to be desirable.

    RESOLUTION: The same shader will produce the same result when run
    multiple times with the same input. The wording 'the same shader' means
    a program object that is populated with the same source strings, which
    are compiled and then linked, possibly multiple times. This program
    object is executed using the same GL state vector.

    Besides the above general statement, we will limit this specification to
    one invariance rule with respect to depth produced by a fragment shader:

    All shaders that either conditionally or unconditionally copy the input
    gl_FragCoord.z to the output gl_FragDepth are depth-invariant with
    respect to each other, for those fragments where this copy actually is
    done.

    Note that a fragment shader that does not write to gl_FragDepth is
    depth-invariant with fixed function (since fixed function depth will be
    used for the fragment when gl_FragDepth is not written).

    See also Appendix A.

    5) Should the output from the pixel rectangle rasterization and bitmap
       rasterization stages feed into a fragment shader?

    DISCUSSION: See also Issue 2 in the OpenGL Shading Language
    specification. Future API additions could make the operations DrawPixels
    performs programmable. For the list of specific operations that could be
    replaced see Section 3.6.4, Figure 3.7 in the OpenGL 1.4 specification.
    Combined with the proposed pack/unpack language, and the proposed pack
    and unpack processors, such a future extension will become an extremely
    powerful and flexible imaging pipeline.

    Most of the harder parts to implement the functionality in Figure 3.7
    result from the imaging subset. A conceivable way to implement this
    functionality is by using the programmable fragment unit. However, if
    the results from the pixel rectangle and bitmap rasterization stages did
    feed into the fragment shader, then implementing all the functionality
    in Figure 3.7 might become hard or impossible, when a fragment shader is
    also active. A possibility that was considered was to say that if a
    fragment shader was active, pixel transfer functionality such as scale
    and bias, color matrix, lookup, etc., was disabled. A fragment shader
    could perform these kinds of operations, after all.

    ARB_fragment_program does feed the result of pixel rectangle and bitmap
    rasterization into the fragment shader.

    RESOLUTION: Yes, this allows fragment shaders to do image processing
    type of operations on pixel rectangles and bitmaps.

    Note that a fragment shader that is processing fragments resulting from
    rasterization of pixel rectangles or bitmaps, can only reference
    built-in varying variables starting with "gl_" (gl_Color,
    gl_SecondaryColor, gl_TexCoord[] and gl_FogFragCoord). The fragments
    produced as a result of rasterizing a pixel rectangle or bitmap have
    associated values for those varying variables. If the fragment shader
    uses a user-defined varying, results are undefined.

    6) What about clamping and conversion for color and depth output
       variables?

    DISCUSSION: The output variables gl_FragDepth and gl_FragColor are in
    floating point format. However, the GL 1.4 pipeline following the
    fragment shader expects these values to be in fixed-point, and clamped
    to the range [0,1].

    RESOLUTION: Color and depth values written by the fragment shader will
    be automatically clamped to the range [0,1] and then converted, as
    appropriate, to a fixed-point representation. See section 3.11.6.

    7) What about clamping and conversion for color and depth input varying
       variables?

    DISCUSSION: This ties in with issue 18 in the ARB_vertex_shader
    specification. There are three cases to consider:

      1) An ARB_vertex_shader shader writing colors that are consumed by an
         ARB_fragment_shader shader.
      2) An ARB_vertex_program shader writing colors that are consumed by an
         ARB_fragment_shader shader.
      3) Fixed functionality vertex processing outputting colors that are
         consumed by an ARB_fragment_shader shader.

    Fixed function vertex processing as well as ARB_vertex_shader and
    ARB_vertex_program do clamp colors automatically to [0,1]. In all three
    cases colors are next converted to fixed-point (section 2.13.9).

    RESOLUTION: Depth and color values will be converted to floating-point
    before entering the fragment shader.

    8) What controls the value of the shader built-in Boolean
       gl_FrontFacing?

    DISCUSSION: The OpenGL Shading Language says the following: "The
    fragment shader has access to the read-only built-in variable
    gl_FrontFacing whose value is true if the fragment belongs to a
    front-facing primitive."

    This specification defines when a fragment is considered front-facing.

    A fragment derives its facing direction from the primitive that
    generates the fragment. All fragments generated by primitives other than
    polygons, triangles, or quadrilaterals are considered to be front
    facing. For all other fragments (including ones resulting from point-
    and line-mode polygons) the determination is made by examining the sign
    of the area computed by equation 2.6 of section 2.13.1 (including the
    possible reversal of this sign as indicated by the last call to
    FrontFace). If the sign is positive then the fragments are front facing;
    otherwise, they are back facing.

    ARB_vertex_shader has an enable called VERTEX_PROGRAM_TWO_SIDE_ARB. If
    false, the front color is always selected. However, this enable does not
    apply to the front or back facing determination of a fragment. The value
    of VERTEX_PROGRAM_TWO_SIDE_ARB does not affect the value of
    gl_FrontFacing. Thus you can have the following situation:

      * VERTEX_PROGRAM_TWO_SIDE_ARB = FALSE. Which forces the front color to
        always be selected. Thus gl_Color and gl_SecondaryColor (read-only
        accessible in the fragment shader) have the values of the varyings
        gl_FrontColor and gl_FrontSecondaryColor (written by the vertex
        shader).
      * The primitive is a polygon and is determined to be back-facing.
        gl_FrontFacing therefore = FALSE.

    RESOLUTION: Depending on the primitive type it is either always front
    facing, or it is determined by he sign of the polygon's area computed in
    window coordinates.

    9) OpenGL provides a hierarchy of texture enables (cube map, 3D, 2D,
       1D). Should samplers override that hierarchy and select specific
       texture targets?

    DISCUSSION: How samplers work is explained in issue 25 of the
    ARB_shader_objects specification.

    RESOLUTION: Yes. This removes a potential pitfall for developers:
    Leaving the hierarchy of enables in an undesired state. It makes shaders
    more readable as the intent of the code is more obvious. It allows
    compilers to be more aggressive as to which texture coordinate
    components are "don't cares" without having to recompile programs when
    fixed-function texture enables change.

    Note that the ARB_shader_objects specification states that it is not
    allowed to have samplers of different types point to the same texture
    image unit. For example, it is not possible to request a 2D and a 3D
    texture lookup using the same texture image unit within a program
    object.

    10) Is Depth Offset applied to the window z value before it enters the
        fragment shader?

    DISCUSSION: Depth Offset (polygon offset) is discussed in section 3.5.5
    of the GL 1.4 spec. Depth offset is considered part of the rasterization
    stage, which happens prior to processing of a fragment shader.

    RESOLUTION: As in the base OpenGL specification, the depth offset
    generated by polygon offset is added during polygon rasterization. The
    depth value provided to shaders in the built-in gl_FragCoord.z already
    includes polygon offset, if enabled. If the depth value is replaced by a
    fragment shader, the polygon offset value will NOT be recomputed and
    added back after shader execution.

    NOTE: This is probably not desirable for fragment shaders that modify
    depth values since the partials used to generate the offset may not
    match the partials of the computed depth value.

    11) Should gl_FragColor be aliased to gl_FragData[0]?

    RESOLUTION: No. A shader should write either gl_FragColor, or
    gl_FragData[n], but not both.

    12) Should gl_FragData[n] be clamped?

    RESOLUTION: gl_FragData[] is basically an array of colors. The values in
    this array might or might not be actual color data, just as is true for
    the output variable gl_FragColor. The data assigned to gl_FragData[n]
    will be clamped to [0,1]. This restriction can be lifted by a separate
    extension, for example by the proposed color_clamp_control extension.

    13) What texture operations are not affected by a fragment shader
        performing a texture lookup?

    RESOLUTION: Whether or not a fragment shader is active, the following
    operations still behave as specified:

      * texture image specification (pp. 119-128)
      * alternate texture image specification (pp. 128-132)
      * compressed texture image specification (pp. 132-135)
      * texture parameters behave as specified even when a texture is
        accessed from within a fragment shader (pp. 135-147)
      * texture state and proxy state (pp. 148-149)
      * texture object specification (pp. 149-152)
      * texture comparison modes (p. 157)

    14) What is the interaction with a possible MRT (Multiple Render Target)
        extension?

    The OpenGL Shading Language defines the array gl_FragData[] to output
    values to multiple buffers. There are two situations to consider.

      1) There is no MRT extension support. A shader can statically assign a
         value to either gl_FragColor or gl_FragData[0] (but not both).
         Either way the same buffer will be targeted.
      2) There is MRT support. In this case what happens is defined in the
         relevant MRT extension documentation.

New Procedures and Functions

    None

New Tokens

    Accepted by the <shaderType> argument of CreateShaderObjectARB and
    returned by the <params> parameter of GetObjectParameter{fi}vARB:

        FRAGMENT_SHADER_ARB                             0x8B30

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

        MAX_FRAGMENT_UNIFORM_COMPONENTS_ARB             0x8B49
        MAX_TEXTURE_COORDS_ARB                          0x8871
        MAX_TEXTURE_IMAGE_UNITS_ARB                     0x8872

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

        FRAGMENT_SHADER_DERIVATIVE_HINT_ARB             0x8B8B

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

    Modify Section 2.1.1, Floating-Point Computation (p. 6)

    (modify first paragraph, p. 6) ... are accurate to about 1 part in 10^5.
    The maximum representable magnitude of a floating-point number used to
    represent positional, normal or texture coordinates must be at least
    2^32. The maximum representable magnitude for colors must be at least
    2^10. The maximum representable magnitude for all other floating-point
    values must be at least 2^32.

    Modify Section 2.7, Vertex Specification (p. 19)

    (modify second paragraph, p. 20) Implementations support more than one
    set of texture coordinates. The commands

        void MultiTexCoord{1234}{sifd}(enum texture, T coords)
        void MultiTexCoord{1234}{sifd}v(enum texture, T coords)

    take the coordinate set to be modified as the <texture> parameter.
    <texture> is a symbolic constant of the form TEXTUREi, indicating that
    texture coordinate set i is to be modified. The constants obey TEXTUREi
    = TEXTURE0 + i (i is in the range 0 to k-1, where k is the
    implementation-dependent number of texture units defined by
    MAX_TEXTURE_COORDS_ARB).

    Modify Section 2.8, Vertex Arrays (p. 23)

    (modify first paragraph, p. 23) ... The client may specify up to 7 plus
    the value of MAX_TEXTURE_COORDS_ARB arrays: one each to store vertex
    coordinates...

    (modify first paragraph, p. 25) The command

        void ClientActiveTexture(enum texture)

    is used to select the vertex array client state parameters to be
    modified by the TexCoordPointer command and the array affected by
    EnableClientState and DisableClientState with parameter
    TEXTURE_COORD_ARRAY. This command sets the client state variable
    CLIENT_ACTIVE_TEXTURE. Each texture coordinate set has a client state
    vector which is selected when this command is invoked. This state vector
    includes the vertex array state. This call also selects the texture
    coordinate set state used for queries of client state.


    (modify first paragraph, p. 30) If the number of supported texture
    coordinate sets (the value of MAX_TEXTURE_COORDS_ARB) is k, ...

    Modify Section 2.10.2, Matrices (p. 33)

    (modify first paragraph, p. 37) For each texture coordinate set, a 4x4
    matrix is applied to the corresponding texture coordinates. This matrix
    is applied as...

    (modify third and fourth paragraphs, p. 37) The command

        void ActiveTexture(enum texture)

    specifies the active texture unit selector, ACTIVE_TEXTURE. Each texture
    unit contains up to two distinct sub-units: a texture coordinate
    processing unit (consisting of a texture matrix stack and texture
    coordinate generation state) and a texture image unit (consisting of all
    the texture state defined in Section 3.8). In implementations with a
    different number of supported texture coordinate sets and texture image
    units, some texture units may consist of only one of the two sub-units.

    The active texture unit selector specifies the texture coordinate set
    accessed by commands involving texture coordinate processing. Such
    commands include those accessing the current matrix stack (if
    MATRIX_MODE is TEXTURE), TexGen (section 2.10.4), Enable/Disable (if any
    texture coordinate generation enum is selected), as well as queries of
    the current texture coordinates and current raster texture coordinates.
    If the texture coordinate set number corresponding to the current value
    of ACTIVE_TEXTURE is greater than or equal to the
    implementation-dependent constant MAX_TEXTURE_COORDS_ARB, the error
    INVALID_OPERATION is generated by any such command.

    The active texture unit selector also selects the texture image unit
    accessed by commands involving texture image processing (section 3.8).
    Such commands include all variants of TexEnv, TexParameter, and TexImage
    commands, BindTexture, Enable/Disable for any texture target (e.g.,
    TEXTURE_2D), and queries of all such state. If the texture image unit
    number corresponding to the current value of ACTIVE_TEXTURE is greater
    than or equal to the implementation-dependent constant
    MAX_TEXTURE_IMAGE_UNITS_ARB, the error INVALID_OPERATION is generated by
    any such command.

    ActiveTexture generates the error INVALID_ENUM if an invalid <texture>
    is specified. <texture> is a symbolic constant of the form TEXTUREi,
    indicating that texture unit i is to be modified. The constants obey
    TEXTUREi = TEXTURE0 + i (i is in the range 0 to k-1, where k is the
    larger of the MAX_TEXTURE_COORDS_ARB and MAX_TEXTURE_IMAGE_UNITS_ARB).

    For compatibility with old OpenGL specifications, the
    implementation-dependent constant MAX_TEXTURE_UNITS specifies the number
    of conventional texture units supported by the implementation. Its value
    must be no larger than the minimum of MAX_TEXTURE_COORDS_ARB and
    MAX_TEXTURE_IMAGE_UNITS_ARB.

    (modify third paragraph, p. 38) The state required to implement
    transformations consists of a 4-valued integer indicating the current
    matrix mode, one stack of at least two 4x4 matrices for each of COLOR,
    PROJECTION, each texture coordinate set, and TEXTURE and a stack of at
    least 32 4x4 matrices for MODELVIEW. Each matrix stack has an associated
    stack pointer. Initially, there is only one matrix on each stack, and
    all matrices are set to the identity. The initial matrix mode is
    MODELVIEW. The initial value of ACTIVE_TEXTURE is TEXTURE0.

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

    (Modify first paragraph, p. 61)... Figure 3.1 diagrams the rasterization
    process. The color value assigned to a fragment is initially determined
    by the rasterization operations (sections 3.3 through 3.7) and modified
    by either the execution of the texturing, color sum, and fog operations
    as defined in sections 3.8, 3.9, and 3.10, or of a fragment shader
    defined in section 3.11. The final depth value is initially determined
    by the rasterization operations and may be modified or replaced by a
    fragment shader. The results from rasterizing a point, line, polygon,
    pixel rectangle or bitmap can be routed through a fragment shader.

    (modify Figure 3.1)


                     _ +---------------+      switch depending on a
                     /||    Point      |\     fragment shader being active
                    /  | Rasterization | \              o-------------+
                   /   +---------------+ -++-++--->o                  |
           From   /    +---------------+ / | ||         o             |
        Primitive ---> |     Line      |/  | ||         |             |
         Assembly \    | Rasterization |  /  ||         |             |
                   \   +---------------+ /   ||         |             |
                    \  +---------------+/    ||   +-----+-----+  +----+-----+
                     \||    Polygon    |     ||   | Texturing |  | Fragment |
                     - | Rasterization |    / |   +-----+-----+  | Shader   |
                       +---------------+   /  |         |        +----+-----+
                       +---------------+  /   |   +-----+-----+       |
                       |     Pixel     | /    |   | Color Sum |       |
        DrawPixels --> |   Rectangle   |/    /    +-----+-----+       |
                       | Rasterization |    /           |             V
                       +---------------+   /      +-----+-----+
                       +---------------+  /       |    Fog    |---> Fragments
          Bitmap ----> |    Bitmap     | /        +-----------+
                       | Rasterization |/
                       +---------------+

    Modify Section 3.3.1, Basic Point Rasterization (p. 67)

    (modify last paragraph, p. 67) All fragments produced in rasterizing a
    non-antialiased point are assigned the same associated data, which are
    those of the vertex corresponding to the point. If a fragment shader is
    active (see section 3.11) the texture coordinates s, t, r, and q are
    passed on directly. Otherwise, the texture coordinates s, t, and r are
    replaced by s/q, t/q, and r/q, respectively, and if q is less than or
    equal to zero, the results are undefined.

    (modify second paragraph p. 68) If antialiasing is enabled, then point
    rasterization produces a fragment for each fragment square that
    intersects the region lying within the circle having diameter equal to
    the current point width and centered at the point's (Xw, Yw) (figure
    3.3). The coverage value for each fragment in the window coordinate area
    of the intersection of the circular region with the corresponding
    fragment square (but see section 3.2). This value is saved and used in
    the final step of rasterization (section 3.12). The data associated with
    each fragment are otherwise the data associated with the point being
    rasterized, with the exception of the texture coordinates. If a fragment
    shader is active, texture coordinates s, t, r, and q are passed on
    directly. Otherwise, the texture coordinates s, t, and r are replaced by
    s/q, t/q, and r/q, respectively, and if q is less than or equal to zero,
    the results are undefined.

    Modify Section 3.4.1, Basic Line Segment Rasterization (p. 71)

    (modify last paragraph, p. 72) ... or the s, t, r, or q texture
    coordinate or the clip w coordinate (the depth value, window z, must be
    found using equation 3.5, below), is found as

       (Equation 3.4)

    where fa and fb are the data associated with the starting and ending
    endpoints of the segment, respectively; wa and wb are the clip w
    coordinates of the starting and ending endpoints of the segments,
    respectively. When there is no fragment shader active (see section
    3.11), alpha a = alpha b = 1 for all data except texture coordinates, in
    which case alpha a = qa and alpha b = qb (qa and qb are the homogeneous
    texture coordinates at the starting and ending endpoints of the segment;
    results are undefined if either of these is less than or equal to 0).
    When a fragment shader is active, alpha a = alpha b = 1 for all
    components (i.e., q is interpolated along with s, t, and r). Note that
    linear interpolation would use ...

    ... A GL implementation may choose to approximate equation 3.4 with 3.5,
    but this will normally lead to unacceptable distortion effects when
    interpolating texture coordinates or clip w coordinates.

    Modify Section 3.5.1, Basic Polygon Rasterization (p. 77)

    (modify fourth paragraph, p. 78) ... When no fragment shader is active
    (section 3.11), alpha a = alpha b = alpha c = 1 except for texture s, t,
    and r coordinates, for which alpha a = qa, alpha b = qb, and alpha c =
    qc (if any of qa, qb, or qc are less than or equal to zero, results are
    undefined). When a fragment shader is active, alpha a = alpha b = alpha
    c = 1 for all components (i.e., q is interpolated along with s, t, and
    r). ...

    (modify first paragraph p. 79) this may yield acceptable results for
    color values (it must be used for depth values), but will normally lead
    to unacceptable distortion effects if used for texture coordinates or
    clip w coordinates.

    Modify Section 3.6.4, Rasterization of Pixel Rectangles (p. 95)

    (modify third paragraph, p. 106) A fragment arising from a group
    consisting of color data ...,and texture coordinates are taken from the
    current raster position's associated texture coordinates. If a fragment
    shader is active (see section 3.11) the texture coordinates s, t, r, and
    q are passed on directly. Otherwise, the texture coordinates s, t, and r
    are replaced by s/q, t/q, and r/q, respectively, and if q is less than
    or equal to zero, the results are undefined. Groups arising from
    DrawPixels ...

    Modify Section 3.7, Bitmaps (p. 116)

    (modify first paragraph, p. 118) ...The associated data for each
    fragment are those associated with the current raster position. If a
    fragment shader is active (see section 3.11) the texture coordinates s,
    t, r, and q are passed on directly. Otherwise, the texture coordinates
    s, t, and r are replaced by s/q, t/q, and r/q, respectively, and if q is
    less than or equal to zero, the results are undefined. Once the
    fragments have been produced,...

    Modify Section 3.8, Texturing (p. 118)

    (change the first full paragraph on p. 119) The GL provides two ways to
    specify the details of how texturing of a primitive is effected. The
    first is referred to as fixed functionality, and is described in this
    section. The second is referred to as a fragment shader, and is
    described in section 3.11. The specification of the image to be texture
    mapped and the means by which the image is filtered when applied to the
    primitive are common to both methods and are discussed in this section.
    The fixed functionality method for determining what RGBA value is
    produced is also described in this section. If a fragment shader is
    active, the method for determining the RGBA value is specified by an
    application-supplied fragment shader as described in the OpenGL Shading
    Language Specification.

    Modify Section 3.8.8, Texture Minification (p. 140)

    (change the first paragraph of the "Scale Factor and Level of Detail"
    section)

    The choice is governed by a scale factor rho(x,y) and the level of
    detail parameter lambda(x,y), defined as

    lambda_base(x,y) = log2[rho(x,y)]                                  3.16a

    lambda'(x,y) = lambda_base(x,y) +                                  3.16b
                   clamp(texobj_bias + texunit_bias + fragshader_bias)

                  |------- lod_max    lambda' > lod_max
    lambda(x,y) = |        lambda'    lod_min <= lambda' <= lod_max    3.16c
                  |        lod_min    lambda' < lod_min
                  |------- undefined  lod_min > lod_max

    texobj_bias is the value of TEXTURE_LOD_BIAS for the bound texture
    object (as described in section 3.8.4), and texunit_bias is the value of
    TEXTURE_LOD_BIAS for the current texture unit (as described in section
    3.8.13). fragshader_bias is the value of the optional bias parameter in
    the texture lookup functions available to a fragment shader. If a
    fragment shader is active, but the bias parameter is not provided, or if
    no fragment shader is active, then fragshader_bias is zero. The sum of
    these values is clamped to the range [-max_bias, max_bias] where
    max_bias is the value of the implementation defined constant
    MAX_TEXTURE_LOD_BIAS.

    Modify Section 3.8.15, Texture Application (p. 158)

    (modify fifth paragraph, p. 158) Texturing is enabled and disabled
    individually for each texture unit. If texturing is disabled for one of
    the units, then the fragment resulting from the previous unit is passed
    unaltered to the following unit. Individual texture units beyond those
    specified by MAX_TEXTURE_UNITS are always treated as disabled.

    Modify Section 3.9, Color Sum (p. 160)

    (add a new sentence before first paragraph, p. 160) If no fragment
    shader is active (see Section 3.11), a color sum operation is performed
    involving the primary and secondary colors.

    (change the last sentence of the section, p. 160) Color sum has no
    effect in color index mode or if a fragment shader is active.

    Modify Section 3.10, Fog (p. 160)

    (Change the first sentence, p. 160) If no fragment shader is active (see
    Section 3.11) and fog is enabled, an operation is performed that blends
    a fog color with a rasterized fragment's ....

    Modify Section 3.11, Antialiasing Application

    Rename this section to Section 3.12.

    Add Section 3.11, Fragment Shaders

    The sequence of operations that are applied to fragments that result
    from rasterizing a point, line segment, polygon, pixel rectangle or
    bitmap as described in Sections 3.8 through 3.10 is a
    fixed-functionality method for processing such fragments. Applications
    can more generally describe the operations that occur on such fragments
    by using a "fragment shader".

    A fragment shader is an array of strings containing source code for the
    operations that are meant to occur on each fragment that results from
    rasterizing a point, line segment, polygon, pixel rectangle or bitmap.
    The language used for fragment shaders is described in the OpenGL
    Shading Language Specification.

    A fragment shader only applies when the GL is in RGBA mode. Its
    operation in color index mode is undefined.

    Section 3.11.1 Creating and Using a Fragment Shader

    In order to create a fragment shader, call CreateShaderObjectARB with a
    <shaderType> of FRAGMENT_SHADER_ARB. The source code for the fragment
    shader can be specified using the ShaderSourceARB command. A fragment
    shader is compiled by calling CompileShaderARB and attached to a program
    object by calling AttachObjectARB. When LinkProgramARB is issued, all of
    the attached shader objects of type FRAGMENT_SHADER_ARB are linked
    together to create an executable program that can be used to process
    fragments that arise from rasterizing points, line segments, polygons,
    pixel rectangles or bitmpas. This executable program will become part of
    current state when UseProgramObjectARB is issued.

    CreateShaderObjectARB will set the object specific parameter
    OBJECT_SUBTYPE_ARB to FRAGMENT_SHADER_ARB.

    Section 3.11.2 Uniform Variables

    A fragment shader may define one or more "uniform" variables. These
    values are expected to remain constant over a primitive or a sequence of
    primitives. The OpenGL Shading Language Specification defines a set of
    built-in uniform variables for fragment shaders that correspond to the
    state that GL manages for the purpose of processing fragments that are
    generated by the rasterization of points, line segments, and polygons.
    The amount of storage that is available for fragment shader uniform
    variables is specified by the implementation dependent constant
    MAX_FRAGMENT_UNIFORM_COMPONENTS_ARB. This value represents the number of
    individual floating point values, or individual integer values, or
    individual Boolean values that can be held in uniform variable storage
    for a fragment shader. A link error will be generated if an attempt is
    made to utilize more than the space available for fragment shader
    uniform variables.

    Section 3.11.3 Varying Variables

    A fragment shader consumes the data produced as a result of the
    rasterization of points, line segments, polygons, pixel rectangles or
    bitmaps. If no vertex shader is active, the data that is available to
    the fragment shader at each fragment consists of the same types of data
    that are normally associated with a fragment for fixed functionality
    fragment processing, namely, the fragment's coordinate, color, secondary
    color, texture coordinates, fog coordinate, and eyeZ. The OpenGL Shading
    Language Specification defines a set of built-in varying variables that
    can be used to access these values within a fragment shader.

    When a vertex shader is active, it may define one or more "varying"
    variables (see Section 2.15.4 and the OpenGL Shading Language
    Specification). These values are expected to be interpolated across the
    primitive being rendered. The results of these interpolations are
    available within a fragment shader through varying variables that are
    defined as varying variables in the fragment shader with the same names
    as those defined in the vertex shader.

    Section 3.11.4 Fragment Shader Execution Environment

    If a fragment shader is active, the executable version of the fragment
    shader is used to process incoming fragment values that are the result
    of point, line segment, polygon, pixel rectangle or bitmap rasterization
    rather than the fixed functionality fragment processing described in
    Sections 3.8-3.10. In particular,

      * the texture environments and texture functions described in Section
        3.8.13 are not applied (pp. 152-157)
      * texture application as described in Section 3.8.15 is not applied.
        (pp. 158- 160)
      * color sum as described in Section 3.9 is not applied (p. 160)
      * fog as described in Section 3.10 is not applied (p. 160-162)

    When a texture lookup is performed in a fragment shader, the GL computes
    the filtered texture value ? in the manner described in sections 3.8.8
    and 3.8.9, and converts it to a texture source color C_s according to
    table 3.21 (section 3.8.13). The GL returns a four-component vector
    (R_s, G_s, B_s, A_s) to the fragment shader. For the purposes of
    level-of-detail calculations, the derivates du/dx, du/dy, dv/dx, dv/dy,
    dw/dx and dw/dy may be approximated by a differencing algorithm as
    detailed in section 8.8 of the OpenGL Shading Language specification.

    Texture comparison requires the fragment shader to use the shadow
    versions of the texture lookup functions. This in turn means that
    samplers of type sampler1DShadow or sampler2DShadow or
    sampler2DRectShadow need to be used to indicate the texture image unit
    that has a depth texture bound to it.

    The results of a texture lookup function are undefined if:

      * The sampler used in a texture lookup function is of type sampler1D
        or sampler2D or sampler2DRect, 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 of type
        sampler1DShadow or sampler2DShadow or sampler2DRectShadow, 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 of type
        sampler1DShadow or sampler2DShadow or sampler2DRectShadow, and the
        texture object's internal format is not DEPTH_COMPONENT_ARB.

    If a fragment shader uses a sampler which associated texture object is
    not complete, as defined in section 3.8.10, the texture image unit will
    return (R, G, B, A) = (0, 0, 0, 1).

    The number of separate texture units that can be accessed from within a
    fragment shader during the rendering of a single primitive is specified
    by the implementation- dependent constant MAX_TEXTURE_IMAGE_UNITS_ARB.

    A fragment shader has access to the read-only built-in variable
    gl_FrontFacing whose value is true if the fragment belongs to a
    front-facing primitive. A fragment derives its facing direction from the
    primitive that generates the fragment. All fragments generated by
    primitives other than polygons, triangles, or quadrilaterals are
    considered to be front facing. For all other fragments (including ones
    resulting from point- and line-mode polygons) the determination is made
    by examining the sign of the area computed by equation 2.6 of section
    2.13.1 (including the possible reversal of this sign as indicated by the
    last call to FrontFace). If the sign is positive then the fragments are
    front facing; otherwise, they are back facing.

    When processing fragments resulting from the rasterization of a pixel
    rectangle or bitmap, results are undefined if the fragment shader uses a
    varying variable that is not a built-in varying variable (see Section
    7.6 of the Shading Language Specification for a list).

    Section 3.11.5 Fragment Shader Input

    The OpenGL Shading Language specification describes the values that are
    available as inputs to the fragment shader. This section is concerned
    with the built-in variables gl_FragCood, gl_Color and gl_SecondaryColor.

    The built-in gl_FragCoord holds the window relative coordinates x, y, z,
    and 1/w for the fragment. The "z" component of gl_FragCoord undergoes an
    implied conversion to floating point. This conversion must leave the
    values 0 and 1 invariant. Note that this "z" component already has a
    polygon offset added in, if enabled. The 1/w value is computed from the
    Wc coordinate (see Section 2.10), which is the result of the product of
    the projection matrix and the vertex's eye coordinates.

    The built-in variables gl_Color and gl_SecondaryColor hold the "r", "g",
    "b", and "a" components, respectively, of the fragment color and
    secondary color. Each fixed-point color component undergoes an implied
    conversion to floating point. This conversion must leave the values 0
    and 1 invariant.

    Section 3.11.6 Fragment Shader Output

    The OpenGL Shading Language specification describes the values that may
    be output by a fragment shader. These are gl_FragColor, gl_FragData[n],
    and gl_FragDepth. The final fragment color values or the final fragment
    data values written by a fragment shader are clamped to the range [0,1]
    and then converted to fixed-point as described in section 2.13.9, Final
    Color Processing. The final fragment depth written by a fragment shader
    is first clamped to [0,1] and then converted to fixed-point as if it
    were a window z value. See Section 2.10.1, Controlling the Viewport.
    Note that the depth range computation is NOT applied here, only the
    conversion to fixed-point.

    The OpenGL Shading Language specification defines what happens when
    color, fragment data and/or depth are not written. Those rules are
    repeated here.

    Writing to gl_FragColor specifies the fragment color that will be used
    by the subsequent fixed functionality pipeline. If subsequent fixed
    functionality consumes fragment color and an execution of a fragment
    shader does not write a value to gl_FragColor then the fragment color
    consumed is undefined.

    The variable gl_FragData is an array. Writing to gl_FragData[n]
    specifies the fragment data that will be used by the subsequent fixed
    functionality pipeline for data n. If subsequent fixed functionality
    consumes fragment data and an execution of a fragment shader does not
    write a value to it, then the fragment data consumed is undefined.

    If a shader statically assigns a value to gl_FragColor, it may not
    assign a value to any element of gl_FragData. If a shader statically
    writes a value to any element of gl_FragData, it may not assign a value
    to gl_FragColor. That is, a shader may assign values to either
    gl_FragColor or gl_FragData, but not both..

    Writing to gl_FragDepth will establish the depth value for the fragment
    being processed. If depth buffering is enabled, and a shader does not
    write gl_FragDepth, then the fixed function value for depth will be used
    as the fragment's depth value. If a shader statically assigns a value to
    gl_FragDepth, and there is an execution path through the shader that
    does not set gl_FragDepth, then the value of the fragment's depth may be
    undefined for some executions of the shader. That is, if a shader
    statically contains a write to gl_FragDepth, then it is responsible for
    always writing it.

    Note, a shader contains a static assignment to a variable x if, after
    pre-processing, the shader contains a statement that would write to x,
    whether or not run-time flow of control will cause that statement to be
    executed.

    Section 3.11.7 Required State

    Besides the required state outlined in the ARB_shader_objects extension
    document, the following state per program object is also required:

      * An array of MAX_FRAGMENT_UNIFORM_COMPONENTS_ARB words that holds
        uniform values.

    Modify Section 3.12, Multisample Point Fade

    Rename this section to Section 3.13.


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

    None

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

    Modify Section 5.6, Hints (p. 203)

    (add to the paragraph describing the hints)... the desired quality and
    performance of compressing texture images;
    FRAGMENT_SHADER_DERIVATIVE_HINT_ARB, indicating the desired derivative
    accuracy for the fragment processing built-in functions dFdx, dFdy and
    fwidth. Hint must be one of FASTEST, ...

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

    Modify Section 6.1.2, Data Conversions (p. 205)

    (add to end of last paragraph, p. 206) Queries of texture state
    variables corresponding to a texture coordinate processing unit (namely,
    TexGen state and enables, and matrices) will produce an
    INVALID_OPERATION error if the value of ACTIVE_TEXTURE is greater than
    or equal to MAX_TEXTURE_COORDS_ARB. All other texture state queries will
    result in an INVALID_OPERATION error if the value of ACTIVE_TEXTURE is
    greater than or equal to MAX_TEXTURE_IMAGE_UNITS_ARB.

    Modify section 6.1.12 Object Queries.

    The commands

        void GetObjectParameter{if}vARB(handleARB obj, enum pname, T params)

    return object specific parameter values for object <obj> in <params>.
    The parameter value to return is specified by <pname>.

    If <pname> is OBJECT_TYPE_ARB, GetObjectParameter{if}vARB returns
    PROGRAM_OBJECT_ARB if <obj> references a program object. It returns
    SHADER_OBJECT_ARB if <obj> references any shader object. If <obj> is not
    of type PROGRAM_OBJECT_ARB or SHADER_OBJECT_ARB, the error
    INVALID_OPERATION is generated.

    If <pname> is OBJECT_SUBTYPE_ARB, GetObjectParameter{if}vARB returns
    FRAGMENT_SHADER_ARB if <obj> references a shader object. If <obj> is not
    of type SHADER_OBJECT_ARB, the error INVALID_OPERATION is generated.


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

    Add to end of Section A.3 (p. 250):

    The same fragment shader will produce the same result when run multiple
    times with the same input. The wording 'the same shader' means a program
    object that is populated with the same source strings, which are
    compiled and then linked, possibly multiple times. This program object
    is then executed using the same GL state vector.

    All fragment shaders that either conditionally or unconditionally assign
    gl_FragCoord.z to gl_FragDepth are depth-invariant with respect to each
    other, for those fragments where the assignment to gl_FragDepth actually
    is done.

Additions to the AGL/GLX/WGL Specifications

    None

Interactions with ARB_vertex_program and ARB_fragment_program

    Mixing a high level ARB_fragment_shader shader with a low level
    ARB_vertex_program shader is allowed. However, a high level
    ARB_fragment_shader shader and a low level ARB_fragment_program shader
    cannot be active at the same time.

Interactions with ARB_fragment_program

    Enabling an ARB_fragment_shader shader by issuing the command
    UseProgramObjectARB(), with a handle which is not zero, results in any
    low level fragment shader to be ignored and overrides the enable
    FRAGMENT_PROGRAM_ARB. Note that the value for FRAGMENT_PROGRAM_ARB does
    not change by installing an ARB_fragment_shader shader.

    The following enumerants are borrowed from ARB_fragment_program. Their
    usage and meaning has stayed the same:

        MAX_TEXTURE_COORDS_ARB                          0x8871
        MAX_TEXTURE_IMAGE_UNITS_ARB                     0x8872

Interactions with ARB_vertex_shader

    If ARB_vertex_shader is present, then this extension does not also
    define the new token SHADER_OBJECT_ARB.

    If ARB_vertex_shader is not present, the wording of Section 3.11.3
    Varying Variables needs to be modified to omit references to the vertex
    shader.

Errors

    The error INVALID_OPERATION is generated by any command accessing
    texture coordinate processing state if the texture unit number
    corresponding to the current value of ACTIVE_TEXTURE is greater than or
    equal to the implementation-dependent constant MAX_TEXTURE_COORDS_ARB.

    The error INVALID_OPERATION is generated by any command accessing
    texture image processing state if the texture unit number corresponding
    to the current value of ACTIVE_TEXTURE is greater than or equal to the
    implementation-dependent constant MAX_TEXTURE_IMAGE_UNITS_ARB.

    The error INVALID_VALUE is generated by any command that takes one or
    more handles as input, and one or more of these handles are not an
    object handle generated by OpenGL.

    The error INVALID_OPERATION is generated by GetObjectParameter{if}vARB
    if <pname> is OBJECT_TYPE_ARB and <obj> is not of type
    PROGRAM_OBJECT_ARB or SHADER_OBJECT_ARB.

    The error INVALID_OPERATION is generated by GetObjectParameter{if}vARB
    if <pname> is OBJECT_SUBTYPE_ARB and <obj> is not of type
    SHADER_OBJECT_ARB.

New State
                                                                 Initial
    Get Value              Type       Get Command                Value        Description          Sec.   Attribute
    ---------              -----      -----------------------  -------------  -----------          ----   ---------
    OBJECT_TYPE_ARB        Z2         GetObjectParameterivARB   SHADER_OBJECT  Type of object      3.11.1        -
    OBJECT_SUBTYPE_ARB     Z2         GetObjectParameterivARB  FRAGMENT_SHADER Sub type of object  3.11.1        -

    Table X Shader object state.

    (Add the following hint to Table 6.26, p. 241.)

                                                                 Initial
    Get Value              Type       Get Command                Value        Description          Sec.   Attribute
    ---------              -----      -----------------------  -------------  -----------          ----   ---------
    FRAGMENT_SHADER_DERIVATIVE_HINT                                            fragment shader
                           Z3         GetIntegerv               DONT_CARE      derivative accuracy  5.6    hint
                                                                               hint

New Implementation Dependent State
                                                                      Minimum
    Get Value                           Type  Get Command   Value   Description            Sec.  Attr.
    ---------                           ----  -----------  -------  -----------            ----  -----
    MAX_FRAGMENT_UNIFORM_COMPONENTS_ARB Z+   GetIntegerv     64     Number of words        3.11.2   -
                                                                    for fragment shader
                                                                    uniform variables
    MAX_TEXTURE_IMAGE_UNITS_ARB         Z+   GetIntegerv     2      Number of separate     3.11.4   -
                                                                    texture image units
    MAX_TEXTURE_COORDS_ARB              Z+    GetIntegerv    2      number of texture      2.7      -
                                                                    coordinate sets

Sample Usage

    The code below is taken from the sample section in ARB_vertex_shader and
    expanded to include a fragment shader.

    GLboolean init(GLcharARB *vertexShader, GLcharARB *fragmentShader)
    {
        const GLcharARB    *pInfoLog;
        GLboolean compiled = GL_FALSE;
        GLboolean linked   = GL_FALSE;
        GLint     length;

        //
        // Create shader and program objects.
        //
        ProgramObject      = glCreateProgramObjectARB();
        VertexShaderObject = glCreateShaderObjectARB(GL_VERTEX_SHADER_ARB);
        FragmentShaderObject = glCreateShaderObjectARB(GL_FRAGMENT_SHADER_ARB);


        length = strlen(vertexShader);
        glShaderSourceARB(VertexShaderObject, 1, &vertexShader, &length);
        glShaderSourceARB(FragmentShaderObject, 1, &fragmentShader, NULL);

        //
        // OpenGL made a copy of the shaders, we can free our copy
        //
        free(vertexShader);
        free(fragmentShader);

        //
        // Compile the vertex and fragment shader, and print out the
        // compiler log file.
        //
        glCompileShaderARB(VertexShaderObject);
        glGetObjectParameterivARB(VertexShaderObject,
                                  GL_OBJECT_COMPILE_STATUS_ARB, &compiled);

        glGetObjectParameterivARB(VertexShaderObject,
                                 GL_OBJECT_INFO_LOG_LENGTH_ARB, &maxLength);
        pInfoLog = (GLcharARB *) malloc(maxLength * sizeof(GLcharARB));
        glGetInfoLogARB(VertexShaderObject, maxLength, &length, pInfoLog);
        printf("%s", pInfoLog);
        free(pInfoLog);

        if (!compiled) {
            printf("Compile failed\n");
            return GL_FALSE;
        }

        glCompileShaderARB(FragmentShaderObject);
        glGetObjectParameterivARB(FragmentShaderObject,
                                  GL_OBJECT_COMPILE_STATUS_ARB, &compiled);

        glGetObjectParameterivARB(FragmentShaderObject,
                                 GL_OBJECT_INFO_LOG_LENGTH_ARB, &maxLength);
        pInfoLog = (GLcharARB *) malloc(maxLength * sizeof(GLcharARB));
        glGetInfoLogARB(FragmentShaderObject, maxLength, NULL, pInfoLog);
        printf("%s", pInfoLog);
        free(pInfoLog);

        if (!compiled) {
            printf("Compile failed\n");
            return GL_FALSE;
        }

        //
        // Populate the program object with the compiled shadera
        //
        glAttachObjectARB(ProgramObject, VertexShaderObject);
        glAttachObjectARB(ProgramObject, FragmentShaderObject);

        //
        // We want the shader objects to go away as soon as it is detached
        // from the program object it is attached to. We can simply call
        // delete now to achieve that. Note that calling delete on a program
        // object will result in all shaders attached to that program object
        // to be detached. If delete has been called for the shader objects,
        // calling delete on the program object will result in the shader
        // objects being deleted as well.
        //
        glDeleteObjectARB(VertexShaderObject);
        glDeleteObjectARB(FragmentShaderObject);

        //
        // Link the program object and print out the linker log file
        //
        glLinkProgramARB(ProgramObject);
        glGetObjectParameterivARB(ProgramObject,
                                  GL_OBJECT_LINK_STATUS_ARB, &linked);

        glGetObjectParameterivARB(ProgramObject,
                                 GL_OBJECT_INFO_LOG_LENGTH_ARB, &maxLength);
        pInfoLog = (GLcharARB *) malloc(maxLength * sizeof(GLcharARB));
        glGetInfoLogARB(ProgramObject, maxLength, NULL, pInfoLog);

        printf("%s\n", pInfoLog);
        free(pInfoLog);

        //
        // If all went well, make the program object part of the current state
        //
        if (linked) {
            glUseProgramObjectARB(ProgramObject);
            return GL_TRUE;
        } else {
            return GL_FALSE;
        }
    }

Revision History

    Revision 0.5, 6/6/2002
      - First draft for circulation
    Revision 0.51, 6/10/2002
      - Listed all varyings that a fragment shader can access
      - Clarified section 3.11.6
      - Added more to the 'Interaction with GL2_vertex_shader' section
    Revision 0.52, 6/12/2002
      - Now references V1.0 of the OpenGL Shading Language Specification
      - Fixed minor typos
      - Accepted by the GL2 working group
    Revision 0.52, 10/17/2002
      - Removed IsObjectGL2()
      - Expanded GetObjectParameter{if}GL2. Added OBJECT_SUBTYPE_GL2.
    Revision 0.53, 10/18/2002
      - Forgot to add _GL2 to the end of MAX_FP_TEXTURE_UNITS_GL2.
      - Added language disallowing mixing GL2 high level vertex shader with
        low level ARB vertex program or fragment program.
    Revision 0.54, 10/24/2002
      - Removed the resource limit section and move it to GL2_shader_objects
      - Clarified some sections across the document
      - Based on ARB_fragment_program split a texture unit into two sub
        units. This resulted in expanding Section 2 significantly.
      - Expanded section 6
      - Expanded Errors section
      - Added sample usage
    Revision 0.6, 10/29/2002
      - Now written against the OpenGL 1.4 specification.
      - Second distribution to the GL2 working group.
    Revision 0.61, 11/26/2002
      - Renamed MAX_FP_TEXTURE_UNITS to MAX_FRAGMENT_TEXTURE_UNITS.
      - Updated list of contributors.
      - Allowed mixing of a high level GL2 fragment shader with a low level
        ARB_vertex_program shader.
    Revision 0.62, 12/04/2002
      - Changed issue 3 wording to make the number of texture image units
        and coordinates units independent from each other.
      - Changed MAX_FRAGMENT_UNIFORM_FLOATS_GL2 to
        MAX_FRAGMENT_UNIFORM_WORDS_GL2. Also changed language in paragraph
        3.11.2 clarifying this new constant.
      - Added issue number 5.
    Revision 0.63, 02/13/2003
      - Consistently used 'texture coordinate set'
      - Changed 3.11.5, fragment shader output. Colors are clamped, and
        depths are clamped then converted to fixed point.
      - Added Section 3.11.4.1 Fragment Shader Texturing
    Revision 0.64, 02/21/2003
      - Modified section 2.10.1
      - Added color conversion to fixed-point to the values written to
        gl_FragColor. Section 3.11.5.
    Revision 0.65, 03/06/2003
      - Added a third LOD bias parameter to section 3.8.8 (comes from the
        texture lookup functions).
      - Added issues 6 and 7.
      - Added clip w coordinate interpolation for lines and polygons.
      - Upgraded colors and texture coordinates to be full floating point
        citizens, section 2.1.1.
      - Updated the interactions section.
      - Renamed MAX_FRAGMENT_TEXTURE_UNITS_GL2 to
        MAX_TEXTURE_IMAGE_UNITS_ARB
    Revision 0.66, 03/26/2003
      - Expanded issues 2 and 3.
      - Added modification to section 3.8.15.
      - Updated contributors list. Who else?
      - Updated IP Status section to point to the contributors agreement.
    Revision 0.67, 04/09/2003
      - Added required state section.
      - Renamed handle to handleGL2
    Revision 0.68, 05/08/2003
      - Changed MAX_FRAGMENT_UNIFORM_WORDS_GL2 to
        MAX_FRAGMENT_UNIFORM_COMPONENTS_GL2
      - Updated example section to reflect the latest API changes
      - Changed the location of the Contributors License to a publicly
        accessible place on www.3dlabs.com.
      - Re-worded the introduction.
      - Added OBJECT_TYPE_GL2 to the list of new tokens.
      - Moved issue 3 up to be issue 1.
      - Re-wrote section 3.8, introduction.
      - Added issue 8.
      - Added front/back facing language to section 3.11.4
      - Re-wrote issue 3.
      - Added language to appendix A. Invariance.
      - Added section 3.11.5 Fragment Shader Input
      - Added issue 9
      - Fixed section 3.11.4. Texture enables are ignored.
      - Added issue 10.
      - Added a note about polygon offset to section 3.11.5.
      - Reversed the resolution of issue 5. Changed chapter 3 to reflect
        this.
      - Updated sample code to reflect latest API names.
      - Updated errors section.
      - Numerous small fixes based on Pat's comments.
      - Depth values are converted to floating point before entering the
        fragment shader. Updated issue 7 to reflect this.
      - Fixed up the state tables.
      - Updated section 3.11.4. Clarified depth texture comparison mode when
        a fragment shader is active.
      - Added Jon Leech, Evan Hart, Benjamin Lipchak and Jeremy Sandmel to
        the list of contributors.
    Revision 0.69, 05/09/2003
      - Added to issue 5. In this case fragment shader should only reference
        built- in varying variables s (starting with "gl_"). Also added spec
        language to section 3.11.4.
      - Added one more paragraph to issue 4, invariance. If you do not write
        to gl_FragDepth you're depth invariant with fixed-function.
      - Explained 'statically assigned'
      - Assigned enum values.
      - Version approved by the ARB-GL2 working group.
    Revision 0.70, 05/14/2003
      - Section 3.8.15 clarified.
      - Issue 8 intended to explain what happens when
        VERTEX_PROGRAM_TWO_SIDE_ARB is false, not true. Fixed.
      - Clarified fragment front/back facing selection when in polygon point
        or line mode.
      - Fixed typos.
      - Renamed all GL2 occurrences to ARB.
      - Added SHADER_OBJECT_ARB to the list of new tokens.
      - Deleted reference to AppendShader (this call no longer exist).
    Revision 0.71, 06/30/2003
      - Removed section 2.13.9. It no longer applies.
      - The dynamic range of colors is left at 2^10, only texture
        coordinates are upgraded to 2^32 (Section 2.1.1).
      - Updated Sample Usage section.
      - Added fixed-point conversion rule for color and secondary color.
        Section 3.11.5.
      - General language cleanup.
      - Version approved as ARB extension
    Revision 0.72, 02/23/2004
      - Fixed the last part of section 3.4.1, basic line segment
        rasterization.
      - Removed SHADER_OBJECT_ARB, OBJECT_TYPE_ARB and OBJECT_SUBTYPE_ARB
        tokens from the New Tokens section. They are already defined in
        ARB_shader_objects. Also removed references to these in Chapter 6,
        GetObjectParameter{fi}v and the Errors section.
      - Added the official extension number (32). Edited the Status
        paragraph.
    Revision 0.73, 03/11/2004
      - Added language to specify when texture lookups are undefined when
        mixing shadow and non shadow samplers with texture objects with or
        without depth components and different texture compare modes set.
    Revision 0.74, 03/12/2004
      - Added sampler2DRect and sampler2DRectShadow to the previous changes.
    Revision 0.75, 03/16/2004
      - Fixed up the sampler language from version 0.74.
      - Updated section 3.11.6, Fragment Shader Output to incorporate the
        new gl_FragData[] output array. Added related issues 11 and 12.
    Revision 0.76, 03/19/2004
      - Added a hint DERIVATIVE_ACCURACY_HINT to section 5.6 and the New
        Tokens section.
    Revision 0.77, 03/31/2004
      - Added language to section 3.11.4 specifying that derivatives for LOD
        calculations may be approximated.
      - Moved spec language related to texture operations not affected by a
        fragment shader from section 3.11.4 to issue 13.
      - Added language to section 3.11.4, copied from the vertex shader, how
        the filtered texture value is computed. Also added language that the
        LOD could be computed using derivatives computed using a
        differencing algorithm.
      - Renamed DERIVATIVE_ACCURACY_HINT_ARB to
        FRAGMENT_SHADER_DERIVATIVE_HINT_ARB and added it to the state
        tables.
      - Updated issue 12. gl_FragData will be clamped to [0,1]
      - Added issue 14, explaining the interaction with MRT.
      - Updated the shading language version this spec references to version
        100.53.
      - Added clamping to [0,1] for output color and fragData back into
        section 3.11.6. Also updated the language in 3.11.6 to be the same
        as in the OpenGL Shading Language document.
      - Version voted on and approved by the workgroup.
    Revision 0.78, 04/06/2004
      - Minor language changes to issues 12 and 14.
      - Updated the Shading Language Version referenced to the now official
        version 1.10.
    Revision 0.79, 05/14/2004
      - Listed that FRAGMENT_SHADER_DERIVATIVE_HINT is also accepted by the
        Get* commands under the New Tokens section.
      - Updated issue 14. Punted most of it to the MRT extension document.
    Revision 0.80, 12/12/2006
      - Fixed spelling of glGetObjectParameterivARB in sample code.