Name

    NV_gpu_shader5

Name Strings

    GL_NV_gpu_shader5

Contact

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

Contributors

    Barthold Lichtenbelt, NVIDIA
    Chris Dodd, NVIDIA
    Eric Werness, NVIDIA
    Greg Roth, NVIDIA
    Jeff Bolz, NVIDIA
    Piers Daniell, NVIDIA
    Daniel Rakos, AMD
    Mathias Heyer, NVIDIA

Status

    Shipping.

Version

    Last Modified Date:         03/07/2017
    NVIDIA Revision:            11

Number

    OpenGL Extension #389
    OpenGL ES Extension #260

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.

    If implemented in OpenGL, OpenGL 3.2 and GLSL 1.50 are required.

    If implemented in OpenGL, ARB_gpu_shader5 is required.

    This extension interacts with ARB_gpu_shader5.

    This extension interacts with ARB_gpu_shader_fp64.

    This extension interacts with ARB_tessellation_shader.

    This extension interacts with NV_shader_buffer_load.

    This extension interacts with EXT_direct_state_access.

    This extension interacts with EXT_vertex_attrib_64bit and
    NV_vertex_attrib_integer_64bit.

    This extension interacts with OpenGL ES 3.1 (dated October 29th 2014).

    This extension interacts with OpenGL ES Shading Language 3.1 (revision 3).

    If implemented in OpenGL ES, OpenGL ES 3.1 and GLSL ES 3.10 are required.

    If implemented in OpenGL ES, OES/EXT_gpu_shader5 and EXT_shader_implicit-
    _conversions are required.

    This extension interacts with OES/EXT_tessellation_shader

    This extension interacts with OES/EXT_geometry_shader

Overview

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

      #extension GL_NV_gpu_shader5 : require     (or enable)

    This extension was developed concurrently with the ARB_gpu_shader5
    extension, and provides a superset of the features provided there.  The
    features common to both extensions are documented in the ARB_gpu_shader5
    specification; this document describes only the addition language features
    not available via ARB_gpu_shader5.  A shader that enables this extension
    via an #extension directive also implicitly enables the common
    capabilities provided by ARB_gpu_shader5.

    In addition to the capabilities of ARB_gpu_shader5, this extension
    provides a variety of new features for all shader types, including:

      * support for a full set of 8-, 16-, 32-, and 64-bit scalar and vector
        data types, including uniform API, uniform buffer object, and shader
        input and output support;

      * the ability to aggregate samplers into arrays, index these arrays with
        arbitrary expressions, and not require that non-constant indices be
        uniform across all shader invocations;

      * new built-in functions to pack and unpack 64-bit integer types into a
        two-component 32-bit integer vector;

      * new built-in functions to pack and unpack 32-bit unsigned integer
        types into a two-component 16-bit floating-point vector;

      * new built-in functions to convert double-precision floating-point
        values to or from their 64-bit integer bit encodings;

      * new built-in functions to compute the composite of a set of boolean
        conditions a group of shader threads;

      * vector relational functions supporting comparisons of vectors of 8-,
        16-, and 64-bit integer types or 16-bit floating-point types; and

      * extending texel offset support to allow loading texel offsets from
        regular integer operands computed at run-time, except for lookups with
        gradients (textureGrad*).

    This extension also provides additional support for processing patch
    primitives (introduced by ARB_tessellation_shader).
    ARB_tessellation_shader requires the use of a tessellation evaluation
    shader when processing patches, which means that patches will never
    survive past the tessellation pipeline stage.  This extension lifts that
    restriction, and allows patches to proceed further in the pipeline and be
    used

      * as input to a geometry shader, using a new "patches" layout qualifier;

      * as input to transform feedback;

      * by fixed-function rasterization stages, in which case the patches are
        drawn as independent points.

    Additionally, it allows geometry shaders to read per-patch attributes
    written by a tessellation control shader using input variables declared
    with "patch in".


New Procedures and Functions

    void Uniform1i64NV(int location, int64EXT x);
    void Uniform2i64NV(int location, int64EXT x, int64EXT y);
    void Uniform3i64NV(int location, int64EXT x, int64EXT y, int64EXT z);
    void Uniform4i64NV(int location, int64EXT x, int64EXT y, int64EXT z,
                       int64EXT w);
    void Uniform1i64vNV(int location, sizei count, const int64EXT *value);
    void Uniform2i64vNV(int location, sizei count, const int64EXT *value);
    void Uniform3i64vNV(int location, sizei count, const int64EXT *value);
    void Uniform4i64vNV(int location, sizei count, const int64EXT *value);

    void Uniform1ui64NV(int location, uint64EXT x);
    void Uniform2ui64NV(int location, uint64EXT x, uint64EXT y);
    void Uniform3ui64NV(int location, uint64EXT x, uint64EXT y, uint64EXT z);
    void Uniform4ui64NV(int location, uint64EXT x, uint64EXT y, uint64EXT z,
                       uint64EXT w);
    void Uniform1ui64vNV(int location, sizei count, const uint64EXT *value);
    void Uniform2ui64vNV(int location, sizei count, const uint64EXT *value);
    void Uniform3ui64vNV(int location, sizei count, const uint64EXT *value);
    void Uniform4ui64vNV(int location, sizei count, const uint64EXT *value);

    void GetUniformi64vNV(uint program, int location, int64EXT *params);


    (The following function is also provided by NV_shader_buffer_load.)

    void GetUniformui64vNV(uint program, int location, uint64EXT *params);


    (All of the following ProgramUniform* functions are supported if and only
     if implemented in OpenGL ES or EXT_direct_state_access is supported.)

    void ProgramUniform1i64NV(uint program, int location, int64EXT x);
    void ProgramUniform2i64NV(uint program, int location, int64EXT x,
                              int64EXT y);
    void ProgramUniform3i64NV(uint program, int location, int64EXT x,
                              int64EXT y, int64EXT z);
    void ProgramUniform4i64NV(uint program, int location, int64EXT x,
                              int64EXT y, int64EXT z, int64EXT w);
    void ProgramUniform1i64vNV(uint program, int location, sizei count,
                               const int64EXT *value);
    void ProgramUniform2i64vNV(uint program, int location, sizei count,
                               const int64EXT *value);
    void ProgramUniform3i64vNV(uint program, int location, sizei count,
                               const int64EXT *value);
    void ProgramUniform4i64vNV(uint program, int location, sizei count,
                               const int64EXT *value);

    void ProgramUniform1ui64NV(uint program, int location, uint64EXT x);
    void ProgramUniform2ui64NV(uint program, int location, uint64EXT x,
                               uint64EXT y);
    void ProgramUniform3ui64NV(uint program, int location, uint64EXT x,
                               uint64EXT y, uint64EXT z);
    void ProgramUniform4ui64NV(uint program, int location, uint64EXT x,
                               uint64EXT y, uint64EXT z, uint64EXT w);
    void ProgramUniform1ui64vNV(uint program, int location, sizei count,
                                const uint64EXT *value);
    void ProgramUniform2ui64vNV(uint program, int location, sizei count,
                                const uint64EXT *value);
    void ProgramUniform3ui64vNV(uint program, int location, sizei count,
                                const uint64EXT *value);
    void ProgramUniform4ui64vNV(uint program, int location, sizei count,
                                const uint64EXT *value);


