xref: /third_party/openGLES/extensions/ARB/ARB_gpu_shader5.txt

Name

    ARB_gpu_shader5

Name Strings

    GL_ARB_gpu_shader5

Contact

    Pat Brown, NVIDIA Corporation (pbrown 'at' nvidia.com)

Contributors

    Barthold Lichtenbelt, NVIDIA
    Bill Licea-Kane, AMD
    Bruce Merry, ARM
    Chris Dodd, NVIDIA
    Eric Werness, NVIDIA
    Graham Sellers, AMD
    Greg Roth, NVIDIA
    Jeff Bolz, NVIDIA
    Nick Haemel, AMD
    Pierre Boudier, AMD
    Piers Daniell, NVIDIA

Notice

    Copyright (c) 2010-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

Status

    Complete. Approved by the ARB at the 2010/01/22 F2F meeting.
    Approved by the Khronos Board of Promoters on March 10, 2010.

Version

    Version 16, March 30, 2012

Number

    ARB Extension #88

Dependencies

    This extension is written against the OpenGL 3.2 (Compatibility Profile)
    Specification.

    This extension is written against Version 1.50 (Revision 09) of the OpenGL
    Shading Language Specification.

    OpenGL 3.2 and GLSL 1.50 are required.

    This extension interacts with ARB_gpu_shader_fp64.

    This extension interacts with NV_gpu_shader5.

    This extension interacts with ARB_sample_shading.

    This extension interacts with ARB_texture_gather.

Overview

    This extension provides a set of new features to the OpenGL Shading
    Language and related APIs to support capabilities of new GPUs, extending
    the capabilities of version 1.50 of the OpenGL Shading Language.  Shaders
    using the new functionality provided by this extension should enable this
    functionality via the construct

      #extension GL_ARB_gpu_shader5 : require     (or enable)

    This extension provides a variety of new features for all shader types,
    including:

      * support for indexing into arrays of samplers using non-constant
        indices, as long as the index doesn't diverge if multiple shader
        invocations are run in lockstep;

      * extending the uniform block capability of OpenGL 3.1 and 3.2 to allow
        shaders to index into an array of uniform blocks;

      * support for implicitly converting signed integer types to unsigned
        types, as well as more general implicit conversion and function
        overloading infrastructure to support new data types introduced by
        other extensions;

      * a "precise" qualifier allowing computations to be carried out exactly
        as specified in the shader source to avoid optimization-induced
        invariance issues (which might cause cracking in tessellation);

      * new built-in functions supporting:

        * fused floating-point multiply-add operations;

        * splitting a floating-point number into a significand and exponent
          (frexp), or building a floating-point number from a significand and
          exponent (ldexp);

        * integer bitfield manipulation, including functions to find the
          position of the most or least significant set bit, count the number
          of one bits, and bitfield insertion, extraction, and reversal;

        * packing and unpacking vectors of small fixed-point data types into a
          larger scalar; and

        * convert floating-point values to or from their integer bit
          encodings;

      * extending the textureGather() built-in functions provided by
        ARB_texture_gather:

        * allowing shaders to select any single component of a multi-component
          texture to produce the gathered 2x2 footprint;

        * allowing shaders to perform a per-sample depth comparison when
          gathering the 2x2 footprint using for shadow sampler types;

        * allowing shaders to use arbitrary offsets computed at run-time to
          select a 2x2 footprint to gather from; and

        * allowing shaders to use separate independent offsets for each of the
          four texels returned, instead of requiring a fixed 2x2 footprint.

    This extension also provides some new capabilities for individual
    shader types, including:

      * support for instanced geometry shaders, where a geometry shader may be
        run multiple times for each primitive, including a built-in
        gl_InvocationID to identify the invocation number;

      * support for emitting vertices in a geometry program where each vertex
        emitted may be directed independently at a specified vertex stream (as
        provided by ARB_transform_feedback3), and where each shader output is
        associated with a stream;

      * support for reading a mask of covered samples in a fragment shader;
        and

      * support for interpolating a fragment shader input at a programmable
        offset relative to the pixel center, a programmable sample number, or
        at the centroid.

IP Status

    No known IP claims.

New Procedures and Functions

    None

New Tokens

    Accepted by the <pname> parameter of GetProgramiv:

        GEOMETRY_SHADER_INVOCATIONS                     0x887F

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

        MAX_GEOMETRY_SHADER_INVOCATIONS                 0x8E5A
        MIN_FRAGMENT_INTERPOLATION_OFFSET               0x8E5B
        MAX_FRAGMENT_INTERPOLATION_OFFSET               0x8E5C
        FRAGMENT_INTERPOLATION_OFFSET_BITS              0x8E5D
        MAX_VERTEX_STREAMS                              0x8E71

    (note:  MAX_GEOMETRY_SHADER_INVOCATIONS,
     MIN_FRAGMENT_INTERPOLATION_OFFSET, MAX_FRAGMENT_INTERPOLATION_OFFSET, and
     FRAGMENT_INTERPOLATION_OFFSET_BITS have identical values to corresponding
     "NV" enums from NV_gpu_program5.  MAX_VERTEX_STREAMS is also defined in
     ARB_transform_feedback3.)


Additions to Chapter 2 of the OpenGL 3.2 (Compatibility Profile) Specification
(OpenGL Operation)

    Modify Section 2.15.4, Geometry Shader Execution Environment, p. 121

    (add two unnumbered subsections after "Texture Access", p. 122)

    Instanced Geometry Shaders

    For each input primitive received by the geometry shader pipeline stage,
    the geometry shader may be run once or multiple times.  The number of
    times a geometry shader should be executed for each input primitive may be
    specified using a layout qualifier in a geometry shader of a linked
    program.  If the invocation count is not specified in any layout
    qualifier, the invocation count will be one.

    Each separate geometry shader invocation is assigned a unique invocation
    number.  For a geometry shader with <N> invocations, each input primitive
    spawns <N> invocations, numbered 0 through <N>-1.  The built-in uniform
    gl_InvocationID may be used by a geometry shader invocation to determine
    its invocation number.

    When executing instanced geometry shaders, the output primitives generated
    from each input primitive are passed to subsequent pipeline stages using
    the shader invocation number to order the output.  The first primitives
    received by the subsequent pipeline stages are those emitted by the shader
    invocation numbered zero, followed by those from the shader invocation
    numbered one, and so forth.  Additionally, all output primitives generated
    from a given input primitive are passed to subsequent pipeline stages
    before any output primitives generated from subsequent input primitives.


    Geometry Shader Vertex Streams

    Geometry shaders may emit primitives to multiple independent vertex
    streams.  Each vertex emitted by the geometry shader is directed at one of
    the vertex streams.  As vertices are received on each stream, they are
    arranged into primitives of the type specified by the geometry shader
    output primitive type.  The shading language built-in functions
    EndPrimitive() and EndStreamPrimitive() may be used to end the primitive
    being assembled on a given vertex stream and start a new empty primitive
    of the same type.  If an implementation supports <N> vertex streams, the
    individual streams are numbered 0 through <N>-1.  There is no requirement
    on the order of the streams to which vertices are emitted, and the number
    of vertices emitted to each stream may be completely independent, subject
    only to implementation-dependent output limits.

    The primitives emitted to all vertex streams are passed to the transform
    feedback stage to be captured and written to buffer objects in the manner
    specified by the transform feedback state.  The primitives emitted to all
    streams but stream zero are discarded after transform feedback.
    Primitives emitted to stream zero are passed to subsequent pipeline stages
    for clipping, rasterization, and subsequent fragment processing.

    Geometry shaders that emit vertices to multiple vertex streams are
    currently limited to using only the "points" output primitive type.  A
    program will fail to link if it includes a geometry shader that calls the
    EmitStreamVertex() built-in function and has any other output primitive
    type parameter.


