xref: /third_party/openGLES/extensions/EXT/EXT_shader_framebuffer_fetch.txt

Name

    EXT_shader_framebuffer_fetch

Name Strings

    GL_EXT_shader_framebuffer_fetch
    GL_EXT_shader_framebuffer_fetch_non_coherent

Contact

    Benj Lipchak, Apple (lipchak 'at' apple.com)

Contributors

    Francisco Jerez, Intel

Status

    Complete

Version

    Last Modified Date: September 6, 2018
    Author Revision: 8

Number

    OpenGL ES Extension #122
    OpenGL Extension #520

Dependencies

    OpenGL 2.0 or OpenGL ES 2.0 is required.
    
    This specification is written against the OpenGL ES 2.0.24 and OpenGL ES
    3.0.4 specifications.  This extension is written against the OpenGL ES
    Shading Language 1.0.17 and OpenGL ES Shading Language 3.00.3
    specifications.
    
    OpenGL 2.0, OpenGL 3.0, OpenGL 4.0, OpenGL 4.5, OpenGL ES 2.0, OpenGL ES
    3.0, OpenGL ES 3.1 and OpenGL ES 3.2 affect the definition of this
    extension.

    ARB_sample_shading and OES_sample_shading interact with this extension.

Overview

    Conventional OpenGL blending provides a configurable series of operations
    that can be used to combine the output values from a fragment shader with
    the values already in the framebuffer. While these operations are
    suitable for basic image compositing, other compositing operations or
    operations that treat fragment output as something other than a color
    (normals, for instance) may not be expressible without multiple passes or
    render-to-texture operations.

    This extension provides a mechanism whereby a fragment shader may read
    existing framebuffer data as input. This can be used to implement
    compositing operations that would have been inconvenient or impossible with
    fixed-function blending. It can also be used to apply a function to the
    framebuffer color, by writing a shader which uses the existing framebuffer
    color as its only input.

    This extension provides two alternative name strings:

     - GL_EXT_shader_framebuffer_fetch guarantees full coherency between
       framebuffer reads and writes.  If this extension string is exposed, the
       result of reading from the framebuffer from a fragment shader invocation
       is guaranteed to reflect values written by any previous overlapping
       samples in API primitive order, unless requested otherwise in the shader
       source using the noncoherent layout qualifier.

     - GL_EXT_shader_framebuffer_fetch_non_coherent provides limited implicit
       coherency guarantees.  Instead, the application is expected to call the
       FramebufferFetchBarrierEXT command for previous framebuffer writes to
       become visible to subsequent fragment shader invocations.  For this
       extension to give well-defined results applications may have to split
       rendering into multiple passes separated with FramebufferFetchBarrierEXT
       calls.  The functionality provided by this extension is requested in the
       shader source using the noncoherent layout qualifier.