New Tokens

    Returned by the <type> parameter of GetActiveAttrib, GetActiveUniform, and
    GetTransformFeedbackVarying:

        INT64_NV                                        0x140E
        UNSIGNED_INT64_NV                               0x140F

        INT8_NV                                         0x8FE0
        INT8_VEC2_NV                                    0x8FE1
        INT8_VEC3_NV                                    0x8FE2
        INT8_VEC4_NV                                    0x8FE3
        INT16_NV                                        0x8FE4
        INT16_VEC2_NV                                   0x8FE5
        INT16_VEC3_NV                                   0x8FE6
        INT16_VEC4_NV                                   0x8FE7
        INT64_VEC2_NV                                   0x8FE9
        INT64_VEC3_NV                                   0x8FEA
        INT64_VEC4_NV                                   0x8FEB
        UNSIGNED_INT8_NV                                0x8FEC
        UNSIGNED_INT8_VEC2_NV                           0x8FED
        UNSIGNED_INT8_VEC3_NV                           0x8FEE
        UNSIGNED_INT8_VEC4_NV                           0x8FEF
        UNSIGNED_INT16_NV                               0x8FF0
        UNSIGNED_INT16_VEC2_NV                          0x8FF1
        UNSIGNED_INT16_VEC3_NV                          0x8FF2
        UNSIGNED_INT16_VEC4_NV                          0x8FF3
        UNSIGNED_INT64_VEC2_NV                          0x8FF5
        UNSIGNED_INT64_VEC3_NV                          0x8FF6
        UNSIGNED_INT64_VEC4_NV                          0x8FF7
        FLOAT16_NV                                      0x8FF8
        FLOAT16_VEC2_NV                                 0x8FF9
        FLOAT16_VEC3_NV                                 0x8FFA
        FLOAT16_VEC4_NV                                 0x8FFB

    (If ARB_tessellation_shader is supported, the following enum is accepted
     by a new primitive.)

    Accepted by the <primitiveMode> parameter of BeginTransformFeedback:

        PATCHES


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

    Modify Section 2.6.1, Begin and End, p. 22

    (Extend language describing PATCHES introduced by ARB_tessellation_shader.
    It particular, add the following to the end of the description of the
    primitive type.)

    If a patch primitive is drawn, each patch is drawn separately as a
    collection of points, which each patch vertex definining a separate point.
    Extra vertices from an incomplete patch are never drawn.


    Modify Section 2.14.3, Vertex Attributes, p. 86

    (modify the second paragraph, p. 87) ... exceeds MAX_VERTEX_ATTRIBS.  For
    the purposes of this comparison, attribute variables of the type i64vec3,
    u64vec3, i64vec4, and u64vec4 count as consuming twice as many attributes
    as equivalent single-precision types.


    (extend the list of types in the first paragraph, p. 88)
    ... UNSIGNED_INT_VEC3, UNSIGNED_INT_VEC4, INT8_NV, INT8_VEC2_NV,
    INT8_VEC3_NV, INT8_VEC4_NV, INT16_NV, INT16_VEC2_NV, INT16_VEC3_NV,
    INT16_VEC4_NV, INT64_NV, INT64_VEC2_NV, INT64_VEC3_NV, INT64_VEC4_NV,
    UNSIGNED_INT8_NV, UNSIGNED_INT8_VEC2_NV, UNSIGNED_INT8_VEC3_NV,
    UNSIGNED_INT8_VEC4_NV, UNSIGNED_INT16_NV, UNSIGNED_INT16_VEC2_NV,
    UNSIGNED_INT16_VEC3_NV, UNSIGNED_INT16_VEC4_NV, UNSIGNED_INT64_NV,
    UNSIGNED_INT64_VEC2_NV, UNSIGNED_INT64_VEC3_NV, UNSIGNED_INT64_VEC4_NV,
    FLOAT16_NV, FLOAT16_VEC2_NV, FLOAT16_VEC3_NV, or FLOAT16_VEC4_NV.


    Modify Section 2.14.4, Uniform Variables, p. 89

    (modify third paragraph, p. 90) ... uniform variable storage for a vertex
    shader.  A scalar or vector uniform with with 64-bit integer components
    will consume no more than 2<n> components, where <n> is 1 for scalars, and
    the component count for vectors.  A link error is generated ...

    (add to Table 2.13, p. 96)

      Type Name Token           Keyword
      --------------------      ----------------
      INT8_NV                   int8_t
      INT8_VEC2_NV              i8vec2
      INT8_VEC3_NV              i8vec3
      INT8_VEC4_NV              i8vec4
      INT16_NV                  int16_t
      INT16_VEC2_NV             i16vec2
      INT16_VEC3_NV             i16vec3
      INT16_VEC4_NV             i16vec4
      INT64_NV                  int64_t
      INT64_VEC2_NV             i64vec2
      INT64_VEC3_NV             i64vec3
      INT64_VEC4_NV             i64vec4
      UNSIGNED_INT8_NV          uint8_t
      UNSIGNED_INT8_VEC2_NV     u8vec2
      UNSIGNED_INT8_VEC3_NV     u8vec3
      UNSIGNED_INT8_VEC4_NV     u8vec4
      UNSIGNED_INT16_NV         uint16_t
      UNSIGNED_INT16_VEC2_NV    u16vec2
      UNSIGNED_INT16_VEC3_NV    u16vec3
      UNSIGNED_INT16_VEC4_NV    u16vec4
      UNSIGNED_INT64_NV         uint64_t
      UNSIGNED_INT64_VEC2_NV    u64vec2
      UNSIGNED_INT64_VEC3_NV    u64vec3
      UNSIGNED_INT64_VEC4_NV    u64vec4
      FLOAT16_NV                float16_t
      FLOAT16_VEC2_NV           f16vec2
      FLOAT16_VEC3_NV           f16vec3
      FLOAT16_VEC4_NV           f16vec4

    (modify list of commands at the bottom of p. 99)

      void Uniform{1,2,3,4}{i64,ui64}NV(int location, T value);
      void Uniform{1,2,3,4}{i64,ui64}vNV(int location, T value);

    (insert after fourth paragraph, p. 100) The Uniform*i64{v}NV and
    Uniform*ui64{v}NV commands will load <count> sets of one to four 64-bit
    signed or unsigned integer values into a uniform location defined as a
    64-bit signed or unsigned integer scalar or vector types.


    (modify "Uniform Buffer Object Storage", p. 102, adding two bullets after
     the last "Members of type", and modifying the subsequent bullet)

     * Members of type int8_t, int16_t, and int64_t are extracted from a
       buffer object by reading a single byte, short, or int64-typed value at
       the specified offset.

     * Members of type uint8_t, uint16_t, and uint64_t are extracted from a
       buffer object by reading a single ubyte, ushort, or uint64-typed value
       at the specified offset.

     * Members of type float16_t are extracted from a buffer object by reading
       a single half-typed value at the specified offset.

     * Vectors with N elements with basic data types of bool, int, uint,
       float, double, int8_t, int16_t, int64_t, uint8_t, uint16_t, uint64_t,
       or float16_t are extracted as N values in consecutive memory locations
       beginning at the specified offset, with components stored in order with
       the first (X) component at the lowest offset. The GL data type used for
       component extraction is derived according to the rules for scalar
       members above.


    Modify Section 2.14.6, Varying Variables, p. 106

    (modify third paragraph, p. 107) ... For the purposes of counting input
    and output components consumed by a shader, variables declared as vectors,
    matrices, and arrays will all consume multiple components.  Each component
    of variables declared as 64-bit integer scalars or vectors, will be
    counted as consuming two components.

    (add after the bulleted list, p. 108) For the purposes of counting the
    total number of components to capture, each component of outputs declared
    as 64-bit integer scalars or vectors will be counted as consuming two
    components.


    Modify Section 2.15.1, Geometry Shader Input Primitives, p. 118

    (add new qualifier at the end of the section, p. 120)

    Patches (patches)

    Geometry shaders that operate on patches are valid for the PATCHES
    primitive type.  The number of vertices available to each program
    invocation is equal to the vertex count of the variable-size patch, with
    vertices presented to the geometry shader in the order specified in the
    patch.


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

    (add to the end of "Geometry Shader Inputs", p. 123)

    Geometry shaders also support built-in and user-defined per-primitive
    inputs.  The following built-in inputs, not replicated per-vertex and not
    contained in gl_in[], are supported:

      * The variable gl_PatchVerticesIn is filled with the number of the
        vertices in the input primitive.

      * The variables gl_TessLevelOuter[] and gl_TessLevelInner[] are arrays
        holding outer and inner tessellation levels of an input patch.  If a
        tessellation control shader is active, the tessellation levels will be
        taken from the corresponding outputs of the tessellation control
        shader.  Otherwise, the default levels provided as patch parameters
        are used.  Tessellation level values loaded in these variables will be
        prior to the clamping and rounding operations performed by the
        primitive generator as described in Section 2.X.2 of
        ARB_tessellation_shader.  For triangular tessellation,
        gl_TessLevelOuter[3] and gl_TessLevelInner[1] will be undefined.  For
        isoline tessellation, gl_TessLevelOuter[2], gl_TessLevelOuter[3], and
        both values in gl_TessLevelInner[] are undefined.

    Additionally, a geometry shader with an input primitive type of "patches"
    may declare per-patch input variables using the qualifier "patch in".
    Unlike per-vertex inputs, per-patch inputs do not correspond to any
    specific vertex in the input primitive, and are not indexed by vertex
    number.  Per-patch inputs declared as arrays have multiple values for the
    input patch; similarly declared per-vertex inputs would indicate a single
    value for each vertex in the output patch.  User-defined per-patch input
    variables are filled with corresponding per-patch output values written by
    the tessellation control shader.  If no tessellation control shader is
    active, all such variables are undefined.

    Per-patch input variables and the built-in inputs "gl_PatchVerticesIn",
    "gl_TessLevelOuter[]", and "gl_TessLevelInner[]" are supported only for
    geometry shaders with an input primitive type of "patches".  A program
    will fail to link if any such variable is used in a geometry shader with a
    input primitive type other than "patches".


    Modify Section 2.19, Transform Feedback, p. 130

    (add to Table 2.14, p. 131)

      Transform Feedback
      primitiveMode               allowed render primitive modes
      ----------------------      ---------------------------------
      PATCHES                     PATCHES


    (modify first paragraph, p. 131) ... <primitiveMode> is one of TRIANGLES,
    LINES, POINTS, or PATCHES and specifies the type of primitives that will
    be recorded into the buffer objects bound for transform feedback (see
    below). ...

    (modify last paragraph, p. 131 and first paragraph, p. 132, adding patch
    support, and dealing with capture of 8- and 16-bit components)

    When an individual point, line, triangle, or patch primitive reaches the
    transform feedback stage ...  When capturing line, triangle, and patch
    primitives, all attributes ...  For multi-component varying variables or
    varying array elements, the individual components are written in order.
    For variables with 8- or 16-bit fixed- or floating-point components,
    individual components will be converted to and stored as equivalent values
    of type "int", "uint", or "float".  The value for any attribute specified
    ...

    (modify next-to-last paragraph, p. 132) ... is not incremented.  If
    transform feedback receives a primitive that fits in the remaining space
    after such an overflow occurs, that primitive may or may not be recorded.
    Primitives that fail to fit in the remaining space are never recorded.


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

    None.

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.15, Shader and Program Queries, p. 332

    (add to the first list of commands, p. 337)

      void GetUniformi64vNV(uint program, int location, int64EXT *params);
      void GetUniformui64vNV(uint program, int location, uint64EXT *params);


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_NV_gpu_shader5 : <behavior>

    where <behavior> is as specified in section 3.3.

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

      #define GL_NV_gpu_shader5         1

    If the features of this extension are enabled by an #extension directive,
    shading language features documented in the ARB_gpu_shader5 extension will
    also be provided.


    Modify Section 3.6, Keywords, p. 15

    (add the following to the list of reserved keywords)

    int8_t              i8vec2          i8vec3          i8vec4
    int16_t             i16vec2         i16vec3         i16vec4
    int32_t             i32vec2         i32vec3         i32vec4
    int64_t             i64vec2         i64vec3         i64vec4
    uint8_t             u8vec2          u8vec3          u8vec4
    uint16_t            u16vec2         u16vec3         u16vec4
    uint32_t            u32vec2         u32vec3         u32vec4
    uint64_t            u64vec2         u64vec3         u64vec4
    float16_t           f16vec2         f16vec3         f16vec4
    float32_t           f32vec2         f32vec3         f32vec4
    float64_t           f64vec2         f64vec3         f64vec4

    (note:  the "float64_t" and "f64vec*" types are available if and only if
    ARB_gpu_shader_fp64 is also supported)


    Modify Section 4.1, Basic Types, p. 18

    (add to the basic "Transparent Types" table, p. 18)

      Types       Meaning
      --------    ----------------------------------------------------------
      int8_t      an 8-bit signed integer
      i8vec2      a two-component signed integer vector (8-bit components)
      i8vec3      a three-component signed integer vector (8-bit components)
      i8vec4      a four-component signed integer vector (8-bit components)

      int16_t     a 16-bit signed integer
      i16vec2     a two-component signed integer vector (16-bit components)
      i16vec3     a three-component signed integer vector (16-bit components)
      i16vec4     a four-component signed integer vector (16-bit components)

      int32_t     a 32-bit signed integer
      i32vec2     a two-component signed integer vector (32-bit components)
      i32vec3     a three-component signed integer vector (32-bit components)
      i32vec4     a four-component signed integer vector (32-bit components)

      int64_t     a 64-bit signed integer
      i64vec2     a two-component signed integer vector (64-bit components)
      i64vec3     a three-component signed integer vector (64-bit components)
      i64vec4     a four-component signed integer vector (64-bit components)

      uint8_t     a 8-bit unsigned integer
      u8vec2      a two-component unsigned integer vector (8-bit components)
      u8vec3      a three-component unsigned integer vector (8-bit components)
      u8vec4      a four-component unsigned integer vector (8-bit components)

      uint16_t    a 16-bit unsigned integer
      u16vec2     a two-component unsigned integer vector (16-bit components)
      u16vec3     a three-component unsigned integer vector (16-bit components)
      u16vec4     a four-component unsigned integer vector (16-bit components)

      uint32_t    a 32-bit unsigned integer
      u32vec2     a two-component unsigned integer vector (32-bit components)
      u32vec3     a three-component unsigned integer vector (32-bit components)
      u32vec4     a four-component unsigned integer vector (32-bit components)

      uint64_t    a 64-bit unsigned integer
      u64vec2     a two-component unsigned integer vector (64-bit components)
      u64vec3     a three-component unsigned integer vector (64-bit components)
      u64vec4     a four-component unsigned integer vector (64-bit components)

      float16_t   a single 16-bit floating-point value
      f16vec2     a two-component floating-point vector (16-bit components)
      f16vec3     a three-component floating-point vector (16-bit components)
      f16vec4     a four-component floating-point vector (16-bit components)

      float32_t   a single 32-bit floating-point value
      f32vec2     a two-component floating-point vector (32-bit components)
      f32vec3     a three-component floating-point vector (32-bit components)
      f32vec4     a four-component floating-point vector (32-bit components)

      float64_t   a single 64-bit floating-point value
      f64vec2     a two-component floating-point vector (64-bit components)
      f64vec3     a three-component floating-point vector (64-bit components)
      f64vec4     a four-component floating-point vector (64-bit components)


    Modify Section 4.1.3, Integers, p. 20

    (add after the first paragraph of the section, p. 20)

    Variables with the types "int8_t", "int16_t", and "int64_t" represent
    signed integer values with exactly 8, 16, or 64 bits, respectively.
    Variables with the type "uint8_t", "uint16_t", and "uint64_t" represent
    unsigned integer values with exactly 8, 16, or 64 bits, respectively.
    Variables with the type "int32_t" and "uint32_t" represent signed and
    unsigned integer values with 32 bits, and are equivalent to "int" and
    "uint" types, respectively.


    (modify the grammar, p. 21, adding "L" and "UL" suffixes)

      integer-suffix:  one of

        u U l L ul UL

    (modify next-to-last paragraph, p. 21) ... When the suffix "u" or "U" is
    present, the literal has type <uint>.  When the suffix "l" or "L" is
    present, the literal has type <int64_t>.  When the suffix "ul" or "UL" is
    present, the literal has type <uint64_t>.  Otherwise, the type is
    <int>. ...


    Modify Section 4.1.4, Floats, p. 22

    (insert after second paragraph, p. 22)

    Variables of type "float16_t" represent floating-point using exactly 16
    bits and are stored using the 16-bit floating-point representation
    described in the OpenGL Specification.  Variables of type "float32_t"
    and "float64_t" represent floating-point with 32 or 64 bits, and are
    equivalent to "float" and "double" types, respectively.


    Modify Section 4.1.7, Samplers, p. 23

    (modify 1st paragraph of the section, deleting the restriction requiring
    constant indexing of sampler arrays) ... 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. ...

    (remove the additional restriction added by ARB_gpu_shader5 making a
    similar edit requiring uniform indexing across shader invocations for
    defined results.  NV_gpu_shader5 has no such limitation.)


    Modify Section 4.1.10, Implicit Conversions, p. 27

    (modify table of implicit conversions)

                                Can be implicitly
        Type of expression        converted to
        --------------------    -----------------------------------------
        int                     uint, int64_t, uint64_t, float, double(*)
        ivec2                   uvec2, i64vec2, u64vec2, vec2, dvec2(*)
        ivec3                   uvec3, i64vec3, u64vec3, vec3, dvec3(*)
        ivec4                   uvec4, i64vec4, u64vec4, vec4, dvec4(*)

        int8_t   int16_t        int, int64_t, uint, uint64_t, float, double(*)
        i8vec2   i16vec2        ivec2, i64vec2, uvec2, u64vec2, vec2, dvec2(*)
        i8vec3   i16vec3        ivec3, i64vec3, uvec3, u64vec3, vec3, dvec3(*)
        i8vec4   i16vec4        ivec4, i64vec4, uvec4, u64vec4, vec4, dvec4(*)

        int64_t                 uint64_t, double(*)
        i64vec2                 u64vec2, dvec2(*)
        i64vec3                 u64vec3, dvec3(*)
        i64vec4                 u64vec4, dvec4(*)

        uint                    uint64_t, float, double(*)
        uvec2                   u64vec2, vec2, dvec2(*)
        uvec3                   u64vec3, vec3, dvec3(*)
        uvec4                   u64vec4, vec4, dvec4(*)

        uint8_t  uint16_t       uint, uint64_t, float, double(*)
        u8vec2   u16vec2        uvec2, u64vec2, vec2, dvec2(*)
        u8vec3   i16vec3        uvec3, u64vec3, vec3, dvec3(*)
        u8vec4   i16vec4        uvec4, u64vec4, vec4, dvec4(*)

        uint64_t                double(*)
        u64vec2                 dvec2(*)
        u64vec3                 dvec3(*)
        u64vec4                 dvec4(*)

        float                   double(*)
        vec2                    dvec2(*)
        vec3                    dvec3(*)
        vec4                    dvec4(*)

        float16_t               float, double(*)
        f16vec2                 vec2, dvec2(*)
        f16vec3                 vec3, dvec3(*)
        f16vec4                 vec4, dvec4(*)

        (*) if ARB_gpu_shader_fp64 is supported

    (Note:  Expressions of type "int32_t", "uint32_t", "float32_t", and
    "float64_t" are treated as identical to those of type "int", "uint",
    "float", and "double", respectively.  Implicit conversions to and from
    these explicitly-sized types are allowed whenever conversions involving
    the equivalent base type are allowed.)


    (modify second paragraph of the section) No implicit conversions are
    provided to convert from unsigned to signed integer types, from
    floating-point to integer types, from higher-precision to lower-precision
    types, from 8-bit to 16-bit types, or between matrix types.  There are no
    implicit array or structure conversions.

    (add before the final paragraph of the section, p. 27)

    (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
    int8_t value to a uint16_t value, both values can be implicitly converted
    to uint, uint64_t, float, and double.  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.  If operands can be
    converted to both 32- and 64-bit versions of the chosen base data type,
    the 32-bit version is used.


    Modify Section 4.3.4, Inputs, p. 31

    (modify third paragraph of section, p. 31, allowing explicitly-sized
    types) ... Vertex shader inputs variables can only be signed and unsigned
    integers, floats, doubles, explicitly-sized integers and floating-point
    values, vectors of any of these types, and matrices.  ...

    (modify edits done in ARB_tessellation_shader adding support for "patch
    in", allowing for geometry shaders as well) Additionally, tessellation
    evaluation and geometry shaders support per-patch input variables declared
    with the "patch in" qualifier.  Per-patch input ...


    (modify third paragraph, p. 32) ... Fragment inputs can only be signed and
    unsigned integers, floats, doubles, explicitly-sized integers and
    floating-point values, vectors of any of these types, matrices, or arrays
    or structures of these.  Fragment inputs declared as signed or unsigned
    integers, doubles, 64-bit floating-point values, including vectors,
    matrices, or arrays derived from those types, must be qualified as "flat".


    Modify Section 4.3.6, Outputs, p. 33

    (modify third paragraph of the section, p. 33) ... They can only be signed
    and unsigned integers, floats, doubles, explicitly-sized integers and
    floating-point values, vectors of any of these types, matrices, or arrays
    or structures of these.

    (modify last paragraph, p. 33) ...  Fragment outputs can only be signed
    and unsigned integers, floats, explicitly-sized integers and
    floating-point values with 32 or fewer bits, vectors of any of these
    types, or arrays of these.  Doubles, 64-bit integers or floating-point
    values, vectors or arrays of those types, matrices, and structures cannot
    be output. ...


    Modify Section 4.3.8.1, Input Layout Qualifiers, p. 37

    (add to the list of qualifiers for geometry shaders, p. 37)

      layout-qualifier-id:
        ...
        triangles_adjacency
        patches

    (modify the "size of input arrays" table, p. 38)

        Layout          Size of Input Arrays
      ------------      --------------------
        patches         gl_MaxPatchVertices

    (add paragraph below that table, p. 38)

    When using the input primitive type "patches", the geometry shader is used
    to process a set of patches with vertex counts that may vary from patch to
    patch.  For the purposes of input array sizing, patches are treated as
    having a vertex count fixed at the implementation-dependent maximum patch
    size, gl_MaxPatchVertices.  If a shader reads an input corresponding to a
    vertex not found in the patch being processed, the values read are
    undefined.


    Modify Section 5.4.1, Conversion and Scalar Constructors, p. 49

    (add after first list of constructor examples)

    Similar constructors are provided to convert to and from explicitly-sized
    scalar data types, as well:

      float(uint8_t)      // converts an 8-bit uint value to a float
      int64_t(double)     // converts a double value to a 64-bit int
      float64_t(int16_t)  // converts a 16-bit int value to a 64-bit float
      uint16_t(bool)      // converts a Boolean value to a 16-bit uint

    (replace final two paragraphs, p. 49, and the first paragraph, p. 50,
    using more general language)

    When constructors are used to convert any floating-point type to any
    integer type, the fractional part of the floating-point value is dropped.
    It is undefined to convert a negative floating point value to an unsigned
    integer type.

    When a constructor is used to convert any integer or floating-point type
    to bool, 0 and 0.0 are converted to false, and non-zero values are
    converted to true.  When a constructor is used to convert a bool to any
    integer or floating-point type, false is converted to 0 or 0.0, and true
    is converted to 1 or 1.0.

    Constructors converting between signed and unsigned integers with the same
    bit count always preserve the bit pattern of the input.  This will change
    the value of the argument if its most significant bit is set, converting a
    negative signed integer to a large unsigned integer, or vice versa.


    Modify Section 5.9, Expressions, p. 57

    (modify bulleted list as follows, adding support for expressions with
    64-bit integer 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 arithmetic binary operators add (+), subtract (-), multiply (*), and
      divide (/) operate on 32-bit integer, 64-bit integer, and floating-point
      scalars, vectors, and matrices.  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.  ...

    * The operator modulus (%) operate on 32- and 64-bit 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.  ...

    * The arithmetic unary operators negate (-), post- and pre-increment and
      decrement (-- and ++) operate on 32-bit integer, 64-bit integer, and
      floating-point values (including vectors and matrices). ...

    * The relational operators greater than (>), less than (<), and less than
      or equal (<=) operate only on scalar 32-bit integer, 64-bit integer, and
      floating-point expressions.  The result is scalar Boolean.  The
      fundamental type of the two operands must match, either as specified, or
      after one of the implicit type conversions specified in Section 4.1.10.
      ...

    * The equality operators equal (==), and not equal (!=) operate only on
      scalar 32-bit integer, 64-bit integer, and floating-point expressions.
      The result is scalar Boolean.  The fundamental type of the two operands
      must match, either as specified, or after one of the implicit type
      conversions specified in Section 4.1.10.  ...


    Modify Section 6.1, Function Definitions, p. 63

    (ARB_gpu_shader5 adds a set of rules for defining whether implicit
    conversions for one matching function definition are better or worse than
    those for another.  These comparisons are done argument by argument.
    Extend the edits made by ARB_gpu_shader5 to add several new rules for
    comparing implicit conversions for a single argument, corresponding to the
    new data types introduced by this extension.)

     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 a conversion from a signed integer, unsigned
           integer, or floating-point type to a similar type having a larger
           number of bits is better a match not involving another conversion.
           The set of conversions qualifying under this rule are:

            source types                destination types
            -----------------           -----------------
            int8_t, int16_t             int, int64_t
            int                         int64_t
            uint8_t, uint16_t           uint, uint64_t
            uint                        uint64_t
            float16_t                   float
            float                       double

       3.  A match involving one conversion in rule 2 is better than a match
           involving another conversion in rule 2 if:

            (a) both conversions start with the same type and the first
                conversion is to a type with a smaller number of bits (e.g.,
                converting from int16_t to int is preferred to converting
                int16_t to int64_t), or

            (b) both conversions end with the same type and the first
                conversion is from a type with a larger number of bits (e.g.,
                converting an "out" parameter from int16_t to int is preferred
                to convering from int8_t to int).

       4. A match involving an implicit conversion from any integer type to
          float is better than a match involving an implicit conversion from
          any integer type to double.


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

    (NOTE:  These edits are written against the re-organized section in the
    ARB_tessellation_shader specification.)

    (add to the list of built-ins inputs for geometry shaders) In the geometry
    language, built-in input and output variables are intrinsically declared
    as:

      in int gl_PatchVerticesIn;
      patch in float gl_TessLevelOuter[4];
      patch in float gl_TessLevelInner[2];

    ...

    The input variable gl_PatchVerticesIn behaves as in the identically-named
    tessellation control and evaluation shader inputs.

    The input variables gl_TessLevelOuter[] and gl_TessLevelInner[] behave as
    in the identically-named tessellation evaluation shader inputs.


    Modify Chapter 8, Built-in Functions, p. 81

    (add to description of generic types, last paragraph of p. 69) ...  Where
    the input arguments (and corresponding output) can be int64_t, i64vec2,
    i64vec3, or i64vec4, <genI64Type> is used as the argument.  Where the
    input arguments (and corresponding output) can be uint64_t, u64vec2,
    u64vec3, or u64vec4, <genU64Type> is used as the argument.


    Modify Section 8.3, Common Functions, p. 84

    (add support for 64-bit integer packing and unpacking functions)

    Syntax:

      int64_t  packInt2x32(ivec2 v);
      uint64_t packUint2x32(uvec2 v);

      ivec2  unpackInt2x32(int64_t v);
      uvec2  unpackUint2x32(uint64_t v);

    The functions packInt2x32() and packUint2x32() return a signed or unsigned
    64-bit integer obtained by packing the components of a two-component
    signed or unsigned integer vector, respectively.  The first vector
    component specifies the 32 least significant bits; the second component
    specifies the 32 most significant bits.

    The functions unpackInt2x32() and unpackUint2x32() return a signed or
    unsigned integer vector built from a 64-bit signed or unsigned integer
    scalar, respectively.  The first component of the vector contains the 32
    least significant bits of the input; the second component consists the 32
    most significant bits.


    (add support for 16-bit floating-point packing and unpacking functions)

    Syntax:

      uint      packFloat2x16(f16vec2 v);
      f16vec2   unpackFloat2x16(uint v);

    The function packFloat2x16() returns an unsigned integer obtained by
    interpreting the components of a two-component 16-bit floating-point
    vector as integers according to OpenGL Specification, and then packing the
    two 16-bit integers into a 32-bit unsigned integer.  The first vector
    component specifies the 16 least significant bits of the result; the
    second component specifies the 16 most significant bits.

    The function unpackFloat2x16() returns a two-component vector with 16-bit
    floating-point components obtained by unpacking a 32-bit unsigned integer
    into a pair of 16-bit values, and interpreting those values as 16-bit
    floating-point numbers according to the OpenGL Specification.  The first
    component of the vector is obtained from the 16 least significant bits of
    the input; the second component is obtained from the 16 most significant
    bits.


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

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

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

      genI64Type doubleBitsToInt64(genDType value);
      genU64Type doubleBitsToUint64(genDType 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:

      genDType int64BitsToDouble(genI64Type value);
      genDType uint64BitsToDouble(genU64Type value);


    (add functions to evaluate predicates over groups of threads)

    Syntax:

      bool anyThreadNV(bool value);
      bool allThreadsNV(bool value);
      bool allThreadsEqualNV(bool value);

    Implementations of the OpenGL Shading Language may, but are not required,
    to run multiple shader threads for a single stage as a SIMD thread group,
    where individual execution threads are assigned to thread groups in an
    undefined, implementation-dependent order.  Algorithms may benefit from
    being able to evaluate a composite of boolean values over all active
    threads in the thread group.

    The function anyThreadNV() returns true if and only if <value> is true for
    at least one active thread in the group.  The function allThreadsNV()
    returns true if and only if <value> is true for all active threads in the
    group.  The function allThreadsEqualNV() returns true if <value> is the
    same for all active threads in the group; the result of
    allThreadsEqualNV() will be true if and only if anyThreadNV() and
    allThreadsNV() would return the same value.

    Since these functions depends on the values of <value> in an undefined
    group of threads, the value returned by these functions is largely
    undefined.  However, anyThreadNV() is guaranteed to return true if <value>
    is true, and allThreadsNV() is guaranteed to return false if <value> is
    false.

    Since implementations are generally not required to combine threads into
    groups, simply returning <value> for anyThreadNV() and allThreadsNV() and
    returning true for allThreadsEqualNV() is a legal implementation of these
    functions.


    Modify Section 8.6, Vector Relational Functions, p. 90

    (modify the first paragraph, p. 90, adding support for relational
    functions operating on explicitly-sized types)

    Relational and equality operators (<, <=, >, >=, ==, !=) are defined (or
    reserved) to operate on scalars and produce scalar Boolean results.  For
    vector results, use the following built-in functions.  In the definitions
    below, the following terms are used as placeholders for all vector types
    for a given fundamental data type:

        placeholder     fundamental types
        -----------     ------------------------------------------------
        bvec            bvec2, bvec3, bvec4

        ivec            ivec2, ivec3, ivec4, i8vec2, i8vec3, i8vec4,
                        i16vec2, i16vec3, i16vec4, i64vec2, i64vec3, i64vec4

        uvec            uvec2, uvec3, uvec4, u8vec2, u8vec3, u8vec4,
                        u16vec2, u16vec3, u16vec4, u64vec2, u64vec3, u64vec4

        vec             vec2, vec3, vec4, dvec2(*), dvec3(*), dvec4(*),
                        f16vec2, f16vec3, f16vec4

        (*) only if ARB_gpu_shader_fp64 is supported

    In all cases, the sizes of the input and return vectors for any
    particular call must match.


    Modify Section 8.7, Texture Lookup Functions, p. 91

    (modify text for textureOffset() functions, p. 94, allowing non-constant
    offsets)

    Do a texture lookup as in texture but with offset added to the (u,v,w)
    texel coordinates before looking up each texel.  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_TEXEL_OFFSET_EXT or
    greater than MAX_PROGRAM_TEXEL_OFFSET_EXT, the offset applied to the
    texture coordinates is undefined.  Note that offset does not apply to the
    layer coordinate for texture arrays. This is explained in detail in
    section 3.9.9 of the OpenGL Specification (Version 3.2, Compatibility
    Profile), where offset is (delta_u, delta_v, delta_w).  Note that texel
    offsets are also not supported for cube maps.

    (Note:  This lifting of the constant offset restriction also applies to
    texelFetchOffset, p. 95, textureProjOffset, p. 95, textureLodOffset,
    p. 96, textureProjLodOffset, p. 96.)


    (modify the description of the textureGradOffset() functions, p. 97,
    preserving the restriction on constant offsets)

    Do a texture lookup with both explicit gradient and offset, as described
    in textureGrad and textureOffset.  For these functions, the offset value
    must be a constant expression.  A limited range of offset values are
    supported; the minimum and maximum offset values are
    implementation-dependent and given by MIN_PROGRAM_TEXEL_OFFSET and
    MAX_PROGRAM_TEXEL_OFFSET, respectively.


    (modify the description of the textureProjGradOffset() functions,
    p. 98, preserving the restriction on constant offsets)

    Do a texture lookup projectively and with explicit gradient as described
    in textureProjGrad, as well as with offset, as described in textureOffset.
    For these functions, the offset value must be a constant expression.  A
    limited range of offset values are supported; the minimum and maximum
    offset values are implementation-dependent and given by
    MIN_PROGRAM_TEXEL_OFFSET and MAX_PROGRAM_TEXEL_OFFSET, respectively.

    (modify the description of the textureGatherOffsets() functions,
     added in ARB_gpu_shader5, to remove the restriction on constant offsets)

    The textureGatherOffsets() functions operate identically ...
    selecting the texel T_i0_j0 of that footprint.  The specified values in
    <offsets> need not be constant.  A limited range of ...

    Modify Section 9, Shading Language Grammar, p. 92

    !!! TBD !!!


GLX Protocol

    TBD

Interactions with OpenGL ES 3.1

    If implemented in OpenGL ES, NV_gpu_shader5 acts as a superset
    of functionality provided by OES_gpu_shader5.

    A shader that enables this extension
    via an #extension directive also implicitly enables the common
    capabilities provided by OES_gpu_shader5.

    Replace references to ARB_gpu_shader5 with OES_gpu_shader5 and
    EXT_shader_implicit_conversions (as appropriate).
    Replace references to ARB_geometry_shader with OES/EXT_geometry_shader.
    Replace references to ARB_tessellation_shader with OES/EXT_tessellation_shader.

    Replace references to int64EXT and uint64EXT with int64 and uint64,
    respectively.

    The specification should be edited as follows to include new
    ProgramUniform* functions.

    (modify the ProgramUniform* language)

    The following commands:

        ....
        void ProgramUniform{1,2,3,4}{i64,ui64}NV
            (uint program int location, T value);
        void ProgramUniform{1,2,3,4}{i64,ui64}vNV
            (uint program, int location, const T *value);

    operate identically to the corresponding command where "Program" is
    deleted from the name (and extension suffixes are dropped or updated
    appropriately) except, rather than updating the currently active program
    object, these "Program" commands update the program object named by the
    <program> parameter.  ...

    Changes to Section 2.6.1 "Begin and End" don't apply.

    Disregard introduction of 64bit -integer or -floating point vertex
    attribute types.

Interactions with OpenGL ES Shading Language 3.10, revision 3

    If implemented in GLSL ES, NV_gpu_shader5 acts as a superset
    of functionality provided by OES_gpu_shader5 and
    EXT_shader_implicit_conversions.

    A shader that enables this extension via an #extension directive
    also implicitly enables the common capabilities provided by
    OES_gpu_shader5 and EXT_shader_implicit_conversions.

    Replace references to ARB_tessellation_shader with OES/EXT_tessellation_shader.

    Implicit conversion between GLSL ES types are introduced by
    EXT_shader_implicit_conversions instead of ARB_gpu_shader5.

    Disregard the notion of 'double' types as vertex shader inputs.

    Section 4.1.7.2 "Images"
        Remove the third sentence restricts
        access to arrays of images to constant integral expression.

        This essentially leaves it to the 'dynamically uniform integral
        expressions' default as OES_gpu_shader5 introduced.

    Modify Section 4.3.9 "Interface Blocks", as modified OES_gpu_shader5

        NV_gpu_shader5 also lifts OES_gpu_shader5 restrictions with
        regard to indexing into arrays of uniforms blocks and shader
        storage blocks.

        Change sentence
        "All indices used to index a shader storage block array must be
         constant integral expressions. A uniform block array can only
         be indexed with a dynamically uniform integral expression,
         otherwise results are undefined." into

        "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."

        Indexing into arrays  of shader storage blocks defaults to
        'dynamically uniform integral expressions'.

    Changes to Section 4.3.9, p.48 "Interface Blocks"

        Replace the sentence
        "All indices used to index a shader storage block array must be
         constant integral expressions. A uniform block array can only
         be indexed with a dynamically uniform integral expression,
         otherwise results are undefined."
        with
        "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."

    4.4.1.1 "Compute Shader Inputs" change

        "layout-qualifier-id:
            local_size_x = integer-constant
            local_size_y = integer-constant
            local_size_z = integer-constant" into

        "layout-qualifier-id:
            local_size_x = integer-constant-expression
            local_size_y = integer-constant-expression
            local_size_z = integer-constant-expression"

    Section 4.4.1.gs "Geometry Shader Inputs" change

        "<layout-qualifier-id>
            ...
            invocations = integer-constant"  into

        "<layout-qualifier-id>
            ...
            invocations = integer-constant-expression"

    Section 4.4.2 "Output Layout Qualifiers" change

        "layout-qualifier-id:
            location = integer-constant" into

        "layout-qualifier-id:
            location = integer-constant-expression"

    Section 4.4.2.ts "Tessellation Control Outputs" change

        "layout-qualifier-id
            vertices = integer-constant"  into

        "layout-qualifier-id:
            vertices = integer-constant-expression"

    Section 4.4.3 "Uniform Variable Layout Qualifiers" change

        "layout-qualifier-id:
            location = integer-constant" into

        "layout-qualifier-id:
            location = integer-constant-expression"

    Section 4.4.4 "Uniform and Shader Storage Block Layout Qualifiers" change

        "layout-qualifier-id:
            ...
            binding = integer-constant" into

        "layout-qualifier-id:
            ...
            binding = integer-constant-expression"

    Section 4.4.5 "Opaque Uniform Layout Qualifiers" change

        "layout-qualifier-id:
            binding = integer-constant" into

        "layout-qualifier-id:
            binding = integer-constant-expression"

    Change sentence
        "A link-time error will result if two shaders in a program
         specify different integer-constant bindings for the same
         opaque-uniform name." into

         "A link-time error will result if two shaders in a program
          specify different bindings for the same opaque-uniform
          name."

    Section 4.4.6 "Atomic Counter Layout Qualifiers" change

        "layout-qualifier-id:
            binding = integer-constant
             offset = integer-constant" into

        "layout-qualifier-id:
            binding = integer-constant-expression
             offset = integer-constant-expression"

    Section 4.4.7 "Format Layout Qualifiers" change

        "layout-qualifier-id:
            ...
            binding = integer-constant" into

        "layout-qualifier-id:
            ...
            binding = integer-constant-expression"

    Section 4.7.3 "Precision Qualifiers"

    After "Literal constants do not have precision qualifiers." add
    "Neither do explicitly sized types such as int8_t, uint32_t,
    float16_t etc."

Dependencies on OES_gpu_shader5

    In addition to allowing arbitrary indexing arrays of samplers, this
    extension also lifts OES_gpu_shader5 restrictions for indexing
    arrays of images and shader storage blocks. Additionally, it allows
    usage of 'integer-constant-expressions' for layout qualifiers that
    formerly took 'integer-constant'.

    In Section 'Overview': change the bullet point

    "* the ability to aggregate samplers into arrays...."

    to

    "* the ability to index into arrays of samplers, uniforms and shader
       storage blocks with arbitrary expressions, and not require that
       non-constant indices be uniform across all shader invocations."

    "* the ability to index into arrays of images using dynamically
       uniform integers."

    "* the ability to use 'integer-constant-expressions' in place of
       'integer-constant' for layout qualifiers."

Dependencies on OES/EXT_tessellation_shader and OpenGL ES 3.2

    If implemented in OpenGL ES 3.1 or earlier and
    OES/EXT_tessellation_shader is not supported, language introduced by
    this extension describing processing patches in geometry shaders,
    transform feedback, and rasterization should be removed.

    If implemented in OpenGL ES 3.2 or implemented in
    OpenGL ES 3.1 and OES/EXT_tessellation_shader is supported:
      
    It is legal to send patches past the tessellation stage -- the
    following language from OES/EXT_tessellation_shader is removed:

      Patch primitives are not supported by pipeline stages below the
      tessellation evaluation shader.
      
    It is legal to use a tessellation control shader without a tessellation
    evaluation shader.
    
    Remove from the bullet list describing reasons for link failure below the
    LinkProgram command on p. 70 (as modified by OES/EXT_tessellation_shader):

      * the program is not separable and contains no object to form a
      tessellation evaluation shader; or
        
    Modify section 11.1.2.1, "Output Variables" on p. 262 (as modified
    by the OES/EXT_geometry_shader extension):

    Into the paragraph starting with 
     "Each program object can specify a set of output variables from one
      shader to be recorded in transform feedback mode..."
    
    Insert after the tesselation evaluation shader bullet point: 
      * tesselation control shader 
        
       
    Modify section 11.1.3.11, "Validation" to replace the bullet point
    starting with "One but not both of the tessellation..." on p. 271

      * the tessellation evaluation but not tessellation control stage 
        has an active program with corresponding executable shader.


    Modify section 11.1ts, "Tessellation" 

    Replace
      "Tessellation is considered active if and only if the active
      program object or program pipeline object includes both a
      tessellation control shader and a tessellation evaluation shader."
    with
      "Tessellation is considered active if and only if the active
      program object or program pipeline object includes a tessellation
      control shader."

    Replace
      "An INVALID_OPERATION error is generated by any command that
      transfers vertices to the GL if the current program state has one
      but not both of a tessellation control shader and tessellation
      evaluation shader."
    with
      "An INVALID_OPERATION error is generated by any command that
      transfers vertices to the GL if the current program state has a
      tessellation evaluation shader but not a tessellation control
      shader."
      
    Modify section 12.1.2 "Transform Feedback Primitive Capture"
    
    Replace the second paragraph of the section on p. 274 (as modified
    by OES/EXT_tessellation_shader):

    The data captured in transform feedback mode depends on the active
    programs on each of the shader stages. If a program is active for the
    geometry shader stage, transform feedback captures the vertices of each
    primitive emitted by the geometry shader. Otherwise, if a program is
    active for the tessellation evaluation shader stage, transform feedback
    captures each primitive produced by the tessellation primitive generator,
    whose vertices are processed by the tessellation evaluation shader.
    Otherwise, if a program is active for the tessellation control shader stage,
    transform feedback captures each output patch of that stage.
    Otherwise, transform feedback captures each primitive processed by the
    vertex shader.

    Modify the second paragraph following ResumeTransformFeedback on p. 277
    (as modified by OES/EXT_tessellation_shader):

    When transform feedback is active and not paused ... If a tessellation
    or geometry shader is active, the type of primitive emitted
    by that shader is used instead of the <mode> parameter passed to drawing
    commands for the purposes of this error check. If tessellation
    and geometry shaders are both active, the output primitive
    type of the geometry shader will be used for the purposes of this error.
    Any primitive type may be used while transform feedback is paused.


    Modify section 13.3, "Points"

    After 
      "The point size is determined by the last active stage before the
      rasterizer:"
      
    Add a new bullet point to the list, between the
    tessellation evaluation shader and the vertex shader:

      * the tessellation control shader, if active and no tessellation
        evaluation shader is active;
    
Dependencies on OES/EXT_geometry_shader

    If implemented in GLSL ES and OES/EXT_geometry_shader is not supported,
    disregard all changes to geometry shader related functionality.

Dependencies on ARB_gpu_shader5

    This extension also incorporates all the changes to the OpenGL Shading
    Language made by ARB_gpu_shader5; enabling this extension by a #extension
    directive in shader code also enables all features of ARB_gpu_shader5 as
    though the shader code has also declared

      #extension GL_ARB_gpu_shader5 : enable

    The converse is not true; implementations supporting both extensions
    should not provide the shading language features in this extension if
    shader code #extension directives enable only ARB_gpu_shader5.

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

Dependencies on ARB_gpu_shader_fp64

    This extension and ARB_gpu_shader_fp64 both provide support for shading
    language variables with 64-bit components.  If both extensions are
    supported, the various edits describing this new support should be
    combined.

    If ARB_gpu_shader_fp64 is not supported, the following edits should be
    removed:

     * language adding the data types "float64_t", "f64vec2", "f64vec3", and
       "f64vec4";

     * language allowing implicit conversions of various types to double,
       dvec2, dvec3, or dvec4; and

     * the built-in functions doubleBitsToInt64(), doubleBitsToUint64(),
       int64BitsToDouble(), and uint64BitsToDouble().

Dependencies on ARB_tessellation_shader

    If ARB_tessellation_shader is not supported, language introduced by this
    extension describing processing patches in geometry shaders, transform
    feedback, and rasterization should be removed.

    If this extension and ARB_tessellation_shader are supported, it is legal
    to send patches past the tessellation stage -- the following language from
    ARB_tessellation_shader is removed:

      Patch primitives are not supported by pipeline stages below the
      tessellation evaluation shader.  If there is no active program object or
      the active program object does not contain a tessellation evaluation
      shader, the error INVALID_OPERATION is generated by Begin (or vertex
      array commands that implicitly call Begin) if the primitive mode is
      PATCHES.

Dependencies on NV_shader_buffer_load

    If NV_shader_buffer_load is supported, that specification should be edited
    as follows, to allow pointers to dereference the new data types added by
    this extension.

    Modify "Section 2.20.X, Shader Memory Access" from NV_shader_buffer_load.

    (add rules for loads of variables having the new data types from this
    extension to the list of bullets following "When a shader dereferences a
    pointer variable")

    - Data of type "int8_t," "int16_t", "int32_t", and "int64_t" are read
      from or written to memory as a single 8-, 16-, 32-, or 64-bit signed
      integer value at the specified GPU address.

    - Data of type "uint8_t," "uint16_t", "uint32_t", and "uint64_t" are read
      from or written to memory as a single 8-, 16-, 32-, or 64-bit unsigned
      integer value at the specified GPU address.

    - Data of type "float16_t", "float32_t", and "float64_t" are read from or
      written to memory as a single 16-, 32-, or 64-bit floating-point value
      at the specified GPU address.

Dependencies on EXT_direct_state_access

    If EXT_direct_state_access is supported, that specification should be
    edited as follows to include new ProgramUniform* functions.

    (modify the ProgramUniform* language)

    The following commands:

        ....
        void ProgramUniform{1,2,3,4}{i64,ui64}NV
            (uint program int location, T value);
        void ProgramUniform{1,2,3,4}{i64,ui64}vNV
            (uint program, int location, const T *value);

    operate identically to the corresponding command where "Program" is
    deleted from the name (and extension suffixes are dropped or updated
    appropriately) except, rather than updating the currently active program
    object, these "Program" commands update the program object named by the
    <program> parameter.  ...

Dependencies on EXT_vertex_attrib_64bit and NV_vertex_attrib_integer_64bit

    The EXT_vertex_attrib_64bit extension provides the ability to specify
    64-bit floating-point vertex attributes in a GLSL vertex shader and the
    specify the values of these attributes via the OpenGL API.  To
    successfully compile vertex shaders with fp64 input variables, is
    necessary to include

      #extension GL_EXT_vertex_attrib_64bit : enable

    in the shader text.

    However, this extension is considered to enable 64-bit
    floating-point and integer inputs. Provided EXT_vertex_attrib_64bit
    and NV_vertex_attrib_integer_64bit are supported, including the
    following code in a vertex shader

      #extension GL_NV_gpu_shader5 : enable

    will enable 64-bit floating-point or integer input variables whose
    values would be specified using the OpenGL API mechanisms found in
    the EXT_vertex_attrib_64bit and NV_vertex_attrib_integer_64bit
    extensions.


Errors

    None.

New State

    None.

New Implementation Dependent State

    None.

Issues

    (1) What implicit conversions are supported by this extension on top of
        those provided by related extensions?

      RESOLVED:  ARB_gpu_shader5 and ARB_gpu_shader_fp64 provide new implicit
      conversions from "int" to "uint", and from "int", "uint", and "float" to
      "double".

      This extension provides integer types of multiple sizes and supports
      implicit conversions from small integer types to 32- or 64-bit integer
      types of the same signedness, as well as float and double.  It also
      provides floating-point types of multiple sizes and supports implicit
      conversions from smaller to larger types.  Additionally, it supports
      conversion from 64-bit integer types to double.

    (2) How do these implicit conversions impact binary operators?

      RESOLVED:  For binary operators, we prefer converting to a common type
      that is as close as possible in size and type to the original
      expression.

    (3) How do these implicit conversions impact function overloading rules?

      RESOLVED:  We extend the preference rules in ARB_gpu_shader5 to account
      for the new data types, adding rules to:

        * favor new "promotions" in integer/floating point types (previously,
          the only promotion was float-to-double)

        * for promotions, favor conversion to the type closer in size (e.g.,
          prefer converting from int16_t to int over converting to int64_t)

    (4) What should be done to distinguish between 32- and 64-bit integer
        constants?

      RESOLVED:  We will use "L" and "UL" to identify signed and unsigned
      64-bit integer constants; the use of "L" matches a similar ("long")
      suffix in the C programming language.  C leaves the size of integer
      types implementation-dependent, and many implementations require an "LL"
      suffix to declare 64-bit integer constants.  With our size definitions,
      "L" will be considered sufficient to make an integer constant 64-bit.

    (5) Should provide support for vertex attributes with 64-bit components,
        and if so, how should the support be provided in the OpenGL API?

      RESOLVED:  Yes, this seems like useful functionality, particularly for
      applications wanting to provide double-precision or 64-bit integer data
      to shaders performing computations on such types.  We provide
      VertexAttribL* entry points for 64-bit components in the separate
      EXT_vertex_attrib_64bit and NV_vertex_attrib_64bit extensions, which
      should be supported on all implementations supporting this extension.

    (6) Should we allow vertex attributes with 8- or 16-bit components in the
        shading language, and if so, how does it interact with the OpenGL API?

      RESOLVED:  Yes, but we will use existing APIs to specify such
      attributes, which already typically allow 8- and 16-bit components on
      the API side.  Vertex attribute components (other than 64-bit ones)
      specified by the API will be converted from the type specified in the
      vertex attribute commands to the component type of the attribute.  For
      floating-point values, that may involve 16-to-32 bit conversion or vice
      versa.  For integer types, that may involve dropping all but the least
      significant bits of attribute components.

    (7) Should we support uniforms with double or 64-bit attribute types, and
        if so, how?  Should we support uniforms with <32-bit components, and
        if so, how?

      RESOLVED:  We will support uniforms of all component types, either in a
      buffer object (via OpenGL 3.1 or ARB_uniform_buffer_object) or in
      storage associated with the program.

      When uniforms are stored in buffer object, they are stored using their
      native data types according to the pre-existing packing and layout
      rules.  Those rules were already written to be able to accommodate both
      the larger and smaller new data types.

      Uniforms stored in program objects are loaded with Uniform* APIs.  There
      are no pre-existing uniform APIs accepting doubles or other "long"
      types, so there was no clear need to add an extra "L" to the name to
      distinguish from other APIs like we do with VertexAttribL* APIs.

      Uniforms with 8- and 16- bit components are loaded with the "larger"
      Uniform*{i,ui,f} APIs; it didn't seem worth it to add numerous entry
      points to the APIs to handle all those new types.

    (8) How do the uniform loading commands introduced by this extension
        interact similar commands added by NV_shader_buffer_load?

      RESOLVED:  NV_shader_buffer_load provided the command Uniformui64NV to
      load pointer uniforms with a single 64-bit unsigned integer.  This
      extension provides vectors of 64-bit unsigned integers, so we needed
      Uniform{2,3,4}ui64NV commands.  We chose to provide a Uniform1ui64NV
      command, which will be functionally equivalent to Uniformui64NV.

    (9) How will transform feedback work for capturing variables with double
        or 64-bit components?  Should we support transform feedback on
        variables with components with fewer than 32 bits?

      RESOLVED:  Transform feedback will support variables with any component
      size.  Components with fewer than 32-bits are converted to their
      equivalent 32-bit types.

      For doubles and variables with 64-bit components, each component
      captured will count as 64-bit values and occupy two components for the
      purpose of component counting rules.  This could be a problem for the
      SEPARATE_ATTRIBS mode, since the minimum component limit is four, which
      would not be sufficient to capture a dvec3 or dvec4.  However,
      implementations supporting this extension should also be able to support
      ARB_transform_feedback3, which extends INTERLEAVED_ATTRIBS mode to
      capture vertex attribute values interleaved into multiple buffers.  That
      functionality effectively obsoletes the SEPARATE_ATTRIBS mode, since it
      is a functional superset.

      We considered support for capturing 8- and 16-bit values directly, which
      had a number of problems.  First, full byte addressing might impose both
      alignment issues (e.g., capturing a uint8_t followed by a float might
      misalign the float) and additional hardware implementation burdens.  One
      other option would be to pack multiple values into a 32-bit integer
      (e.g., f16vec2 would be packed with .x in the LSBs and .y in the MSBs).
      This could work, even with word addressing, but would require padding
      for odd sizes (e.g., f16vec2 padded to two words, with the second word
      holding only .z).  It would also have endianness issues; packed values
      would look like arrays of the corresponding smaller type on
      little-endian systems, but not on big-endian ones.

    (10) What precision will be used for computation, storage, and inter-stage
         transfer of 8- and 16-bit component data types?

      RESOLVED:  The components may be considered to occupy a full 32 bits for
      the purposes of input/output component count limits.  8- and 16-bit
      values should, however, be passed at that precision.

    (11) Is the new support for non-constant texel offsets completely
         orthogonal?

      RESOLVED:  No.  Non-constant offsets are not supported for the existing
      functions textureGradOffset() and textureProjGradOffset().

    (12) Should we provide functions like intBitsToFloat() that operate on
         16-bit floating-point values?

      RESOLVED:  Not in this extension.  Such conversions can be performed
      using the following code:

        uint16_t float16BitsToUint16(float16_t v)
        {
          return uint16_t(packFloat2x16(f16vec2(v, 0));
        }

        float16_t uint16BitsToFloat16(uint16_t v)
        {
          return unpackFloat2x16(uint(v)).x;
        }

    (13) Should we provide distinct sized types for 32-bit integers and
         floats, and 64-bit floats?  Should we provide those types as aliases
         for existing unsized types?  Or should we provide no such types at
         all?

      RESOLVED:  We will provide sized versions of these types, which are
      defined as completely equivalent to unsized types according to the
      following table:

        unsized type     sized types
        -------------    ---------------
        int              int32_t
        uint             uint32_t
        float            float32_t
        double           float64_t

      Vector types with sized and unsized components have equivalent
      relationships.

      Note that the nominally "unsized" data types in the GLSL 1.30 spec are
      actually sized.  The specification explicitly defines signed and unsized
      integers (int, uint) to be 32-bit values.  It also defines
      floating-point values to "match the IEEE single precision floating-point
      definition for precision and dynamic range", which are also 32-bit
      values.

      This type equivalence has minor implications on function overloading:

        * You can't declare separate versions of a function with an "int"
          argument in one version and an "int32_t" argument in another.

        * Because there is no implicit conversion between equivalent types, we
          will get an exact match if an argument is declared with one type
          (e.g., "int") in the caller and a textually different but equivalent
          type ("int32_t") in the function.

      Note that the type equivalence also applies to API data type queries.
      For example, the type INT will be returned for a variable declared as
      "int32_t".

    (14) What are functions like anyThreadNV() and allThreadsNV() good for?

      NRESOLVED:  If an implementation performs SIMD thread execution,
      divergent branching may result in reduced performance if the "if" and
      "else" blocks of an "if" statement are executed sequentially.  For
      example, an algorithm may have both a "fast path" that performs a
      computation quickly for a subset of all cases and a "fast path" that
      performs a computation quickly but correctly.  When performing SIMD
      execution, code like the following:

        if (condition) {
          result = do_fast_path(...);
        } else {
          result = do_slow_path(...);
        }

      may end up executing *both* the fast and slow paths for a SIMD thread
      group if <condition> diverges, and may execute more slowly than simply
      executing the slow path unconditionally.  These functions allow code
      like:

        if (allThreadsNV(condition)) {
          result = do_fast_path(...);
        } else {
          result = do_slow_path(...);
        }

      that executes the fast path if and only if it can be used for *all*
      threads in the group.  For thread groups where <condition> diverges,
      this algorithm would unconditionally run the slow path, but would never
      run both in sequence.

      There may be other cases where "voting" across shader invocations may be
      useful.  Note that we provide no control over how shader invocations may
      be packed within a SIMD thread group, unlike various "compute" APIs
      (CUDA, OpenCL).

    (15) Can the 64-bit uniform APIs be used to load values for uniforms of
         type "bool", "bvec2", "bvec3", or "bvec4"?

      RESOLVED:  No.  OpenGL 2.0 and beyond did allow "bool" variable to be
      set with Uniform*i* and Uniform*f APIs, and OpenGL 3.0 extended that
      support to Uniform*ui* for orthogonality.  But it seems pointless to
      extended this capability forward to 64-bit Uniform APIs as well.

    (19) The ARB_tessellation_shader extension adds support for patch
         primitives that might survive to the transform feedback stage.  How
         are such primitives captured?

      RESOLVED:  If patch primitives survive to the transform feedback stage,
      they are recorded on a patch-by-patch basis.  Incomplete patches are not
      recorded.  As with other primitive types, if the transform feedback
      buffers do not contain enough space to capture an entire patch, no
      vertices are recorded.

      Note that the only way to get patch primitives all the way to transform
      feedback is to have tessellation evaluation and geometry shaders
      disabled; the output streams from both of those shader stages are
      collections of points, lines, or triangles.

    (20) Previous transform feedback allowed capturing only fixed-size
         primitives; this extension supports variable-sized patches.  What
         interactions does this functionality have with transform feedback
         buffer overflow?

      RESOLVED:  With fixed-size point, line, or triangle primitives, once any
      primitive fails to be recorded due to insufficient space, all subsequent
      primitives would also fail.  With variable-size patch primitives, the
      transform feedback stage might first receive a large patch that doesn't
      fit, followed by a smaller patch that could squeeze into the remaining
      space.

      To allow for different types of implementation of this extension without
      requiring special-case handling of this corner case, we've chosen to
      leave this behavior undefined -- the smaller patch may or may not be
      recorded.


Revision History

    Rev.    Date    Author    Changes
    ----  --------  --------  -----------------------------------------
    11    03/07/17  mheyer    Update OpenGL ES interactions to clarify
                              that using a tessellation control shader
                              without a tessellation evaluation shader
                              is legal, and PATCHES can be sent past the
                              tessellation stage.

    10    04/16/16  mheyer    Add OpenGL ES interactions (written before
                              revision 9, but not published)

     9    02/19/16  pbrown    Clarify that non-constant offset vectors are
                              supported in textureGatherOffsets().

     8    09/11/14  pbrown    Fix incorrect implicit conversions, which
                              follow the general pattern of little->big
                              and int->uint->float.  Thanks to Daniel
                              Rakos, author of similar functionality in
                              the AMD_gpu_shader_int64 spec.

     7    11/08/10  pbrown    Fix typos in description of packFloat2x16 and
                              unpackFloat2x16.

     6    03/23/10  pbrown    Update overview, dependencies, remove references
                              to old extension names.  Extend the function
                              overloading prioritization rules from
                              ARB_gpu_shader5 to account for new data types.
                              Major overhaul of the issues section to match
                              the refactoring done to produce ARB specs.

     5    03/08/10  pbrown    Add interaction with EXT_vertex_attrib_64bit and
                              NV_vertex_attrib_integer_64bit; enabling this
                              extension automatically enables 64-bit floating-
                              point and integer vertex inputs.

     4    03/01/10  pbrown    Fix prototype for GetUniformui64vNV.

     3    01/14/10  pbrown    Fix with updated enum assignments.

     2    12/08/09  pbrown    Add explicit component counting rules for
                              64-bit integer attributes similar to those
                              in the ARB_gpu_shader_fp64 spec.

     1              pbrown    Internal revisions.