Additions to Chapter 3 of the OpenGL 3.2 (Compatibility Profile) Specification
(Rasterization)

    Modify Section 3.3.1, Multisampling, p. 148

    (add new paragraph at the end of the section, p. 149)

    If MULTISAMPLE is enabled and the current program object includes a
    fragment shader with one or more input variables qualified with "sample
    in", the data associated with those variables will be assigned
    independently.  The values for each sample must be evaluated at the
    location of the sample.  The data associated with any other variables not
    qualified with "sample in" need not be evaluated independently for each
    sample.


    Modify ARB_texture_gather, "Changes to Section 3.8.8"

    (extend language describing the operation of textureGather, allowing the
     new <comp> argument to select any of the four components from a
     multi-component texel vector)

    The textureGather and textureGatherOffset built-in shader functions...  A
    four-component vector is then assembled by taking a single component from
    the swizzled texture source colors of the four texels, in the order
    T_i0_j1, T_i1_j1, T_i1_j0, and T_i0_j0.  The selected component is
    identified by the optional <comp> argument, where the values zero, one,
    two, and three identify the Rs, Gs, Bs, or As component, respectively.  If
    <comp> is omitted, it is treated as identifying the Rs component.
    Incomplete textures (section 3.8.10) are considered to return a texture
    source color of (0,0,0,1) for all four source texels.

    (add further language describing textureGatherOffsets)

    The textureGatherOffsets built-in functions from the OpenGL Shading
    Language return a vector derived from sampling four texels in the image
    array of level <level_base>.  For each of the four texel offsets specified
    by the <offsets> argument, the rules for the LINEAR minification filter
    are applied to identify a 2x2 texel footprint, from which the single texel
    T_i0_j0 is selected.  A four-component vector is then assembled by taking
    a single component from each of the four T_i0_j0 texels in the same manner
    as for the textureGather function.


    Modify Section 3.12.1, Shader Variables, p. 273

    (insert prior to the last paragraph of the section, p. 274)

    When interpolating built-in and user-defined varying variables, the default
    screen-space location at which these variables are sampled is defined in
    previous rasterization sections.  The default location may be overriden by
    interpolation qualifiers.  When interpolating variables declared using
    "centroid in", the variable is sampled at a location within the pixel
    covered by the primitive generating the fragment.  When interpolating
    variables declared using "sample in" when MULTISAMPLE is enabled, the
    fragment shader will be invoked separately for each covered sample and the
    variable will be sampled at the corresponding sample point.

    Additionally, built-in fragment shader functions provide further
    fine-grained control over interpolation.  The built-in functions
    interpolateAtCentroid() and interpolateAtSample() will sample variables as
    though they were declared with the "centroid" or "sample" qualifiers,
    respectively.  The built-in function interpolateAtOffset() will sample
    variables at a specified (x,y) offset relative to the center of the pixel.
    The range and granularity of offsets supported by this function is
    implementation-dependent.  If either component of the specified offset is
    less than MIN_FRAGMENT_INTERPOLATION_OFFSET or greater than
    MAX_FRAGMENT_INTERPOLATION_OFFSET, the position used to interpolate the
    variable is undefined.  Not all values of <offset> may be supported; x and
    y offsets may be rounded to fixed-point values with the number of fraction
    bits given by the implementation-dependent constant
    FRAGMENT_INTERPOLATION_OFFSET_BITS.


    Modify Section 3.12.2, Shader Execution, p. 274

    (insert prior to the next-to-last paragraph in "Shader Inputs", p. 277)

    The built-in variable gl_SampleMaskIn[] is an integer array holding
    bitfields indicating the set of fragment samples covered by the primitive
    corresponding to the fragment shader invocation.  The number of elements
    in the array is ceil(<s>/32), where <s> is the maximum number of color
    samples supported by the implementation.  Bit <n> of element <w> in the
    array is set if and only if the sample numbered <w>*32+<n> is considered
    covered for this fragment shader invocation.  When rendering to a
    non-multisample buffer, or if multisample rasterization is disabled, all
    bits are zero except for bit zero of the first array element.  That bit
    will be one if the pixel is covered and zero otherwise.  Bits in the
    sample mask corresponding to covered samples that will be killed due to
    SAMPLE_COVERAGE or SAMPLE_MASK_NV will not be set (section 4.1.3).  When
    per-sample shading is active due to the use of a fragment input qualified
    by "sample", only the bit for the current sample is set in
    gl_SampleMaskIn.  When OpenGL API state specifies multiple fragment shader
    invocations for a given fragment, the sample mask for any single fragment
    shader invocation may specify a subset of the covered samples for the
    fragment.  In this case, the bit corresponding to each covered sample will
    be set in exactly one fragment shader invocation.


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

    None.

Additions to Chapter 5 of the OpenGL 3.2 (Compatibility Profile) Specification
(Special Functions)

    None.

Additions to Chapter 6 of the OpenGL 3.2 (Compatibility Profile) Specification
(State and State Requests)

    Modify Section 6.1.16, Shader and Program Queries, p. 384

    (add to long first paragraph, p. 386) ... If <pname> is
    GEOMETRY_SHADER_INVOCATIONS, the number of geometry shader invocations per
    primitive will be returned.  If GEOMETRY_VERTICES_OUT,
    GEOMETRY_INPUT_TYPE, GEOMETRY_OUTPUT_TYPE, or GEOMETRY_SHADER_INVOCATIONS
    are queried for a program which has not been linked successfully, or which
    does not contain objects to form a geometry shader, then an
    INVALID_OPERATION error is generated.


Additions to Appendix A of the OpenGL 3.2 (Compatibility Profile)
Specification (Invariance)

    None.

Additions to the AGL/GLX/WGL Specifications

    None.

