xref: /third_party/skia/third_party/externals/opengl-registry/extensions/EXT/EXT_gpu_shader5.txt

Name

    EXT_gpu_shader5

Name Strings

    GL_EXT_gpu_shader5

Contact

    Jon Leech (oddhack 'at' sonic.net)
    Daniel Koch, NVIDIA (dkoch 'at' nvidia.com)

Contributors

    Daniel Koch, NVIDIA (dkoch 'at' nvidia.com)
    Pat Brown, NVIDIA (pbrown 'at' nvidia.com)
    Jesse Hall, Google
    Maurice Ribble, Qualcomm
    Bill Licea-Kane, Qualcomm
    Graham Connor, Imagination
    Ben Bowman, Imagination
    Jonathan Putsman, Imagination
    Marcin Kantoch, Mobica
    Slawomir Grajewski, Intel
    Contributors to ARB_gpu_shader5

Notice

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

    Portions Copyright (c) 2013-2014 NVIDIA Corporation.

Status

    Complete.

Version

    Last Modified Date: March 27, 2015
    Revision: 12

Number

    OpenGL ES Extension #178

Dependencies

    OpenGL ES 3.1 and OpenGL ES Shading Language 3.10 are required.

    This specification is written against the OpenGL ES 3.1 (March 17,
    2014) and OpenGL ES 3.10 Shading Language (March 17, 2014)
    Specifications.

    This extension interacts with EXT_geometry_shader.

Overview

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

      #extension GL_EXT_gpu_shader5 : require     (or enable)

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

      * support for indexing into arrays of opaque types (samplers,
        and atomic counters) using dynamically uniform integer expressions;

      * support for indexing into arrays of images and shader storage blocks
        using only constant integral expressions;

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

      * 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;

      * extending the textureGather() built-in functions provided by
        OpenGL ES Shading Language 3.10:

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

New Procedures and Functions

    None

New Tokens

    None

Additions to the OpenGL ES 3.1 Specification

    Add to the end of section 8.13.2, "Coordinate Wrapping and Texel
    Selection":

    ... texture source color of (0,0,0,1) for all four source texels.

    The textureGatherOffsets built-in shader functions 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.


Additions to the OpenGL ES Shading Language 3.10 Specification

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

      #extension GL_EXT_gpu_shader5 : <behavior>

    where <behavior> is as specified in section 3.4.

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

      #define GL_EXT_gpu_shader5        1


    Modifications to Section 3.7 (Keywords)

    Remove "precise" from the list of reserved keywords and add it to the
    list of keywords.

    Remove the last paragraph from section 3.9.3 "Dynamically Uniform
    Expressions" (starting "The definition is not used in this version...")


    Add to the introduction to section 4.1.7, "Opaque Types" on p. 26:

    When aggregated into arrays within a shader, opaque types can only be
    indexed with a dynamically uniform integral expression (see section
    3.9.3) unless otherwise noted; otherwise, results are undefined.


    Replace the first paragraph of section 4.1.7.1, "Samplers" (removing the
    second sentence) on p. 27:

    Sampler types (e.g., sampler2D) are opaque types, declared and behaving
    as described above for opaque types.

    Sampler variables are ...



    Modify Section 4.3.9 "Interface Blocks", as modified by
    EXT_geometry_shader and EXT_shader_io_blocks:

    (modify the paragraph starting "For uniform or shader storage blocks
    declared as an array", removing the requirement for indexing uniform
    blocks using constant expressions)

    For uniform or shader storage blocks declared as an array, each
    individual array element corresponds to a separate buffer object bind
    range, backing one instance of the block. As the array size indicates
    the number of buffer objects needed, uniform and shader storage block
    array declarations must specify an array size. 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.


    Add new section 4.9gs5 before section 4.10 "Order of Qualification":

    4.9gs5 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 8.3, Common Functions, p. 104

    (add support for floating-point multiply-add)

    Syntax:

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

    Computes and returns a * b + c.

    In uses where the return value is eventually consumed by a variable
    declared as precise:

    * fma() is considered a single operation, whereas the expression
      "a*b + c" consumed by a variable declared precise is considered two
      operations.
    * The precision of fma() can differ from the precision of the expression
      "a*b + c".
    * fma() will be computed with the same precision as any other fma()
      consumed by a precise variable, giving invariant results for the same
      input values of a, b, and c.

    Otherwise, in the absence of precise consumption, there are no special
    constraints on the number of operations or difference in precision
    between fma() and the expression "a*b + c".


    Modify the table of functions in section 8.9.3 "Texture Gather
    Functions", changing the "Description" column for the existing
    textureGatherOffset functions on p. 127:

    Description

        Perform a texture gather operation as in textureGather offset by
        <offset> as described in textureOffset, except that the <offset> can
        be variable (non-constant) and the implementation-dependent minimum
        and maximum offset values are given by the values of
        MIN_PROGRAM_TEXTURE_GATHER_OFFSET and
        MAX_PROGRAM_TEXTURE_GATHER_OFFSET, respectively.


    Add new textureGatherOffsets functions to the same table, on p. 127:

    Syntax

        gvec4 textureGatherOffsets(gsampler2D sampler, vec2 P,
                                   ivec2 offsets[4] [, int comp])
        gvec4 textureGatherOffsets(gsampler2DArray sampler, vec3 P,
                                   ivec2 offsets[4] [, int comp])
        vec4 textureGatherOffsets(sampler2DShadow sampler, vec2 P,
                                  float refZ, ivec2 offsets[4])
        vec4 textureGatherOffsets(sampler2DArrayShadow sampler, vec3 P,
                                  float refZ, ivec2 offsets[4])

    Description

        Operate identically to textureGatherOffset except that <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
        <offsets> as a (u,v) coordinate offset to <coord>, identifying the
        four-texel linear footprint, and then selecting texel (i0,j0) of
        that footprint. The specified values in <offsets> must be constant
        integral expressions.