Issues

    1. How is framebuffer data treated during multisample rendering?
    
    RESOLVED: Reading the value of gl_LastFragData produces a different
    result for each sample. This implies that all or part of the shader be
    run once for each sample, but has no additional implications on fragment
    shader input variables which may still be interpolated per pixel by the
    implementation.
    
    2. How does the use of gl_LastFragData interact with fragment discard?
    
    RESOLVED: Hardware may not necessarily support discarding on sample
    granularity depending on API version and extension support. Therefore,
    three options were considered for this functionality:
    
        A) Allow discard based on variables calculated using the framebuffer
           color when multisample rasterization is disabled, but disallow
           discard in this manner when multisample rasterization is enabled.
        
        B) Restrict usage of the framebuffer color until it is known whether
           or not the pixel will be discarded.
            
        C) Allow undefined results for fragment shaders that discard on a
           per-sample basis on hardware that doesn't support it.
    
    This extension has chosen option C where support for per-sample discard
    is not provided by the GL.  Restricting orthogonality of fragment shaders
    between single-sample and multisample rendering is undesirable, as is
    restricting usage of the framebuffer color, which can generally only be
    done with detailed flow-control analysis.

    If an overlapping specification guarantees well-defined results for
    shaders that execute discard with sample granularity (e.g.
    ARB_sample_shading), this extension won't reverse that guarantee, instead
    the boolean query FRAGMENT_SHADER_DISCARDS_SAMPLES_EXT defined by this
    extension will return TRUE for consistency with current specifications.

    3. What is the precision of gl_LastFragData in practice?
    
    RESOLVED: Three options were considered for this functionality:
    
        A) gl_LastFragData is always mediump.
        
        B) gl_LastFragData takes the precision most closely matching the
           actual storage format of the framebuffer.
        
        C) Allow redeclaration of gl_LastFragData in order to change its
           precision.
    
    This extension has chosen option C. A fixed precision per option A
    increases the likelihood of redundant conversion operations in the shader,
    and option B does not provide for clear behavior with regard to the
    precision of intermediate results from calculations using the
    framebuffer color.

    4. How does this extension iteract with conventional blending?
    
    RESOLVED: There is no interaction.  The two remain orthogonal.  The rest
    of the pipeline continues as usual after the fragment shader stage.
    

    5. How does this extension work in ES 3.0?

    RESOLVED: Differently than in ES 2.0.

    The built-in fragment outputs of ES 2.0 are replaced in #version 300 es
    shaders by user-declared outputs, to accomodate integer and MRT 
    framebuffers.  Three options were considered:

        A) Add built-ins similar to gl_LastFragData.
        
        B) Add a layout to mark user-declared fragment outputs as having
        defined content on entry to fragment shader.
            
        C) Allow marking user-declared fragment outputs as "inout".

    This extension has chosen option C.  Adding built-ins per option A is
    unwieldy for MRT framebuffers with mixed attachment types and precisions.  
    Options B and C are semantically identical, but C requires fewer 
    modifications to the specification and to user shaders.  Note that the 
    inout qualifier is not allowed for re-declaring existing fragment outputs 
    such as gl_FragDepth.

    6. How does this extension interact with sRGB rendering?

    RESOLVED: If the current GL state would cause the corresponding destination
    color to be converted from sRGB to linear at input to blending,
    gl_LastFragData or fragment outputs with the inout storage qualifier will
    contain framebuffer values converted from sRGB to linear upon entry to the
    fragment shader.

    7. How does this extension interact with derivative built-in functions?

    RESOLVED: There is no direct interaction in principle, but because the
    result of framebuffer fetch is undefined for helper invocations, derivative
    functions may give non-deterministic results when the argument is dependent
    on values read from the framebuffer.

    To overcome this limitation the application may be able to calculate the
    derivative of gl_HelperInvocation in order to determine whether any of the
    invocations involved in the calculation are helper invocations, which
    would invalidate the result of the same derivative applied to any
    expression dependent on values read from the framebuffer.  In particular,
    if either dFdx(float(gl_HelperInvocation)) or
    dFdy(float(gl_HelperInvocation)) is zero, the corresponding derivative of
    a value read from the framebuffer should be well-defined.

    8. Should we require the behavior of framebuffer fetch to be well-defined
       for helper invocations in order to support calculating derivatives of
       color outputs without restrictions?

    RESOLVED: Not in this extension.  It would be compelling from the
    perspective of the API, and likely more consistent with the current
    behavior of texture sampling and image loads for helper invocations, but
    hardware support may be limited.  With the non-coherent variant of this
    extension there is the additional difficulty that derivatives could still
    give non-deterministic results, because there is no way for the application
    to determine whether there will be overlap between helper invocations and
    previous rendering done in the same pass, since the set of helper
    invocations executed during rendering is fully defined by the
    implementation.

    9. How should the implementation behave where framebuffer fetch coherency
       cannot be enabled selectively for each fragment output due to hardware
       or software limitations?

    RESOLVED: Because the behavior specified for coherent framebuffer fetch
    outputs is a strict subset of the behavior of non-coherent outputs, the
    implementation is free to ignore any noncoherent layout qualifiers and
    enable coherency globally when the fragment shader bound to the pipeline
    has any color outputs requiring framebuffer fetch coherency.

    10. Should the current coherent memory qualifier be reused to indicate
        whether the application requires framebuffer fetch coherency for a given
        fragment output?

    RESOLVED: No, because that would imply breaking GLSL source-level
    compatibility with earlier versions of the EXT_shader_framebuffer_fetch
    extension.  That said, it may make sense to reconsider this syntactic
    compromise if this extension is used as starting point for another
    specification text (e.g. a derived ARB/KHR extension).