Modifications to The OpenGL Shading Language Specification, Version 1.50
(Revision 09)

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

      #extension GL_ARB_gpu_shader5 : <behavior>

    where <behavior> is as specified in section 3.3.

    New preprocessor #defines are added to the OpenGL Shading Language:

      #define GL_ARB_gpu_shader5        1


    Modify Section 3.6, Keywords, p. 14

    (add to the keyword list)

      sample


    Modify Section 4.1.7, Samplers, p. 23

    (modify 1st paragraph of the section, deleting the restriction requiring
    constant indexing of sampler arrays but still requiring uniform indexing
    across invocations) ... Samplers may aggregated into arrays within a
    shader (using square brackets [ ]) and can be indexed with general integer
    expressions.  The results of accessing a sampler array with an
    out-of-bounds index are undefined. ...

    (add new paragraph restricting the use of general integer expression in
    sampler array indexing) When indexing an array of samplers, the integer
    expression used to index the array must be uniform across shader
    invocations.  If this restriction is not satisfied, the results of
    accessing the sampler array are undefined.  For the purposes of this
    uniformity test, the index used for texture lookups performed inside a
    loop is considered uniform for the <n>th loop iteration if all shader
    invocations that execute the loop at least <n> times compute the same
    index on that iteration.  For texture lookups inside a function other than
    main(), an index is considered uniform if the value is the same for all
    invocations calling the function from the same point in the caller.  For
    nested loops and function calls, the uniformity test requires that the
    index match only those other shader invocations with identical loop
    iteration counts and function call chains.


    Modify Section 4.1.10, Implicit Conversions, p. 27

    (modify table of implicit conversions)

                                Can be implicitly
        Type of expression        converted to
        ---------------------   -----------------
        int                     uint, float
        ivec2                   uvec2, vec2
        ivec3                   uvec3, vec3
        ivec4                   uvec4, vec4

        uint                    float
        uvec2                   vec2
        uvec3                   vec3
        uvec4                   vec4

    (modify second paragraph of the section) No implicit conversions are
    provided to convert from unsigned to signed integer types or from
    floating-point to integer types.  There are no implicit array or structure
    conversions.

    (insert before the final paragraph of the section) When performing
    implicit conversion for binary operators, there may be multiple data types
    to which the two operands can be converted.  For example, when adding an
    int value to a uint value, both values can be implicitly converted to uint
    and float.  In such cases, a floating-point type is chosen if either
    operand has a floating-point type.  Otherwise, an unsigned integer type is
    chosen if either operand has an unsigned integer type.  Otherwise, a
    signed integer type is chosen.


    Modify Section 4.3, Storage Qualifiers, p. 29

    (add to first table on the page)

      Qualifier         Meaning
      --------------    ----------------------------------------
      sample in         linkage with per-sample interpolation
      sample out        linkage with per-sample interpolation

    (modify third paragraph, p. 29) These interpolation qualifiers may only
    precede the qualifiers in, centroid in, sample in, out, centroid out, or
    sample out in a declaration.  ...


    Modify Section 4.3.4, Inputs, p. 31

    (modify first paragraph of section) Shader input variables are declared
    with the in, centroid in, or sample in storage qualifiers. ... Variables
    declared as in, centroid in, or sample in may not be written to during
    shader execution. ...

    (modify third paragraph, p. 32) ...  Fragment shader inputs get
    per-fragment values, typically interpolated from a previous stage's
    outputs.  They are declared in fragment shaders with the in, centroid in,
    or sample in storage qualifiers or the deprecated varying and centroid
    varying storage qualifiers. ...

    (add to examples immediately below)

      sample in vec4 perSampleColor;


    Modify Section 4.3.6, Outputs, p. 33

    (modify first paragraph of section) Shader output variables are declared
    with the out, centroid out, or sample out storage qualifiers. ...

    (modify third paragraph of section) Vertex and geometry output variables
    output per-vertex data and are declared using the out, centroid out, or
    sample out storage qualifiers, or the deprecated varying storage
    qualifier.

    (add to examples immediately below)

      sample out vec4 perSampleColor;

    (modify last paragraph, p. 33) Fragment outputs output per-fragment data
    and are declared using the out storage qualifier. It is an error to use
    centroid out or sample out in a fragment shader. ...


    Modify Section 4.3.7, Interface Blocks, p. 34

    (modify last paragaph, p. 36, removing the requirement for indexing
    uniform blocks using constant expressions) For uniform blocks declared as
    arrays, each individual array element corresponds to a separate buffer
    object backing one instance of the block.  As the array size indicates the
    number of buffer objects needed, uniform block array declarations must
    specify an integral array size.  Arbitrary indices may be used to index a
    uniform block array; integral constant expressions are not required.  If
    the index used to access an array of uniform blocks is out-of-bounds, the
    results of the access are undefined.


    Modify Section 4.3.8.1, Input Layout Qualifiers, p. 37

    (modify last paragraph, p. 37, and subsequent paragraphs on p. 38)

    Geometry shaders support input layout qualifiers.  There are two types of
    layout qualifiers used to specify an input primitive type and an
    invocation count.  The input primitive type and invocation count
    qualifiers are allowed only on the interface qualifier in, not on an input
    block, block member, or variable.

      layout-qualifier-id
        points
        lines
        lines_adjacency
        triangles
        triangles_adjacency
        invocations = integer-constant

    The identifiers "points", "lines", "lines_adjacency", "triangles", and
    "triangles_adjacency" are used to specify the type of input primitive
    accepted by the geometry shader, and only one of these is accepted.  At
    least one geometry shader (compilation unit) in a program must declare an
    input primitive type, and all geometry shader input primitive type
    declarations in a program must declare the same type.  It is not required
    that all geometry shaders in a program declare an input primitive type.

    The identifier "invocations" is used to specify the number of times the
    geometry shader is invoked for each input primitive received.  Invocation
    count declarations are optional.  If no invocation count is declared in
    any geometry shader in the program, the geometry shader will be run once
    for each input primitive.  If an invocation count is declared, all such
    declarations must specify the same count.  If a shader specifies an
    invocation count greater than the implementation-dependent maximum, it
    will fail to compile.

    For example,

      layout(triangles, invocations=6) in;

    will establish that all inputs to the geometry shader are triangles and
    that the geometry shader is run six times for each triangle processed.

    All geometry shader input unsized array declarations ...


    Modify Section 4.3.8.2, Output Layout Qualifiers, p. 40

    (modify second and subsequent paragraphs, p. 40)

    Geometry shaders can have output layout qualifiers.  There are three types
    of output layout qualifiers used to specify an output primitive type, a
    maximum output vertex count, and per-output stream numbers.  The output
    primitive type and output vertex count qualifiers are allowed only on the
    interface qualifier out, not on an output block, block member, or variable
    declaration.  The output stream number qualifier is allowed on the
    interface qualifier out, or on output blocks or variable declarations.

    The layout qualifier identifiers for geometry shader outputs are

      layout-qualifier-id
        points
        line_strip
        triangle_strip
        max_vertices = integer-constant
        stream = integer-constant

    The identifiers "points", "line_strip", and "triangle_strip" are used to
    specify the type of output primitive produced by the geometry shader, and
    only one of these is accepted.  At least one geometry shader (compilation
    unit) in a program must declare an output primitive type, and all geometry
    shader output primitive type declarations in a program must declare the
    same primitive type.  It is not required that all geometry shaders in a
    program declare an output primitive type.

    The identifier "max_vertices" is used to specify the maximum number of
    vertices the shader will ever emit in a single invocation.  At least one
    geometry shader (compilation unit) in a program must declare an maximum
    output vertex count, and all geometry shader output vertex count
    declarations in a program must declare the same count.  It is not required
    that all geometry shaders in a program declare a count.

    In the example,

      layout(triangle_strip, max_vertices = 60) out; // order does not matter
      layout(max_vertices = 60) out; // redeclaration okay
      layout(triangle_strip) out; // redeclaration okay
      layout(points) out; // error, contradicts triangle_strip
      layout(max_vertices = 30) out; // error, contradicts 60

    all outputs from the geometry shader are triangles and at most 60 vertices
    will be emitted by the shader.  It is an error for the maximum number of
    vertices to be greater than gl_MaxGeometryOutputVertices.

    The identifier "stream" is used to specify that a geometry shader output
    variable or block is associated with a particular vertex stream (numbered
    beginning with zero).  A default stream number may be declared at global
    scope by qualifying interface qualifier out as in this example:

      layout(stream = 1) out;

    The stream number specified in such a declaration replaces any previous
    default and applies to all subsequent block and variable declarations
    until a new default is established.  The initial default stream number is
    zero.

    Each output block or non-block output variable is associated with a vertex
    stream.  If the block or variable is declared with a stream qualifier, it
    is associated with the specified stream; otherwise, it is associated with
    the current default stream.  A block member may be declared with a stream
    qualifier, but the specified stream must match the stream associated with
    the containing block.  One example:

      layout(stream=1) out;             // default is now stream 1
      out vec4 var1;                    // var1 gets default stream (1)
      layout(stream=2) out Block1 {     // "Block1" belongs to stream 2
        layout(stream=2) vec4 var2;     // redundant block member stream decl
        layout(stream=3) vec2 var3;     // ILLEGAL (must match block stream)
        vec3 var4;                      // belongs to stream 2
      };
      layout(stream=0) out;             // default is now stream 0
      out vec4 var5;                    // var5 gets default stream (0)
      out Block2 {                      // "Block2" gets default stream (0)
        vec4 var6;
      };
      layout(stream=3) out vec4 var7;   // var7 belongs to stream 3

    If a geometry shader output block or variable is declared more than once,
    all such declarations must associate the variable with the same vertex
    stream.  If any stream declaration specifies a non-existent stream number,
    the shader will fail to compile.

    Built-in geometry shader outputs are always associated with vertex stream
    zero.

    Each vertex emitted by the geometry shader is assigned to a specific
    stream, and the attributes of the emitted vertex are taken from the set of
    output blocks and variables assigned to the targeted stream.  After each
    vertex is emitted, the values of all output variables become undefined.
    Additionally, the output variables associated with each vertex stream may
    share storage.  Writing to an output variable associated with one stream
    may overwrite output variables associated with any other stream.  When
    emitting each vertex, a geometry shader should write to all outputs
    associated with the stream to which the vertex will be emitted and to no
    outputs associated with any other stream.


    Modify Section 4.3.9, Interpolation, p. 42

    (modify first paragraph of section, add reference to sample in/out) The
    presence of and type of interpolation is controlled by the storage
    qualifiers centroid in, sample in, centroid out, and sample out, by the
    optional interpolation qualifiers smooth, flat, and noperspective, and by
    default behaviors established through the OpenGL API when no interpolation
    qualifier is present. ...

    (modify second paragraph) ... A variable may be qualified as flat centroid
    or flat sample, which will mean the same thing as qualifying it only as
    flat.

    (replace last paragraph, p. 42)

    When multisample rasterization is disabled, or for fragment shader input
    variables qualified with neither "centroid in" nor "sample in", the value
    of the assigned variable may be interpolated anywhere within the pixel and
    a single value may be assigned to each sample within the pixel, to the
    extent permitted by the OpenGL Specification.

    When multisample rasterization is enabled, "centroid" and "sample" may be
    used to control the location and frequency of the sampling of the
    qualified fragment shader input.  If a fragment shader input is qualified
    with "centroid", a single value may be assigned to that variable for all
    samples in the pixel, but that value must be interpolated at a location
    that lies in both the pixel and in the primitive being rendered, including
    any of the pixel's samples covered by the primitive.  Because the location
    at which the variable is sampled may be different in neighboring pixels,
    derivatives of centroid-sampled inputs may be less accurate than those for
    non-centroid interpolated variables.  If a fragment shader input is
    qualified with "sample", a separate value must be assigned to that
    variable for each covered sample in the pixel, and that value must be
    sampled at the location of the individual sample.


    (Insert before Section 4.7, Order of Qualification, p. 47)

    Section 4.Q, The Precise Qualifier

    Some algorithms may require that floating-point computations be carried
    out in exactly the manner specified in the source code, even if the
    implementation supports optimizations that could produce nearly equivalent
    results with higher performance.  For example, many GL implementations
    support a "multiply-add" that can compute values such as

      float result = (float(a) * float(b)) + float(c);

    in a single operation.  The result of a floating-point multiply-add may
    not always be identical to first doing a multiply yielding a
    floating-point result, and then doing a floating-point add.  By default,
    implementations are permitted to perform optimizations that effectively
    modify the order of the operations used to evaluate an expression, even if
    those optimizations may produce slightly different results relative to
    unoptimized code.

    The qualifier "precise" will ensure that operations contributing to a
    variable's value are performed in the order and with the precision
    specified in the source code.  Order of evaluation is determined by
    operator precedence and parentheses, as described in Section 5.
    Expressions must be evaluated with a precision consistent with the
    operation; for example, multiplying two "float" values must produce a
    single value with "float" precision.  This effectively prohibits the
    arbitrary use of fused multiply-add operations if the intermediate
    multiply result is kept at a higher precision.  For example:

      precise out vec4 position;

    declares that computations used to produce the value of "position" must be
    performed precisely using the order and precision specified.  As with the
    invariant qualifier (section 4.6.1), the precise qualifier may be used to
    qualify a built-in or previously declared user-defined variable as being
    precise:

      out vec3 Color;
      precise Color;            // make existing Color be precise

    This qualifier will affect the evaluation of expressions used on the
    right-hand side of an assignment if and only if:

      * the variable assigned to is qualified as "precise"; or

      * the value assigned is used later in the same function, either directly
        or indirectly, on the right-hand of an assignment to a variable
        declared as "precise".

    Expressions computed in a function are treated as precise only if assigned
    to a variable qualified as "precise" in that same function.  Any other
    expressions within a function are not automatically treated as precise,
    even if they are used to determine a value that is returned by the
    function and directly assigned to a variable qualified as "precise".

    Some examples of the use of "precise" include:

      in vec4 a, b, c, d;
      precise out vec4 v;

      float func(float e, float f, float g, float h)
      {
        return (e*f) + (g*h);            // no special precision
      }

      float func2(float e, float f, float g, float h)
      {
        precise result = (e*f) + (g*h);  // ensures a precise return value
        return result;
      }

      float func3(float i, float j, precise out float k)
      {
        k = i * i + j;                   // precise, due to <k> declaration
      }

      void main(void)
      {
        vec4 r = vec3(a * b);           // precise, used to compute v.xyz
        vec4 s = vec3(c * d);           // precise, used to compute v.xyz
        v.xyz = r + s;                          // precise
        v.w = (a.w * b.w) + (c.w * d.w);        // precise
        v.x = func(a.x, b.x, c.x, d.x);         // values computed in func()
                                                // are NOT precise
        v.x = func2(a.x, b.x, c.x, d.x);        // precise!
        func3(a.x * b.x, c.x * d.x, v.x);       // precise!
      }


    Modify Section 4.7, Order of Qualification, p. 47

    When multiple qualifications are present, they must follow a strict order.
    This order is as follows:

      precise-qualifier invariant-qualifier interpolation-qualifier storage-qualifier
         precision-qualifier


    Modify Section 5.9, Expressions, p. 57

    (modify bulleted list as follows, adding support for implicit conversion
    between signed and unsigned types)

    Expressions in the shading language are built from the following:

    * Constants of type bool, int, int64_t, uint, uint64_t, float, all vector
      types, and all matrix types.

    ...

    * The operator modulus (%) operates on signed or unsigned integer scalars
      or vectors.  If the fundamental types of the operands do not match, the
      conversions from Section 4.1.10 "Implicit Conversions" are applied to
      produce matching types.  ...


    Modify Section 6.1, Function Definitions, p. 63

    (modify description of overloading, beginning at the top of p. 64)

     Function names can be overloaded.  The same function name can be used for
     multiple functions, as long as the parameter types differ.  If a function
     name is declared twice with the same parameter types, then the return
     types and all qualifiers must also match, and it is the same function
     being declared.  For example,

       vec4 f(in vec4 x, out vec4  y);   // (A)
       vec4 f(in vec4 x, out uvec4 y);   // (B) okay, different argument type
       vec4 f(in ivec4 x, out uvec4 y);  // (C) okay, different argument type

       int  f(in vec4 x, out ivec4 y);  // error, only return type differs
       vec4 f(in vec4 x, in  vec4  y);  // error, only qualifier differs
       vec4 f(const in vec4 x, out vec4 y);  // error, only qualifier differs

     When function calls are resolved, an exact type match for all the
     arguments is sought.  If an exact match is found, all other functions are
     ignored, and the exact match is used.  If no exact match is found, then
     the implicit conversions in Section 4.1.10 (Implicit Conversions) will be
     applied to find a match.  Mismatched types on input parameters (in or
     inout or default) must have a conversion from the calling argument type
     to the formal parameter type.  Mismatched types on output parameters (out
     or inout) must have a conversion from the formal parameter type to the
     calling argument type.

     If implicit conversions can be used to find more than one matching
     function, a single best-matching function is sought.  To determine a best
     match, the conversions between calling argument and formal parameter
     types are compared for each function argument and pair of matching
     functions.  After these comparisons are performed, each pair of matching
     functions are compared.  A function definition A is considered a better
     match than function definition B if:

       * for at least one function argument, the conversion for that argument
         in A is better than the corresponding conversion in B; and

       * there is no function argument for which the conversion in B is better
         than the corresponding conversion in A.

     If a single function definition is considered a better match than every
     other matching function definition, it will be used.  Otherwise, a
     semantic error occurs and the shader will fail to compile.

     To determine whether the conversion for a single argument in one match is
     better than that for another match, the following rules are applied, in
     order:

       1. An exact match is better than a match involving any implicit
          conversion.

       2. A match involving an implicit conversion from float to double is
          better than a match involving any other implicit conversion.

       3. A match involving an implicit conversion from either int or uint to
          float is better than a match involving an implicit conversion from
          either int or uint to double.

     If none of the rules above apply to a particular pair of conversions,
     neither conversion is considered better than the other.

     For the function prototypes (A), (B), and (C) above, the following
     examples show how the rules apply to different sets of calling argument
     types:

       f(vec4, vec4);        // exact match of vec4 f(in vec4 x, out vec4 y)
       f(vec4, uvec4);       // exact match of vec4 f(in vec4 x, out ivec4 y)
       f(vec4, ivec4);       // matched to vec4 f(in vec4 x, out vec4 y)
                             //   (C) not relevant, can't convert vec4 to
                             //   ivec4.  (A) better than (B) for 2nd
                             //   argument (rule 2), same on first argument.
       f(ivec4, vec4);       // NOT matched.  All three match by implicit
                             //   conversion.  (C) is better than (A) and (B)
                             //   on the first argument.  (A) is better than
                             //   (B) and (C).


    Modify Section 7.1, Vertex And Geometry Shader Special Variables, p. 69

    (add to the list of geometry shader special variables, p. 69)

      in int gl_InvocationID;

    (add to the end of the section, p. 71)

    The input variable gl_InvocationID is available in the geometry language
    and is filled with an integer holding the invocation number associated
    with the given shader invocation.  If the program is linked to support
    multiple geometry shader invocations per input primitive, the invocations
    are numbered 0, 1, 2, ..., <N>-1.  gl_InvocationID is not available in the
    vertex or fragment language.


    Modify Section 7.2, Fragment Shader Special Variables, p. 72

    (add to the list of built-in variables)

      in int gl_SampleMaskIn[];

    The variable gl_SampleMaskIn is an array of integers, each holding a
    bitfield indicating the set of samples covered by the primitive generating
    the fragment during multisample rasterization.  The array has ceil(<s>/32)
    elements, where <s> is the maximum number of color samples supported by
    the implementation.  Bit <n> or word <w> in the bitfield is set if and
    only if the sample numbered <w>*32+<n> is considered covered for this
    fragment shader invocation.


    Modify Section 8.3, Common Functions, p. 84

    (add support for floating-point multiply-add)

    Syntax:

      genType fma(genType a, genType b, genType c);

    The function fma() performs a fused floating-point multiply-add to compute
    the value a*b+c.  The results of fma() may not be identical to evaluating
    the expression (a*b)+c, because the computation may be performed in a
    single operation with intermediate precision different from that used to
    compute a non-fma() expression.

    The results of fma() are guaranteed to be invariant given fixed inputs
    <a>, <b>, and <c>, as though the result were taken from a variable
    declared as "precise".


    (add support for single-precision frexp and ldexp functions)

    Syntax:

      genType frexp(genType x, out genIType exp);
      genType ldexp(genType x, in genIType exp);

    The function frexp() splits each single-precision floating-point number in
    <x> into a binary significand, a floating-point number in the range [0.5,
    1.0), and an integral exponent of two, such that:

      x = significand * 2 ^ exponent

    The significand is returned by the function; the exponent is returned in
    the parameter <exp>.  For a floating-point value of zero, the significant
    and exponent are both zero.  For a floating-point value that is an
    infinity or is not a number, the results of frexp() are undefined.

    If the input <x> is a vector, this operation is performed in a
    component-wise manner; the value returned by the function and the value
    written to <exp> are vectors with the same number of components as <x>.

    The function ldexp() builds a single-precision floating-point number from
    each significand component in <x> and the corresponding integral exponent
    of two in <exp>, returning:

      significand * 2 ^ exponent

    If this product is too large to be represented as a single-precision
    floating-point value, the result is considered undefined.

    If the input <x> is a vector, this operation is performed in a
    component-wise manner; the value passed in <exp> and returned by the
    function are vectors with the same number of components as <x>.


    (add support for new integer built-in functions)

    Syntax:

      genIType bitfieldExtract(genIType value, int offset, int bits);
      genUType bitfieldExtract(genUType value, int offset, int bits);

      genIType bitfieldInsert(genIType base, genIType insert, int offset,
                              int bits);
      genUType bitfieldInsert(genUType base, genUType insert, int offset,
                              int bits);

      genIType bitfieldReverse(genIType value);
      genUType bitfieldReverse(genUType value);

      genIType bitCount(genIType value);
      genIType bitCount(genUType value);

      genIType findLSB(genIType value);
      genIType findLSB(genUType value);

      genIType findMSB(genIType value);
      genIType findMSB(genUType value);

    The function bitfieldExtract() extracts bits <offset> through
    <offset>+<bits>-1 from each component in <value>, returning them in the
    least significant bits of corresponding component of the result.  For
    unsigned data types, the most significant bits of the result will be set
    to zero.  For signed data types, the most significant bits will be set to
    the value of bit <offset>+<base>-1.  If <bits> is zero, the result will be
    zero.  The result will be undefined if <offset> or <bits> is negative, or
    if the sum of <offset> and <bits> is greater than the number of bits used
    to store the operand.  Note that for vector versions of bitfieldExtract(),
    a single pair of <offset> and <bits> values is shared for all components.

    The function bitfieldInsert() inserts the <bits> least significant bits of
    each component of <insert> into the corresponding component of <base>.
    The result will have bits numbered <offset> through <offset>+<bits>-1
    taken from bits 0 through <bits>-1 of <insert>, and all other bits taken
    directly from the corresponding bits of <base>.  If <bits> is zero, the
    result will simply be <base>.  The result will be undefined if <offset> or
    <bits> is negative, or if the sum of <offset> and <bits> is greater than
    the number of bits used to store the operand.  Note that for vector
    versions of bitfieldInsert(), a single pair of <offset> and <bits> values
    is shared for all components.

    The function bitfieldReverse() reverses the bits of <value>.  The bit
    numbered <n> of the result will be taken from bit (<bits>-1)-<n> of
    <value>, where <bits> is the total number of bits used to represent
    <value>.

    The function bitCount() returns the number of one bits in the binary
    representation of <value>.

    The function findLSB() returns the bit number of the least significant one
    bit in the binary representation of <value>.  If <value> is zero, -1 will
    be returned.

    The function findMSB() returns the bit number of the most significant bit
    in the binary representation of <value>.  For positive integers, the
    result will be the bit number of the most significant one bit.  For
    negative integers, the result will be the bit number of the most
    significant zero bit.  For a <value> of zero or negative one, -1 will be
    returned.


    (add support for general packing functions)

    Syntax:

      uint      packUnorm2x16(vec2 v);
      uint      packUnorm4x8(vec4 v);
      uint      packSnorm4x8(vec4 v);

      vec2      unpackUnorm2x16(uint v);
      vec4      unpackUnorm4x8(uint v);
      vec4      unpackSnorm4x8(uint v);

    The functions packUnorm2x16(), packUnorm4x8(), and packSnorm4x8() first
    convert each component of a two- or four-component vector of normalized
    floating-point values into 8- or 16-bit integer values.  Then, the results
    are packed into a 32-bit unsigned integer.  The first component of the
    vector will be written to the least significant bits of the output; the
    last component will be written to the most significant bits.

    The functions unpackUnorm2x16(), unpackUnorm4x8(), and unpackSnorm4x8()
    first unpacks a single 32-bit unsigned integer into a pair of 16-bit
    unsigned integers, four 8-bit unsigned integers, or four 8-bit signed
    integers.  The, each component is converted to a normalized floating-point
    value to generate a two- or four-component vector.  The first component of
    the vector will be extracted from the least significant bits of the input;
    the last component will be extracted from the most significant bits.

    The conversion between fixed- and normalized floating-point values will be
    performed as below.

      function          conversion
      ---------------   -----------------------------------------------------
      packUnorm2x16     fixed_val = round(clamp(float_val, 0, +1) * 65535.0);
      packUnorm4x8      fixed_val = round(clamp(float_val, 0, +1) * 255.0);
      packSnorm4x8      fixed_val = round(clamp(float_val, -1, +1) * 127.0);
      unpackUnorm2x16   float_val = fixed_val / 65535.0;
      unpackUnorm4x8    float_val = fixed_val / 255.0;
      unpackSnorm4x8    float_val = clamp(fixed_val / 127.0, -1, +1);


    (add functions to get/set the bit encoding for floating-point values)

    32-bit floating-point data types in the OpenGL shading language are
    specified to be encoded according to the IEEE 754 specification for
    single-precision floating-point values.  The functions below allow shaders
    to convert floating-point values to and from signed or unsigned integers
    representing their encoding.

    To obtain signed or unsigned integer values holding the encoding of a
    floating-point value, use:

      genIType floatBitsToInt(genType value);
      genUType floatBitsToUint(genType value);

    Conversions are done on a component-by-component basis.

    To obtain a floating-point value corresponding to a signed or unsigned
    integer encoding, use:

      genType intBitsToFloat(genIType value);
      genType uintBitsToFloat(genUType value);


    (support for unsigned integer add/subtract with carry-out)

    Syntax:

      genUType uaddCarry(genUType x, genUType y, out genUType carry);
      genUType usubBorrow(genUType x, genUType y, out genUType borrow);

    The function uaddCarry() adds 32-bit unsigned integers or vectors <x> and
    <y>, returning the sum modulo 2^32.  The value <carry> is set to zero if
    the sum was less than 2^32, or one otherwise.

    The function usubBorrow() subtracts the 32-bit unsigned integer or vector
    <y> from <x>, returning the difference if non-negative or 2^32 plus the
    difference, otherwise.  The value <borrow> is set to zero if x >= y, or
    one otherwise.


    (support for signed and unsigned multiplies, with 32-bit inputs and a
     64-bit result spanning two 32-bit outputs)

    Syntax:

      void umulExtended(genUType x, genUType y, out genUType msb,
                        out genUType lsb);
      void imulExtended(genIType x, genIType y, out genIType msb,
                        out genIType lsb);

    The functions umulExtended() and imulExtended() multiply 32-bit unsigned
    or signed integers or vectors <x> and <y>, producing a 64-bit result.  The
    32 least significant bits are returned in <lsb>; the 32 most significant
    bits are returned in <msb>.


    Modify Section 8.7, Texture Lookup Functions, p. 91

    (extend the basic versions of textureGather from ARB_texture_gather,
     allowing for optional component selection in a multi-component texture
     and for shadow mapping)

    Syntax:
      gvec4 textureGather(gsampler2D sampler, vec2 coord[, int comp]);
      gvec4 textureGather(gsampler2DArray sampler, vec3 coord[, int comp]);
      gvec4 textureGather(gsamplerCube sampler, vec3 coord[, int comp]);
      gvec4 textureGather(gsamplerCubeArray sampler, vec4 coord[, int comp]);
      gvec4 textureGather(gsampler2DRect sampler, vec2 coord[, int comp]);

      vec4 textureGather(sampler2DShadow sampler, vec2 coord, float refZ);
      vec4 textureGather(sampler2DArrayShadow sampler, vec3 coord, float refZ);
      vec4 textureGather(samplerCubeShadow sampler, vec3 coord, float refZ);
      vec4 textureGather(samplerCubeArrayShadow sampler, vec4 coord,
                         float refZ);
      vec4 textureGather(sampler2DRectShadow sampler, vec2 coord, float refZ);

    The textureGather() functions use the texture coordinates given by <coord>
    to determine a set of four texels to sample from the texture identified by
    <sampler>.  These functions return a four-component vector consisting of
    one component from each texel.  If specified, the value of <comp> must be
    a constant integer expression with a value of zero, one, two, or three,
    identifying the <x>, <y>, <z>, or <w> component of the four-component
    vector lookup result for each texel, respectively.  If <comp> is not
    specified, the <x> component of each texel will be used to generate the
    result vector.  As described in the OpenGL Specification, the vector
    selects the post-swizzle component corresponding to <comp> from each of
    the four texels, returning:

      vec4(T_i0_j1(coord, base).<comp>,
           T_i1_j1(coord, base).<comp>,
           T_i1_j0(coord, base).<comp>,
           T_i0_j0(coord, base).<comp>)

    For textureGather() functions using a shadow sampler type, each of the
    four texel lookups performs a depth comparison against the depth reference
    value passed in <refZ>, and returns the result of that comparison in the
    appropriate component of the result vector.  The parameter <comp> used for
    component selection is not supported for textureGather() functions with
    shader sampler types.

    As with other texture lookup functions, the results of textureGather() are
    undefined for shadow samplers if the texture referenced is not a depth
    texture or has depth comparisons disabled; or for non-shadow samplers if
    the texture referenced is a depth texture with depth comparisons enabled.


    (extend the "Offset" versions of textureGather from ARB_texture_gather,
     allowing for optional component selection in a multi-component texture,
     non-constant offsets, and shadow mapping)

    Syntax:
      gvec4 textureGatherOffset(gsampler2D sampler, vec2 coord,
                                ivec2 offset[, int comp]);
      gvec4 textureGatherOffset(gsampler2DArray sampler, vec3 coord,
                                ivec2 offset[, int comp]);
      gvec4 textureGatherOffset(gsampler2DRect sampler, vec2 coord,
                                ivec2 offset[, int comp]);

      vec4 textureGatherOffset(sampler2DShadow sampler, vec2 coord,
                               float refZ, ivec2 offset);
      vec4 textureGatherOffset(sampler2DArrayShadow sampler, vec3 coord,
                               float refZ, ivec2 offset);
      vec4 textureGatherOffset(sampler2DRectShadow sampler, vec2 coord,
                               float refZ, ivec2 offset);

    The textureGatherOffset() functions operate identically to
    textureGather(), except that the 2-component integer texel offset vector
    <offset> is applied as a (u,v) offset to determine the four texels to
    sample.  The value <offset> need not be constant; however, a limited range
    of offset values are supported.  If any component of <offset> is less than
    MIN_PROGRAM_TEXTURE_GATHER_OFFSET_ARB or greater than
    MAX_PROGRAM_TEXTURE_GATHER_OFFSET_ARB, the offset applied to the texture
    coordinates is undefined.  Note that <offset> does not apply to the layer
    coordinate for array textures.


    (add new "Offsets" versions of textureGather from ARB_texture_gather,
     allowing for optional component selection in a multi-component texture,
     separate non-constant offsets for each texel in the footprint, and shadow
     mapping)

    Syntax:
      gvec4 textureGatherOffsets(gsampler2D sampler, vec2 coord,
                                 ivec2 offsets[4][, int comp]);
      gvec4 textureGatherOffsets(gsampler2DArray sampler, vec3 coord,
                                 ivec2 offsets[4][, int comp]);
      gvec4 textureGatherOffsets(gsampler2DRect sampler, vec2 coord,
                                 ivec2 offsets[4][, int comp]);

      vec4 textureGatherOffsets(sampler2DShadow sampler, vec2 coord,
                                float refZ, ivec2 offsets[4]);
      vec4 textureGatherOffsets(sampler2DArrayShadow sampler, vec3 coord,
                                float refZ, ivec2 offsets[4]);
      vec4 textureGatherOffsets(sampler2DRectShadow sampler, vec2 coord,
                                float refZ, ivec2 offsets[4]);

    The textureGatherOffsets() functions operate identically to
    textureGather(), except that the array of two-component integer vectors
    <offsets> is used to determine the location of the four texels to sample.
    Each of the four texels is obtained by applying the corresponding offset
    in the four-element array <offsets> as a (u,v) coordinate offset to the
    coordinates <coord>, identifying the four-texel LINEAR footprint, and then
    selecting the texel T_i0_j0 of that footprint.  The specified values in
    <offsets> must be constant.  A limited range of offset values are
    supported; the minimum and maximum offset values are
    implementation-dependent and given by
    MIN_PROGRAM_TEXTURE_GATHER_OFFSET_ARB and
    MAX_PROGRAM_TEXTURE_GATHER_OFFSET_ARB, respectively.  Note that <offset>
    does not apply to the layer coordinate for array textures.


    Modify Section 8.8, Fragment Processing Functions, p. 101

    (add new functions to the end of section, p. 102)

    Built-in interpolation functions are available to compute an interpolated
    value of a fragment shader input variable at a shader-specified (x,y)
    location.  A separate (x,y) location may be used for each invocation of
    the built-in function, and those locations may differ from the default
    (x,y) location used to produce the default value of the input.

      float interpolateAtCentroid(float interpolant);
      vec2 interpolateAtCentroid(vec2 interpolant);
      vec3 interpolateAtCentroid(vec3 interpolant);
      vec4 interpolateAtCentroid(vec4 interpolant);

      float interpolateAtSample(float interpolant, int sample);
      vec2 interpolateAtSample(vec2 interpolant, int sample);
      vec3 interpolateAtSample(vec3 interpolant, int sample);
      vec4 interpolateAtSample(vec4 interpolant, int sample);

      float interpolateAtOffset(float interpolant, vec2 offset);
      vec2 interpolateAtOffset(vec2 interpolant, vec2 offset);
      vec3 interpolateAtOffset(vec3 interpolant, vec2 offset);
      vec4 interpolateAtOffset(vec4 interpolant, vec2 offset);

    The function interpolateAtCentroid() will return the value of the input
    varying <interpolant> sampled at a location inside the both the pixel and
    the primitive being processed.  The value obtained would be the same value
    assigned to the input variable if declared with the "centroid" qualifier.

    The function interpolateAtSample() will return the value of the input
    varying <interpolant> at the location of the sample numbered <sample>.  If
    multisample buffers are not available, the input varying will be evaluated
    at the center of the pixel.  If the sample number given by <sample> does
    not exist, the position used to interpolate the input varying is
    undefined.

    The function interpolateAtOffset() will return the value of the input
    varying <interpolant> sampled at an offset from the center of the pixel
    specified by <offset>.  The two floating-point components of <offset>
    give the offset in pixels in the x and y directions, respectively.
    An offset of (0,0) identifies the center of the pixel.  The range and
    granularity of offsets supported by this function is
    implementation-dependent.

    For all of the interpolation functions, <interpolant> must be an input
    variable or an element of an input variable declared as an array.
    Component selection operators (e.g., ".xy") may not be used when
    specifying <interpolant>.  If <interpolant> is declared with a "flat" or
    "centroid" qualifier, the qualifier will have no effect on the
    interpolated value.  If <interpolant> is declared with the "noperspective"
    qualifier, the interpolated value will be computed without perspective
    correction.


    Modify Section 8.10, Geometry Shader Functions, p. 104

    (replace the section, using the following more general formulation)

    These functions are only available in geometry shaders.

    Syntax:

        void EmitStreamVertex(int stream);      // Geometry-only
        void EndStreamPrimitive(int stream);    // Geometry-only

        void EmitVertex();                      // Geometry-only
        void EndPrimitive();                    // Geometry-only

    Description:

    The function EmitStreamVertex() specifies that the vertex being generated
    by the geometry shader is completed.  A vertex is added to the current
    output primitive in the vertex stream numbered <stream> using the current
    values of all output variables associated with <stream>.  The values of
    any unwritten output variables associated with <stream> are undefined.
    The argument <stream> must be a constant integral expression.  The values
    of all output variables (for all output streams) are undefined after
    calling EmitStreamVertex().  If a geometry shader invocation has emitted
    more vertices than permitted by the output layout qualifier
    "max_vertices", the results of calling EmitStreamVertex() are undefined.

    The function EmitVertex() is equivalent to calling EmitStreamVertex() with
    <stream> set to zero.

    The function EndStreamPrimitive() specifies that the current output
    primitive for the vertex stream numbered <stream> is completed and that a
    new empty output primitive of the same type should be started.  The
    argument <stream> must be a constant integral expression.  This function
    does not emit a vertex.  If the output layout is declared to be "points",
    calling EndPrimitive() is optional.

    The function EndPrimitive() is equivalent to calling EndStreamPrimitive()
    with <stream> set to zero.

    A geometry shader starts with an output primitive containing no vertices
    for each stream.  When a geometry shader terminates, the current output
    primitive for each vertex stream is automatically completed.  It is not
    necessary to call EndPrimitive() or EndStreamPrimitive() for any stream
    where the geometry shader writes only a single primitive.

    Multiple vertex streams are supported only if the output primitive type is
    declared to be "points".  A program will fail to link if it contains a
    geometry shader calling EmitStreamVertex() or EndStreamPrimitive() if its
    output primitive type is not "points".


    Modify Section 9, Shading Language Grammar, p. 92

    !!! TBD !!!