New Implementation Dependent State

    None.

Issues

    Note: These issues apply specifically to the definition of the
    EXT_gpu_shader5 specification, which is based on the OpenGL extension
    ARB_gpu_shader5 as updated in OpenGL 4.x. Resolved issues from
    ARB_gpu_shader5 have been removed, but some remain applicable to this
    extension. ARB_gpu_shader5 can be found in the OpenGL Registry.

    (1) What functionality was removed relative to ARB_gpu_shader5?

      - Instanced geometry support (moved into EXT_geometry_shader)
      - Implicit conversions (moved to EXT_shader_implicit_conversions)
      - Interactions with features not supported by the underlying
        ES 3.1 API and Shading Language, including:
        * interactions with ARB_gpu_Shader_fp64 and NV_gpu_shader, including
          support for double-precision in implicit conversions and function
          overload resolution
        * multiple vertex streams (these require ARB_transform_feedback3)
        * textureGather built-in variants for cube map array and rectangle
          texture samples.
        * shading language function overloading rules involving the type
          double
      - Functionality already in OpenGL ES 3.00, including packing and
        unpacking of 16-bit types and converting floating-point values to or
        from their integer bit encodings.
      - Functionality already in OpenGL ES 3.10, including
        * splitting and building floating-point numbers from a significand and
          exponent, integer bitfield manipulation, and packing and unpacking
          vectors of 8-bit fixed-point data types.
        * a subset of the textureGather and textureGatherOffset builtins
          (but some textureGather builtins remain in this extension).
      - Functionality already in OES_sample_variables, including support for
        reading a mask of covered samples in a fragment shader.
      - Functionality already in OES_shader_multisample_interpolation,
        including support for interpolating a fragment shader input at a
        programmable offset relative to the pixel center, a programmable
        sample number, or at the centroid.
      - MAX_PROGRAM_TEXTURE_GATHER_COMPONENTS (Issue 9).

    (2) What functionality was changed and added relative to
        ARB_gpu_shader5?

      - Support for indexing into arrays of samplers with extended to all
        opaque types, and the description of allowed indices was rewritten
        in terms of dynamically uniform expressions, as was done when
        ARB_gpu_shader5 was promoted into OpenGL 4.0.
      - The only remaining API interaction is an increase in a
        minium-maximum value, so no "Changes to the OpenGL ES Specification"
        sections are included above.
      - arrays of images and shader storage blocks can only be indexed
        with constant integral expressions.

    (3) What should the rules on GLSL suffixing be?

    RESOLVED: "precise" is not a reserved keyword in ESSL 3.00, but it is
    a keyword in GLSL 4.40. ESSL 3.10 updated the reserved keyword list
    to include all keywords used or reserved in GLSL 4.40 (but not otherwise
    used in ES) and thus we can use "precise" in this spec by moving it
    from the reserved keywords section. See bug 11179.

    (4) Are changes to the "Order of Qualification" section needed?

    RESOLVED. No. ESSL 3.10 relaxes the ordering constraints similarly to
    GLSL 4.40. And thus there is no need for modifications to section 4.7
    in 3.00 (4.10 in 3.10) in this extension.

    (5) Are any more changes needed to the descriptions of texture gather?

    Probably not. Bug 11109 suggests cleanup to be applied to both desktop
    API and language specifications to make them cleaner and more
    consistent. The important parts of this cleanup were done in the texture
    gather functionality folded into ES 3.1, although some small language
    tweaks may still be needed.

    (6) Moved to EXT_shader_implicit_conversions Issue 4.

    (7) Should uniform and shader storage blocks be backable with buffer
        object subranges?

    RESOLVED: Yes. The section 4.3.7 "Interface Blocks" language picked up
    from desktop GL allows this (they are called "bind ranges"). This is a
    spec oversight in ES, because BindBufferRange is fully supported in
    OpenGL ES 3.0.

    (8) Where is MAX_PROGRAM_TEXTURE_GATHER_COMPONENTS?

    RESOLVED. It was not added in Core GL because ARB_texture_gather and
    ARB_gpu_shader5 were both added to GL 4.0 and thus the query was
    unneeded. Since OpenGL ES 3.1 also includes texture gather and the
    multi-component gather support from gpu_shader5, the query was also
    unnecessary there and here.  Bug 11002.

    (9) Some vendors may not be able to support dynamic indexing
    of arrays of images or shader storage blocks. What should we use instead?

    RESOLVED: Only allowing 'constant integral expression' instead of
    'dynamically uniform integer expression' for arrays of images or shader
    storage blocks. For images this is done by carving out an exception in the
    general language for opaque types. For shader storage blocks, different
    rules are given for arrays of uniform blocks and arrays of shader storage
    blocks.