New Procedures and Functions

    [[ The following applies if EXT_shader_framebuffer_fetch_non_coherent is
       supported. ]]

    void FramebufferFetchBarrierEXT(void);
    
New Tokens

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

New Builtin Variables

    [[ The following applies to OpenGL Shading Language 1.1 and 1.2 only. ]]

    vec4 gl_LastFragData[gl_MaxDrawBuffers];

    [[ The following applies to OpenGL ES Shading Language 1.0 only. ]]

    mediump vec4 gl_LastFragData[gl_MaxDrawBuffers]
    
Changes to the OpenGL ES 2.0.24 Specification, Chapter 3

    Remove the last sentence of Paragraph 2 of Section 3.8.1, page 84 ("These
    built-in varying variables include [...]" and add:
    
    These built-in varying variables include the fragment's position, eye z
    coordinate, and front-facing flag, as well as the last data or color value
    written to the framebuffer. When the value of SAMPLE_BUFFERS is 1 and the 
    current framebuffer color is accessed in the fragment shader, the fragment
    shader will be invoked separately for each covered sample and a separate 
    value for the previous framebuffer color will be provided for each sample."
    
    [[ The following applies if EXT_shader_framebuffer_fetch_non_coherent is
       supported. ]]

    Append new paragraph at the end of section 3.8.2, page 197 ("Shader
    Execution"):

    "The command

        void FramebufferFetchBarrierEXT(void);

    specifies a boundary between passes when reading existing framebuffer data
    from fragment shaders via the gl_LastFragData built-in variable.  Previous
    framebuffer object writes regardless of the mechanism (including clears,
    blits and primitive rendering) are guaranteed to be visible to subsequent
    fragment shader invocations that read from the framebuffer once
    FramebufferFetchBarrierEXT is executed."

    [[ The following applies if both EXT_shader_framebuffer_fetch and
       EXT_shader_framebuffer_fetch_non_coherent are supported. ]]

    "Because the implementation guarantees coherency of framebuffer reads and
    writes for color outputs not explicitly marked with the noncoherent layout
    qualifier, calling the FramebufferFetchBarrierEXT command is not required
    unless the application wishes to manage memory ordering of framebuffer
    reads and writes explicitly, which may provide better performance on some
    implementations in cases where rendering can be split into multiple passes
    with non-self-overlapping geometry."

    [[ The following applies to either variant of the extension unless
       specified otherwise in the interactions sections. ]]

    Add a new subsection to section 3.8.2, page 87 ("Shader Execution"):
    
    "Discard
    
    Fragment shaders may conditionally abandon operations using the discard
    keyword. However, the ability of hardware to support abandoning operations
    on a single sample when the shader is invoked once for each covered sample
    is implementation-dependent. This capability can be determined by calling
    GetBooleanv with the symbolic constant 
    FRAGMENT_SHADER_DISCARDS_SAMPLES_EXT. If FALSE is returned, results from
    shaders which discard based on per-sample logic are undefined."

Changes to the OpenGL ES 2.0.24 Specification, Chapter 4

    Replace first element of Figure 4.1, page 90 ("Fragment + Associated Data"):
    
        "Fragment (or sample) + Associated Data"

    Add a new section 4.1.lastfragcolor (Fragment Data Input) - immediately before section 4.1.4 (Stencil Test):

        Prior to fragment shading, if GL_EXT_shader_framebuffer_fetch is enabled,
        gl_LastFragData[] is populated with the value last written to the
        framebuffer at the same (x,y,sample) position.
        
        If the framebuffer attachment corresponding to a given element of
        gl_LastFragData[] has a fixed-point format, each color component undergoes a
        conversion to floating-point first. This conversion must leave the values 0
        and 1 invariant.

        [[If GL_EXT_sRGB is supported]]

        If the value of FRAMEBUFFER_ATTACHMENT_COLOR_ENCODING{_EXT} for the
        framebuffer attachment corresponding to a given element of gl_LastFragData[]
        is SRGB,

        [[If GL_EXT_sRGB_write_control is supported]]


        and FRAMEBUFFER_SRGB_EXT is enabled,


        [[End GL_EXT_sRGB_write_control]]


        the R, G, and B destination color values
        (after conversion from fixedpoint to floating-point) are considered to be
        encoded for the sRGB color space and hence must be linearized first.
        Each R, G, and B component is converted in the same fashion described for
        sRGB texture components in section 3.8.16.

        [[End GL_EXT_sRGB]]

New Implementation Dependent State

    Add to table 6.19 (Implementation Dependent Values (cont.)):

    Get Value                             Type  Get Command  Minimum Value  Description        Section
    ---------                             ----  -----------  -------------  --------------     -------
    FRAGMENT_SHADER_DISCARDS_SAMPLES_EXT  B     GetBooleanv  -              Samples may be     3.8.2
                                                                            discarded 
                                                                            individually 

Changes to the OpenGL ES 3.0.4 Specification, Chapter 3

    Append new paragraphs at the end of the "Shader Outputs" subsection under
    section 3.9.2, Shader Execution, page 171:

    "Prior to fragment shading, fragment outputs declared inout are populated
    with the value last written to the framebuffer at the same (x,y,sample)
    position.  If the framebuffer attachment corresponding to an inout fragment
    output has a fixed-point format, each color component undergoes a
    conversion to floating-point first.  This conversion must leave the values
    0 and 1 invariant.

    Reading from a user-defined fragment output declared inout causes the
    shader to be evaluated per-sample, since the framebuffer potentially
    contains different color values for each sample.

    If the value of FRAMEBUFFER_ATTACHMENT_COLOR_ENCODING{_EXT} for the
    framebuffer attachment corresponding to a given inout fragment output is
    SRGB (see section 6.1.13),"

    [[If GL_EXT_sRGB_write_control is supported]]

    "and FRAMEBUFFER_SRGB_EXT is enabled,"

    [[End GL_EXT_sRGB_write_control]]

    "the R, G, and B destination color values (after conversion from
    fixed-point to floating-point) are considered to be encoded for the sRGB
    color space and hence must be linearized first.  Each R, G, and B component
    is converted in the same fashion described for sRGB texture components in
    section 3.8.16."

    [[ The following applies if EXT_shader_framebuffer_fetch_non_coherent is
       supported. ]]

    "The command

        void FramebufferFetchBarrierEXT(void);

    specifies a boundary between passes when reading existing framebuffer data
    from fragment shaders via inout fragment outputs.  Previous framebuffer
    object writes regardless of the mechanism (including clears, blits and
    primitive rendering) are guaranteed to be visible to subsequent fragment
    shader invocations that read from the framebuffer once
    FramebufferFetchBarrierEXT is executed."

    [[ The following applies if both EXT_shader_framebuffer_fetch and
       EXT_shader_framebuffer_fetch_non_coherent are supported. ]]

    "Because the implementation guarantees coherency of framebuffer reads and
    writes for color outputs not explicitly marked with the noncoherent layout
    qualifier, calling the FramebufferFetchBarrierEXT command is not required
    unless the application wishes to manage memory ordering of framebuffer
    reads and writes explicitly, which may provide better performance on some
    implementations in cases where rendering can be split into multiple passes
    with non-self-overlapping geometry."

Changes to the OpenGL ES Shading Language 1.0.17 Specification, Chapter 3

    Remove Paragraph 2 of section 3.8, page 17, Identifiers ("Identifiers
    starting with "gl_" are reserved [...]") and add:

    "Identifiers starting with "gl_" are reserved for use by the Shading
    Language, and may not be declared in a shader as either a variable or a
    function.  However, as noted in the specification, certain predeclared
    "gl_" names are allowed to be redeclared in a shader for the specific
    purpose of changing their precision or layout qualifier."

Changes to the OpenGL ES Shading Language 1.0.17 Specification, Chapter 4

    [[ The following applies if EXT_shader_framebuffer_fetch_non_coherent is
       supported. ]]

    Add a new Section 4.x (Layout Qualifiers) as follows:

    "4.x Layout Qualifiers

    Layout qualifiers can appear with an individual variable declaration:

        <layout-qualifier> <declaration>;

        <layout-qualifier>:
            layout( <layout-qualifier-id-list> )

        <layout-qualifier-id-list>:
            comma separated list of <layout-qualifier-id>

    Declarations of layouts can only be made at global scope, and only where
    indicated in the following subsection; their details are specific to what
    the declaration interface is, and are discussed individually.

    The tokens in any <layout-qualifier-id-list> are identifiers, not
    keywords. Generally they can be listed in any order. Order-dependent
    meanings exist only if explicitly called out below. Similarly, these
    identifiers are not case-sensitive, unless explicitly noted otherwise.

    4.x.1 Output Layout Qualifiers

    Fragment shaders may specify the following layout qualifier only for
    redeclaring the built-in gl_LastFragData array.  The allowed layout
    qualifier identifiers for gl_LastFragData are:

      <layout-qualifier-id>:
        noncoherent

    Non-coherent framebuffer fetch outputs have relaxed memory ordering
    requirements and may provide better performance on some implementations,
    but they require FramebufferFetchBarrierEXT to be called explicitly for the
    contents rendered to a color attachment to be visible to subsequent
    fragment shader invocations.  Redeclarations are done as follows:

      layout(noncoherent) mediump vec4 gl_LastFragData[gl_MaxDrawBuffers];"

Changes to the OpenGL ES Shading Language 1.0.17 Specification, Chapter 7

    Add after the last sentence of Paragraph 2 of Section 7.2, page 60,
    Fragment Shader Special Variables ("These variables may be written to
    more [...]"):
    
    "... To access the existing framebuffer values (e.g., to implement a
    complex blend operation inside the shader), fragment shaders should use
    the read-only input array gl_LastFragData."

    [[ The following applies if EXT_shader_framebuffer_fetch is supported. ]]

    "Unless it has been redeclared with the noncoherent layout qualifier,
    gl_LastFragData contains the most recent value written to the attachments
    bound to each color output at the current sample location.  Access to
    gl_LastFragData is optional and can be enabled by

     #extension GL_EXT_shader_framebuffer_fetch : <behavior>

    Where <behavior> is as specified in section 3.4.  A new preprocessor
    define is added to the Shading Language:

     #define GL_EXT_shader_framebuffer_fetch                     1"

    [[ The following applies if EXT_shader_framebuffer_fetch_non_coherent is
       supported. ]]

    "If it has been redeclared with the noncoherent layout qualifier,
    gl_LastFragData contains the most recent value written to the attachments
    bound to each color output at the current sample location as long as
    FramebufferFetchBarrierEXT has been executed between the last command that
    updated the same location of the framebuffer attachment and the current
    draw call.  Its value is undefined for any outputs whose contents at the
    current sample location have been modified since the last
    FramebufferFetchBarrierEXT call.  Access to gl_LastFragData and the ability
    to use the layout(noncoherent) qualifier are optional and can be enabled by

     #extension GL_EXT_shader_framebuffer_fetch_non_coherent : <behavior>

    Where <behavior> is as specified in section 3.4.  A new preprocessor
    define is added to the Shading Language:

     #define GL_EXT_shader_framebuffer_fetch_non_coherent        1"

    [[ The following applies to either variant of the extension but shall be
       omitted where precision qualifiers are not supported. ]]

    "By default, gl_LastFragData is declared with the mediump precision
    qualifier. This can be changed by redeclaring the corresponding variables
    with the desired precision qualifier.
    
    Redeclarations are done as follows
    
    // Redeclaration that changes nothing is allowed
    mediump vec4 gl_LastFragData[gl_MaxDrawBuffers]; 
    
    // All the following are allowed redeclaration that change behavior
    lowp vec4 gl_LastFragData[gl_MaxDrawBuffers];
    highp vec4 gl_LastFragData[gl_MaxDrawBuffers];
    
    Redeclarations must not otherwise alter the declared type or array size of
    gl_LastFragData."

    [[ The following applies if EXT_shader_framebuffer_fetch_non_coherent is
       supported. ]]

    "Unless the GL_EXT_shader_framebuffer_fetch extension has been enabled in
    addition, it's an error to use gl_LastFragData if it hasn't been
    explicitly redeclared with layout(noncoherent)."

Changes to the OpenGL ES Shading Language 1.0.17 Specification, Chapter 8

    Add after paragraph 2 of section 8.7, Texture Lookup Functions,
    page 57 ("Functions containing the bias parameter [...]"):

    "Results are undefined if the coordinates passed to any of the built-in
    functions below that compute an implicit LOD value are calculated based on
    the result of reading from gl_LastFragData, and the texture bound to the
    specified sampler is mip-mapped."

Changes to the OpenGL Shading Language 1.10 Specification, Chapter 8

    [[ The following applies in addition to the changes given above for the
       same chapter of the OpenGL ES Shading Language 1.0.17 Specification. ]]

    Append at the end of section 8.8, Fragment Processing Functions,
    page 59:

    "The result of the built-in derivative functions dFdx, dFdy and
    fwidth is undefined if the value passed as argument was calculated
    based on the result of reading from gl_LastFragData."

Changes to the OpenGL ES Shading Language 3.00.3 Specification, Chapter 4

    Modify Paragraph 2 of section 4.3.6:
    "Except in the fragment stage, there is not an inout storage qualifier at
    global scope for declaring a single variable name as both input and output
    [...]"

    Modify Paragraph 7 of section 4.3.6:

    "Fragment outputs output per-fragment data and are declared using the out
    or inout storage qualifier.  It is a compile-time error to use auxiliary
    storage qualifiers or interpolation qualifiers on an output in a fragment
    shader [...]" and append new paragraphs at the end of the same section:

    [[ The following applies if EXT_shader_framebuffer_fetch_non_coherent is
       supported. ]]

    "Fragment outputs declared inout may specify the following layout
    qualifier:

      <layout-qualifier-id>:
        noncoherent

    Non-coherent framebuffer fetch outputs have relaxed memory ordering
    requirements and may provide better performance on some implementations,
    but they require FramebufferFetchBarrierEXT to be called explicitly for the
    contents rendered to a color attachment to be visible to subsequent
    fragment shader invocations."

    [[ The following applies if EXT_shader_framebuffer_fetch is supported. ]]

    "Upon entry to the fragment shader, fragment outputs declared inout not
    qualified with the noncoherent layout qualifier will contain the most
    recent value written to the same framebuffer attachment at the current
    sample location.  This behavior and the ability to use the inout qualifier
    at global scope in a fragment shader is optional and can be enabled by

     #extension GL_EXT_shader_framebuffer_fetch : <behavior>
    
    Where <behavior> is as specified in section 3.4.  A new preprocessor
    define is added to the Shading Language:

     #define GL_EXT_shader_framebuffer_fetch                     1"

    [[ The following applies if EXT_shader_framebuffer_fetch_non_coherent is
       supported. ]]

    "Upon entry to the fragment shader, fragment outputs declared inout
    qualified with the noncoherent layout qualifier will contain the most
    recent value written to the same framebuffer attachment at the current
    sample location, as long as FramebufferFetchBarrierEXT has been executed
    between the last command that updated the framebuffer location and the
    current draw call.  The initial value is undefined for any fragment outputs
    declared inout whose contents at the current sample location have been
    modified since the last FramebufferFetchBarrierEXT call.  This behavior and
    the ability to use the inout and layout(noncoherent) qualifiers at global
    scope in a fragment shader are optional and can be enabled by

     #extension GL_EXT_shader_framebuffer_fetch_non_coherent : <behavior>

    Where <behavior> is as specified in section 3.4.  A new preprocessor
    define is added to the Shading Language:

     #define GL_EXT_shader_framebuffer_fetch_non_coherent        1"

    [[ The following applies if EXT_shader_framebuffer_fetch_non_coherent is
       supported. ]]

    "It is an error to declare an inout fragment output not qualified with
    layout(noncoherent) if the GL_EXT_shader_framebuffer_fetch extension hasn't
    been enabled."

Changes to the OpenGL ES Shading Language 3.00.3 Specification, Chapter 7

    [[ The following shall be omitted if the changes given below for the same
       chapter of the OpenGL ES Shading Language 3.10.4 Specification apply. ]]

    Append at the end of section 7.2, Fragment Shader Special Variables, page
    82:

    "A helper invocation is a fragment shader invocation that is created solely
    for the purposes of evaluating derivatives for the built-in functions
    texture() (section 8.9 "Texture Functions"), dFdx(), dFdy(), and fwidth()
    for other non-helper fragment shader invocations.

    Fragment shader helper invocations execute the same shader code as
    non-helper invocations, but will not have side effects that modify the
    framebuffer or other shader-accessible memory.  In particular fragments
    corresponding to helper invocations are discarded when shader execution is
    complete, without updating the framebuffer.  The values returned when
    reading from the framebuffer via inout fragment outputs are undefined for
    helper invocations.

    Helper invocations may be generated for pixels not covered by a primitive
    being rendered. While fragment shader inputs qualified with "centroid" are
    normally required to be sampled in the intersection of the pixel and the
    primitive, the requirement is ignored for such pixels since there is no
    intersection between the pixel and primitive.

    Helper invocations may also be generated for fragments that are covered by
    a primitive being rendered when the fragment is killed by early fragment
    tests or where the implementation is able to determine that executing the
    fragment shader would have no effect other than assisting in computing
    derivatives for other fragment shader invocations.  The set of helper
    invocations generated when processing any set of primitives is
    implementation-dependent."

Changes to the OpenGL ES Shading Language 3.10.4 Specification, Chapter 7

    Modify the first bullet point of paragraph 11 of section 7.1.2, Fragment
    Shader Special Variables, page 96:

    "* Fragments corresponding to helper invocations are discarded when shader
       execution is complete, without updating the framebuffer.  The values
       returned when reading from the framebuffer via inout fragment outputs
       are undefined for helper invocations."

Interactions with OpenGL 2.0

    If OpenGL 2.0 is supported, all changes given above for the OpenGL ES
    2.0.24 and OpenGL ES Shading Language 1.0.17 specifications shall be
    applied, in addition to any changes given specifically for the OpenGL
    Shading Language 1.10 Specification.  References to precision qualifiers
    shall be omitted.

Interactions with OpenGL 3.0 and later

    If OpenGL 3.0 is supported, all changes given above for the OpenGL ES 3.0.4
    and OpenGL ES Shading Language 3.00.3 specifications shall be applied.
    Changes given for earlier OpenGL ES and OpenGL ES Shading Language versions
    shall be ignored.  References to auxiliary storage qualifiers shall be
    omitted if they are not supported by the Shading Language.

Interactions with OpenGL 4.0 and later

    The interaction described below with ARB_sample_shading applies in
    addition to any interactions enumerated for OpenGL 3.0 and above.

Interactions with OpenGL 4.5 and later

    The changes given above for the OpenGL Shading Language 3.10.4
    Specification shall be applied in addition to any interactions enumerated
    for OpenGL 4.0 and above.

Interactions with OpenGL ES 2.0

    If OpenGL ES 2.0 is supported, apply all changes given above for the OpenGL
    ES 2.0.24 and OpenGL ES Shading Language 1.0.17 specifications.

Interactions with OpenGL ES 3.0 and later

    If OpenGL ES 3.0 is supported, all changes given above for the OpenGL ES
    3.0.4 and OpenGL ES Shading Language 3.00.3 specifications shall be
    applied.  Changes given for earlier OpenGL ES and OpenGL ES Shading
    Language versions shall be ignored.  References to auxiliary storage
    qualifiers shall be omitted if they are not supported by the Shading
    Language.

Interactions with OpenGL ES 3.1 and later

    The changes given above for the OpenGL Shading Language 3.10.4
    Specification shall be applied in addition to any interactions enumerated
    for OpenGL ES 3.0 and above.

Interactions with OpenGL ES 3.2 and later

    The interaction described below with OES_sample_shading applies in
    addition to any interactions enumerated for OpenGL ES 3.1 and above.

Interactions with OES_standard_derivatives

    Results from shaders which use the built-in derivative functions dFdx,
    dFdy, and fwidth on variables calculated using the current framebuffer 
    color are undefined.

Interactions with ARB_sample_shading and OES_sample_shading

    The FRAGMENT_SHADER_DISCARDS_SAMPLES_EXT query defined above is guaranteed
    to return TRUE if any of these extensions is supported, since they
    already provide well-defined behavior for discard jumps with sample
    granularity.

Revision History

    Version 8, 2018/09/06 - Replace non-ASCII quote characters.
    Version 7, 2017/11/13 - Specify interactions with desktop OpenGL APIs.
                          - Specify interaction with ARB/OES_sample_shading
                            and unextended GL versions that provide the same
                            functionality.  Clarify resolution of
                            multisampling-related issues to avoid
                            contradicting recent versions of the spec.
                          - Explicitly require per-sample evaluation of the
                            fragment shader when an inout output is read in
                            OpenGL ES 3.0 and above.
                          - Specify undefined behavior of helper invocations
                            in OpenGL ES 3.0 and above.  Add discussion
                            related to derivative computations in the issues
                            section.
                          - Specify undefined behavior of texture lookup
                            functions that compute implicit derivatives in
                            OpenGL (ES) 2.0.
                          - Define EXT_shader_framebuffer_fetch_non_coherent
                            variant of the extension.  Add
                            FramebufferFetchBarrierEXT command.  Define
                            noncoherent layout qualifier for finer-grained
                            control of framebuffer fetch coherency.
    Version 6, 2017/10/04 - Clarified how gl_LastFragData is populated.
    Version 5, 2016/09/08 - Added preprocessor defines.
    Version 4, 2013/05/28 - Added ES3 interaction as requested in Bug 10236
    Version 3, 2012/09/24 - Remove obsolete issue 3 about derivatives
    Version 2, 2012/06/21 - Fix MULTISAMPLE enabled -> SAMPLE_BUFFERS = 1,
                            recast from APPLE to multivendor EXT, clarify that
                            gl_LastFragData reflects value written by previous
                            pixel at same coordinates.
    Version 1, 2012/06/01 - Conversion from ARB_sync to APPLE_sync for ES.