GLX Protocol

    None.

Dependencies on ARB_gpu_shader_fp64

    This extension, ARB_gpu_shader_fp64, and NV_gpu_shader5 all modify the set
    of implicit conversions supported in the OpenGL Shading Language.  If more
    than one of these extensions is supported, an expression of one type may
    be converted to another type if that conversion is allowed by any of these
    specifications.

    If ARB_gpu_shader_fp64 or a similar extension introducing new data types
    is not supported, the function overloading rule in the GLSL specification
    preferring promotion an input parameters to smaller type to a larger type
    is never applicable, as all data types are of the same size.  That rule
    and the example referring to "double" should be removed.


Dependencies on NV_gpu_shader5

    This extension, ARB_gpu_shader_fp64, and NV_gpu_shader5 all modify the set
    of implicit conversions supported in the OpenGL Shading Language.  If more
    than one of these extensions is supported, an expression of one type may
    be converted to another type if that conversion is allowed by any of these
    specifications.

    This specification and NV_gpu_shader5 both lift the restriction in GLSL
    1.50 requiring that indexing in arrays of samplers must be done with
    constant expressions.  However, this extension specifies that results are
    undefined if the indices would diverge if multiple shader invocations are
    run in lockstep.  NV_gpu_shader5 does not impose the non-divergent
    indexing requirement.

    If NV_gpu_shader5 is supported, integer data types are supported with four
    different precisions (8-, 16, 32-, and 64-bit) and floating-point data
    types are supported with three different precisions (16-, 32-, and
    64-bit).  The extension adds the following rule for output parameters,
    which is similar to the one present in this extension for input
    parameters:

       5. If the formal parameters in both matches are output parameters, a
          conversion from a type with a larger number of bits per component is
          better than a conversion from a type with a smaller number of bits
          per component.  For example, a conversion from an "int16_t" formal
          parameter type to "int"  is better than one from an "int8_t" formal
          parameter type to "int".

    Such a rule is not provided in this extension because there is no
    combination of types in this extension and ARB_gpu_shader_fp64 where this
    rule has any effect.