Revision History

    Revision 1, 2013/10/27 (Jon Leech)
        - Initial version based on ARB_gpu_shader5

    Revision 2, 2013/11/06 (Jon Leech)
        - Update Issues list with unresolved issues 4-7, which are dependent
          on decisions to be made by the ARB and ES working groups.
        - Remove {un,}packUnorm2x16EXT (already in ESSL 3.00)
        - Match changes to ES 3.1 texture gather language, but still
          reorganize the textureGather functions into their own subsection &
          table. ES 3.1 restored the [, int comp] argument to the functions
          it defined. Removed sampler2DRect variants incorrectly left in.
        - Clean up function overloading example text and opened bug 11178 to
          resolve possible problems with the GLSL 4.40 language this is
          based on.
        - Remove reference to image2DMS, since there is no longer any image
          load/store support for multisample textures in ES 3.1
        - Add issue (8) regarding "bind ranges".

    Revision 3, 2013/11/14 (Jon Leech)
        - Resolve function overloading issue 7, per bug 11178.

    Revision 4, 2013/11/20 (Jon Leech)
        - Sync with ES 3.1 spec language update.
        - Refer to ES 3.1 instead of ES 3plus.

    Revision 5, 2013/11/21 (Daniel Koch)
        - removed implicit conversion language (to a separate document).
        - updated textureGather functions to reflect the shadow gather
          functionality being added in ES 3.1.
        - added issue 9.

    Revision 6, 2013/12/18 (Daniel Koch)
        - minor cleanup
        - added issue 10, restrict arrays of images to const-int-expr

    Revision 7, 2014/02/12 (Daniel Koch)
        - restrict indexing arrays of shader storage blocks to const-int-expr.
        - Resolved issues 4, 5, 8, 9, 10 and supporting edits.

    Revision 8, 2014/03/10 (Jon Leech)
        - Rebase on OpenGL ES 3.1 and change suffix to EXT.
        - Remove textureGather functions already present in the existing
          GLSL-ES 3.10 spec section 8.9.3

    Revision 9, 2014/03/26 (Daniel Koch)
        - update contributors

    Revision 10, 2014/03/28 (Jon Leech)
        - Sync with released ES 3.1 specs. Reflow text.

    Revision 11, 2014/04/01 (Daniel Koch)
        - Update contributors

    Revision 12, 2015/03/27 (Daniel Koch)
        - Add missing function and token sections.