Dependencies on ARB_sample_shading

    This extension builds upon the per-sample shading support provided by
    ARB_sample_shading to provide several new capabilities, including:

      * the built-in variable gl_SampleMaskIn[] indicates the set of samples
        covered by the input primitive corresponding to the fragment shader
        invocation; and

      * use of the "sample" qualifier on a fragment shader input forces
        per-sample shading, and specifies that the value of the input be
        evaluated per-sample.

    There is no interaction between the extensions, except that shaders using
    the features of this extension seem likely to use features from
    ARB_sample_shading as well.


Dependencies on ARB_texture_gather

    This extension builds upon the textureGather() built-ins provided by
    ARB_texture_gather to provide several new capabilities, including:

      * allowing shaders to select any single component of a multi-component
        texture to produce the gathered 2x2 footprint;

      * allowing shaders to perform a per-sample depth comparison when
        gathering the 2x2 footprint using for shadow sampler types;

      * allowing shaders to use arbitrary offsets computed at run-time to
        select a 2x2 footprint to gather from; and

      * allowing shaders to use separate independent offsets for each of the
        four texels returned, instead of requiring a fixed 2x2 footprint.

    Other than the fact that they provide similar functionality, there is no
    interaction between the extensions.

    Since this extension requires support for gathering from multi-component
    textures, the minimum value of MAX_PROGRAM_TEXTURE_GATHER_COMPONENTS_ARB
    is increased to 4.


Errors

    INVALID_OPERATION is generated by GetProgram if <pname> is
    GEOMETRY_SHADER_INVOCATIONS and the program which has not been linked
    successfully, or does not contain objects to form a geometry shader.


New State

    Add the following state to Table 6.40, Program Object State, p. 378

                                                    Initial
    Get Value                 Type   Get Command     Value     Description                  Sec.  Attribute
    ------------------------- ----  ------------    -------    -------------------------   ------  -------
    GEOMETRY_SHADER_           Z+    GetProgramiv      1       number of times a geometry  6.1.16    -
      INVOCATIONS                                              shader should be executed
                                                               for each input primitive

New Implementation Dependent State

                                               Min.
    Get Value               Type  Get Command  Value  Description                  Sec.      Attrib
    ----------------------  ----  -----------  -----  --------------------------   --------  ------
    MAX_GEOMETRY_SHADER_     Z+   GetIntegerv   32    maximum supported geometry   2.16.4      -
      INVOCATIONS                                     shader invocation count
    MIN_FRAGMENT_INTERP-     R    GetFloatv    -0.5   furthest negative offset     3.12.1      -
      OLATION_OFFSET                                   for interpolateAtOffset()
    MAX_FRAGMENT_INTERP-     R    GetFloatv    +0.5   furthest positive offset     3.12.1      -
      OLATION_OFFSET                                   for interpolateAtOffset()
    FRAGMENT_INTERPOLATION_  Z+   GetIntegerv    4    supixel bits for             3.12.1      -
      OFFSET_BITS                                      interpolateAtOffset()
    MAX_VERTEX_STREAMS       Z+   GetInteger     4    total number of vertex       2.16.4      -
                                                       streams

    (Note:  The minimum value for MAX_PROGRAM_TEXTURE_GATHER_COMPONENTS_ARB,
     added by ARB_texture_gather, is increased to 4.)

Issues

    (1) This extension builds on the capability provided by
        ARB_sample_shading, adding a new built-in variable for the input
        sample mask.  It seems likely that a shader using this mask might also
        want to use one or more ARB_sample_shading built-ins.  Are such
        shaders required to include #extension lines for both extensions?

      UNRESOLVED:  It would be nice if it wasn't required.

    (2) How do the per-sample shading features of this extension interact with
        non-multisample rendering?

      RESOLVED:  Non-multisample rendering (due to no multisample buffer or
      MULTISAMPLE disabled) is treated as single-sample rendering.

    (3) This extension lifts the restriction requiring that indices into
        samplers be constant expressions, but makes the results undefined if
        the indices used would diverge in lockstep execution.  What is this
        good for?

      RESOLVED:  This allows shaders to index into samplers using integer
      uniforms, or with non-divergent values computed at run-time (e.g., loop
      counters).  Many implementations of this extension will be SIMD, running
      multiple shader invocations at once, and some implementations may have
      difficulty with accessing multiple textures in a single SIMD
      instruction.

      Note that the NV_gpu_shader5 extension similarly lifts the restriction
      but does not require non-divergent indexing.

    (4) What sort of implicit conversions should we support in this and
        related extensions?

      RESOLVED:  In GLSL 1.50, we have implicit conversion from "int" and
      "uint" to "float", as well as equivalent conversions for vector type.
      One of the primary motivations of this feature is to allow constants
      that are nominally integer values to be used in floating-point contexts
      without requiring special suffixes.  The following code compiles
      successfully in GLSL 1.50.

        float square(float x) {
          return x * x;
        }
        float f = 0;
        float g = f * 2;
        float h = square(3);

      The same code would fail on GLSL 1.1, because "0", "2", and "3" would
      need to be written as "0.0", "2.0", and "3.0", respectively.

      This extension adds implicit conversions from "int" to "uint" to allow
      for cases like:

        uint square(uint x) {
          return x * x;
        }
        uint v = square(2);

      This code is legal with this extension, but not in GLSL 1.50 ("2" would
      need to be replaced with "2U" or "uint(2)").

      ARB_gpu_shader_fp64 adds a new type "double", and we extend existing
      implicit conversions to allow for promotion of "int", "uint", and
      "float" to "double".

      Unlike C/C++, the general rule for implicit conversions in GLSL is that
      conversions are unidirectional.  If type A can be implicitly converted
      to type B, type B can not be converted to type A.

    (5) Increasing the number of available implicit conversions means that
        there is the possibility of ambiguities in various operators?  How do
        we deal with these cases?

      RESOLVED:  For binary operators, the new implicit conversions mean that
      there may be multiple ways to resolve an expression.  For example, in
      the following declaration

        int i;
        uint u;

      the expression "i+u" could be resolved either by implicitly converting
      "i" to "uint", or by implicitly converting both values to either "float"
      or "double".  To resolve, we define a set of preferences for a common
      data type based on the types of the operands:

        - use a floating-point type if either operand is floating-point
        - use an unsigned integer type if either operand is unsigned
        - use a signed integer type otherwise

      If conversions to multiple precisions are supported, the
      lowest-precision available data type is preferred (e.g., int*float will
      be converted to float*float and not double*double).

      These rules should extend naturally if new basic data types are added.

    (6) Increasing the number of available implicit conversions means that
        there is an increased possibility of ambiguity when function
        overloading is involved?  Additionally, this and related extensions
        add new function overloads?  How do we deal with these cases?

      RESOLVED:  The general rule for function overloading in GLSL 1.50 is
      that we first check for a function prototype that exactly matches the
      parameters passed to a function call.  If no match exists, we check for
      prototypes that can be matched by implicit conversions.  If more than
      one matching prototype can be matched by conversion, the function call
      is considered ambiguous and results in a complication error.

      Unfortunately, when adding new implicit conversions, it is possible for
      cases that were formally unambiguous to become ambiguous.  For backward
      compatibility purposes, it would be desirable to ensure that shaders
      that succeeded in old language versions should still compile if
      "upgraded" to more recent versions/extensions.  However, the new
      conversions and overloads might make this more difficult without
      modifying other language rules.  For example, the following prototypes
      are available for the standard built-in function min() on scalar values
      when this extension and ARB_gpu_shader_fp64 are supported:

        int     min(int a, int b);
        uint    min(uint a, uint b);
        float   min(float a, float b);
        double  min(double a, double b);

      In GLSL 1.50, a function call such as:

        float f;
        min(f, 1);

      would be considered unambiguous because the double-precision version of
      min() didn't exist and the call matched only the single-precision
      version.  However, with double-precision, implicit conversions can be
      used to resolve to either the single- or double-precision versions.

      To resolve this issue, we provide a set of rules that can be used to
      resolve multiple candidates to a "best match".  The rules for
      determining a best match are similar to those for C++ function
      overloading, but not exactly the same.  Like C++, these rules compare
      the conversions required on an argument-by-argument basis.  A function
      prototype A is better than function prototype B if:

        - A is better than B for one or more arguments
        - B is better than A for no arguments

      If a single function prototype is better than all others, that one is
      used.  Otherwise, we get the same ambiguity error as on previous GLSL
      versions.

      As far as argument-by-argument comparisons go, the order of preference
      is:

        - favor exact matches
        - prefer "promotions" (float->double) to other conversions
        - prefer conversions from int/uint to float over similar conversion to
          double

      If none of the rules apply, one match is considered neither better nor
      worse than the other.

      With these rules, the "min(f,1)" example above resolves to the "float"
      version, as is the case in GLSL 1.50.  However, there are other cases
      where ambiguity remains.  For example, consider the prototypes:

        int f(uint x);
        int f(float x);

      With GLSL 1.50 rules, "f(3)" would match the floating-point version, as
      no implicit conversions existed from "int" to "uint".  With the new
      implicit conversions, both prototypes match and neither is preferred.
      Because of the ambiguity, "f(3)" would fail to compile with this
      extension enabled, but should still compile on implementations
      supporting this extension if the extension is not enabled in GLSL source
      code.

    (7) The function overloading rules described in this extension describe
        conversions between data types with different sizes, however all
        existing data types allowing implicit conversion (int, uint, float)
        are the same size?  Why do we specify these rules?

      RESOLVED:  This extension is specified at the same time as the related
      ARB_gpu_shader_fp64 and NV_gpu_shader5 extensions, which do provide such
      types.  The rules are specified all in one place here so we don't have
      to replicate and extend the rules in the other extensions.  It also
      provides the ability to automatically convert from signed to unsigned
      integer types, as in the C programming language.

    (8) Should we support textureGather() for rectangle textures
        (sampler2DRect)?  They aren't in ARB_texture_gather.

      RESOLVED:  Yes.

    (9) How does the input sample mask interact with the fixed-function
        SampleCoverage and SampleMask state?  Will samples be removed from the
        input mask if they would be eliminated by these masks in the
        per-fragment operations?

      UNRESOLVED.

    (10) Should we support reading patches as geometry shader inputs, and if
    so, where?

      RESOLVED:  Not in this extension.  This capability will be provided in
      NV_gpu_shader5.

    (11) Should we support per-sample interpolation of attributes?  If so,
         how?

      RESOLVED.  Yes.  When multisample rasterization is enabled, qualifying
      one or more fragment shader inputs with "sample" will force per-sample
      interpolation of those attributes.  If the same shader includes other
      fragment inputs not qualified with sample, those attributes may be
      interpolated per-pixel (i.e., all samples get the same values, likely
      evaluated at the pixel center).

    (12) Should we reserve "sample" as a keyword for per-sample interpolation
    qualifiers, or use something more obscure, such as "per_sample"?

      RESOLVED:  This extension uses "sample".

    (13) What should be the base data type for the bitCount(), findLSB(), and
         findMSB() functions -- signed or unsigned integers?

      RESOLVED:  These functions will return signed values, with -1 returned
      by findLSB/findMSB if no bit is found.  Note that the shading language
      supports implicit conversions of signed integers to unsigned, which
      makes it easy enough if an unsigned result is desired.

    (14) Why do EmitVertex() and EndPrimitive() begin with capitalized words
         while most of the other built-ins start with a lower-case (e.g.,
         emitVertex)?  Which precedent should the new per-vertex stream emit
         and end primitive functions follow?

      RESOLVED:  The inconsistency began with the original functions in
      EXT_geometry_shader4; the spec author can't recall the original reasons
      (if any).  Regardless, we decided to match the existing functions as
      closely as possible and use EmitStreamVertex() and EndStreamPrimitive().

    (15) How do the textureGather functions work with sRGB textures?

      RESOLVED:  Gamma-correction is applied to the texture source color
      before "gathering" and hence applies to all four components, unless the
      texture swizzle of the selected component is ALPHA in which case no
      gamma-correction is applied.

    (16) How should we support arrays of uniform blocks (i.e., multiple blocks
         in a group, each backed by a separate buffer object)?

      RESOLVED:  We will use instance names in the block definitions, which
      can be declared as regular arrays:

        uniform UniformData {
          vec4 stuff;
        } blocks[4];

      These four blocks used will be referred to as "block[0]" through
      "block[3]" in shader code, and "UniformData[0]" through "UniformData[3]"
      in the OpenGL API code.  The block member in this example will be
      referred to as "UniformData.stuff" in the API.  A similar approach was
      already adopted in GLSL 1.50, where geometry shaders supported arrays of
      input blocks that were treated similarly.  Since this spec depends on
      GLSL 1.50, little new spec language is required here.

    (17) What are instanced geometry shaders useful for?

      RESOLVED:  Instanced geometry shaders allow geometry programs that
      perform regular operations to run more efficiently.

      Consider a simple example of an algorithm that uses geometry shaders to
      render primitives to a cube map in a single pass.  Without instanced
      geometry shaders, the geometry shader to render triangles to the cube
      map would do something like:

        for (face = 0; face < 6; face++) {
          for (vertex = 0; vertex < 3; vertex++) {
            project vertex <vertex> onto face <face>, output position
            compute/copy attributes of emitted <vertex> to outputs
            output <face> to result.layer
            emit the projected vertex
          }
          end the primitive (next triangle)
        }

      This algorithm would output 18 vertices per input triangle, three for
      each cube face.  The six triangles emitted would be rasterized, one per
      face.  Geometry shaders that emit a large number of attributes have
      often posed performance challenges, since all the attributes must be
      stored somewhere until the emitted primitives.  Large storage
      requirements may limit the number of threads that can be run in parallel
      and reduce overall performance.

      Instanced geometry shaders allow this example to be restructured to run
      with six separate invocations, one per face.  Each invocation projects
      the triangle to only a single face (identified by the invocation number)
      and emits only 3 vertices.  The reduced storage requirements allow more
      geometry shader invocations to be run in parallel, with greater overall
      efficiency.

      Additionally, the total number of attributes that can be emitted by a
      single geometry shader invocation is limited.  However, for instanced
      geometry shaders, that limit applies to each of <N> invocations which
      allows for a larger total output.  For example, if the GL implementation
      supports only 1024 components of output per invocation, the 18-vertex
      algorithm above could emit no more than 56 components per vertex.  The
      same algorithm implemented as a 3-vertex 6-invocation geometry program
      could theoretically allow for 341 components per vertex.

    (18) Should EmitStreamVertex() and EndStreamPrimitive() accept a
         non-constant stream number?

      RESOLVED:  Not in this extension.  Requiring a constant stream number
      for each call simplifies code generation for the compiler.

    (19) Are there any restrictions on geometry shaders with multiple output
         streams?

      RESOLVED:  Yes, such geometry shaders are required to generate points;
      line strip and triangle strip outputs are not supported.

    (20) Since multi-stream geometry shaders only support points, why does
         EndStreamPrimitive() exist?  Neither it nor EndStream() does anything
         useful when emitting points.

      RESOLVED:  This function was added for completeness, and would be useful
      if the requirement for emitting points were lifted by a future
      extension.

    (21) Should we provide mechanisms allowing shaders to examine or set the
         bit representation of floating-point numbers?

      RESOLVED:  Yes, we will provide functions to convert single-precision
      floats to/from signed and unsigned 32-bit integers.  The
      ARB_gpu_shader_fp64 extension will provide similar functionality for
      double-precision floats.  We chose to adopt the Java naming convention
      here -- converting a single-precision float to/from a signed integer is
      accomplished by the functions floatBitsToInt() and intBitsToFloat().

      Note that this functionality has also been forked off into a separate
      extension (ARB_shader_bit_encoding) that can be exported on
      implementations capable of performing such conversions but not capable
      of the full feature set of this extension and/or OpenGL 4.0.

    (22) What is the "precise" qualifier good for?

      RESOLVED:  Like "invariant", "precise" provides some invariance
      guarantees is useful for certain algorithms.

      With an output position qualified as "invariant", we ensure that if the
      same geometry is processed by multiple shaders using the exact same
      code, it will be transformed in exactly the same way to ensure that we
      have no cracking or flickering in multi-pass algorithms using different
      shaders.

      With "precise", we ensure that an algorithm can be written to produce
      identical results on subtly different inputs.  For example, the order of
      vertices visible to a geometry or tessellation shader used to subdivide
      primitive edges might present an edge shared between two primitives in
      one direction for one primitive and the other direction for the adjacent
      primitive.  Even if the weights are identical in the two cases, there
      may be cracking if the computations are being done in an order-dependent
      manner.  If the position of a new vertex were provided by evaluation the
      function f() below with limited-precision floating-point math, it's not
      necessarily the case that f(a,b,c) == f(c,b,a) in the following code:

          float f(float x, float y, float z)
          {
            return (x + y) + z;
          }

      This function f() can be rewritten as follows with "precise" and a
      symmetric evaluation order to ensure that f(a,b,c) == f(c,b,a).

          float f(float x, float y, float z)
          {
            // Note that we intentionally compute "(x+z)" instead of "(x+y)"
            // here, because that value will be the same when <x> and <z>
            // are reversed.
            precise float result = (x + z) + y;
            return result;
          }

          (a + b) + c == (c + b) + a

      The "precise" qualifier will disable certain optimization and thus
      carries a performance cost.  The cost may be higher than "invariant",
      because "invariant" permits optimizations disallowed by "precise" as
      long as the compiler ensures that it always optimizes in the exact same
      manner.

    (23) What computations will be affected by the "precise" qualifier, and
         what computations aren't?

      RESOLVED:  We will ensure precise computation of any expressions within
      a single function used directly or indirectly to produce the value of a
      variable qualified as "precise".

      We chose not to provide this guarantee across function boundaries, even
      if the results of a function are used in the computation of an output
      qualified as "precise".  Algorithms requiring the use of "precise" may
      have a mix of computations, some required to be precise, some not.  This
      function boundary rule may serve to limit the amount of computation
      indirectly forced to be precise.

      Additionally, the subroutine rule permits non-precise sub-operations in
      a computation required to be precise.  For example, a shader might need
      to compute a "precise" position by taking a weighted average as in the
      following code:

        precise vec3 pos = (p[0]*w[0] + p[1]*w[1]) + (p[2]*w[2] + p[3]*w[3]);

      However, if the main precision requirement is that the same result be
      generated when <p> and <w> are reversed, the following code also gets
      the job done, even if posmad() is implemented with multiply-add
      operations.

        vec3 posmad(vec3 p0, float w0, vec3 p1w1) { return p0*w0+p1w1; }
        precise vec3 pos = (posmad(p[0], w[0], p[1]*w[1]) +
                            posmad(p[3], w[3], p[2]*w[2]));

      To generate precise results within a function, the function arguments
      and/or temporaries within the function body should be qualified as
      "precise" as needed.

      Note that when applying "precise" rules to assignments, indirect
      application of this rule applies on an assignment-by-assignment basis.
      In the following perverse example:

        float a,b,c,d,e,f;
        precise float g;
        f = a + b + c;
        ...
        f = c + d + e;
        g = f * 2.0;

      The first assignment to <f> need not be treated as "precise", since the
      value assigned will have no effect on the final value of the
      precise-qualified <g>.  The second assignment to <f> must be evaluated
      precisely.  The fact that one assignment to a variable needs to be
      treated as precise does not mean that the variable itself is implicitly
      treated as "precise".

    (24) Are "precise" qualifiers allowed on function arguments?  If so, what
         do they mean?  Can a return value for a function be declared as
         precise?

      RESOLVED:  Yes; the rules permit the use of "precise" on any variable
      declaration, including function arguments.  The code

        float f(precise in vec4 arg1, precise out vec4 arg2) { ... }

      specifies that any expressions used to assign values to <arg1> or <arg2>
      within f() will be evaluated as a precise manner.

      Expressions used to derive the value passed to the function f() as
      <arg1> will be treated as precise according to the normal rules.  The
      expression for <arg1> is treated as precise if and only if the function
      call is on the right-hand side of an assignment to a variable qualified
      as "precise" or is indirectly used in an assignment to such a variable.
      It is not automatically treated as precise just because the formal
      parameter <arg1> is qualified with "precise".

      For the purposes of this rule, variables passed as "out" parameters do
      not count as assignments.  Values assigned to an output parameter will
      not be evaluated precisely just because the caller provides a variable
      qualified as "precise".  When the output parameter itself is qualified
      as "precise", precise evaluation of that output is required within the
      callee.

      We chose not to permit function return values to be qualified as
      "precise", though we could have hypothetically allowed code such as:

        precise float f(float a, float b, float c) { return (a+b)+c; }

      To obtain a precise return value in such a case, use code such as:

        float f(float a, float b, float c)
        {
          precise float result = (a+b) + c;
          return result;
        }

    (25) How does texture gather interact with incomplete textures?

      RESOLVED:  For regular texture lookups, incomplete textures are
      considered to return a texel value with RGBA components of (0,0,0,1).
      For texture gather operations, each texel in the sampled footprint is
      considered to have RGBA components of (0,0,0,1).  When using the
      textureGather() function to select the R, G, or B component of an
      incomplete texture, (0,0,0,0) will be returned.  When selecting the A
      component, (1,1,1,1) will be returned.


Revision History

    Rev.    Date    Author    Changes
    ----  --------  --------  -----------------------------------------
    16    03/30/12  pbrown    Fix typo in language restricting the use of
                              EmitStreamVertex()/EndStreamPrimitive() to
                              programs with an output primitive type of
                              points, not an input type of points (bug 8371).

    15    10/17/11  pbrown    Fix prototypes for textureGather and
                              textureGatherOffset to use vec2 coordinates for
                              "2DRect" sampler versions (bug 7964).

    14    01/27/11  pbrown    Add further clarification on the interaction
                              of texture gather and incomplete textures (bug
                              7289).

    13    09/24/10  pbrown    Clarify the interaction of texture gather
                              with swizzle (bug 5910), fixing conflicts
                              between API and GLSL spec language.
                              Consolidate into one copy in the API
                              spec.

    12    03/23/10  pbrown    Update issues section, both fixing/numbering
                              existing issues and including other issues
                              that were left behind in NV_gpu_shader5 when the
                              specs were refactored.

    11    03/23/10  Jon Leech Describe <offset> to interpolateAtOffset
                              without implying it is a constant expression
                              (Bug 6026).

    10    03/07/10  pbrown    Fix typo in an output stream qualifier example.

     9    03/05/10  pbrown    Modify function overloading rules to remove
                              most preferences when converting between
                              two different types.  The only preferences
                              that remain are promoting "float" to "double"
                              over other conversions, and preferring
                              conversion of integers to "float" to converting
                              to "double" (bug 5938).

     8    01/29/10  pbrown    Update the spec to require that the minimum
                              value for MAX_PROGRAM_TEXTURE_GATHER_-
                              COMPONENTS is 4 (bug 5919).

     7    01/21/10  pbrown    Clarify the rules for determining a best match
                              if implicit conversions can result in multiple
                              matching function prototypes.  Modify the rules
                              to pick a best match by comparing pairs of
                              functions, and using any function deemed better
                              than any other choice.  Modify the argument
                              conversion preference rules for overloading to
                              disfavor "int" to "uint" conversions, for
                              backward compatibility with previous GLSL
                              versions.  Add some new discussion of the
                              choices involved to the issues section (bug
                              5938).

     6    01/14/10  pbrown    Minor wording updates from spec reviews.

     5    12/10/09  pbrown    Functionality updates from spec review:
                              Rename fmad to fma.  Fix error in spec
                              language for negative diffs in usubBorrow.

     4    12/10/09  pbrown    Convert from EXT to ARB.

     3    12/08/09  pbrown    Miscellaneous fixes from spec review:  Added
                              missing implementation constants for
                              interpolation offset range and granularity;
                              added explicit section to OpenGL spec describing
                              shader requested interpolation modifiers and
                              functions.  Clean up more dangling "ThreadID"
                              references.  General typo fixes and language
                              clarifications.

     2    10/01/09  pbrown    Renamed gl_ThreadID to gl_InvocationID.

     1              pbrown    Internal revisions.