Name

    KHR_blend_equation_advanced

Name Strings

    GL_KHR_blend_equation_advanced
    GL_KHR_blend_equation_advanced_coherent

Contact

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

Notice

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

Specification Update Policy

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

Contributors

    OpenGL ES Working Group in Khronos
    Jeff Bolz, NVIDIA Corporation
    Mathias Heyer, NVIDIA Corporation
    Mark Kilgard, NVIDIA Corporation
    Daniel Koch, NVIDIA Corporation
    Rik Cabanier, Adobe
    Slawek Grajewski, Intel

Status

    Complete.
    Ratified by the Khronos Board of Promoters on 2014/03/14.

Version

    Last Modified Date:         February 14, 2018
    Revision:                   17

Number

    ARB Extension #174
    OpenGL ES Extension #168

Dependencies

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

    This extension is written against the OpenGL Shading Language
    Specification, Version 4.10 (Revision 6).

    OpenGL 2.0 is required (for Desktop).

    OpenGL ES 2.0 is required (for mobile).

    EXT_blend_minmax is required (for mobile).

    This extension interacts with OpenGL 4.0.

    This extension interacts with OpenGL 4.1 (Core Profile).

    This extension interacts with OpenGL 4.3 or later.

    This extension interacts with OpenGL ES 2.0.

    This extension interacts with OpenGL ES 3.0.

    This extension interacts with NV_path_rendering.

Overview

    This extension adds a number of "advanced" blending equations that can be
    used to perform new color blending operations, many of which are more
    complex than the standard blend modes provided by unextended OpenGL.  This
    extension provides two different extension string entries:

    - KHR_blend_equation_advanced:  Provides the new blending equations, but
      guarantees defined results only if each sample is touched no more than
      once in any single rendering pass.  The command BlendBarrierKHR() is
      provided to indicate a boundary between passes.

    - KHR_blend_equation_advanced_coherent:  Provides the new blending
      equations, and guarantees that blending is done coherently and in API
      primitive order.  An enable is provided to allow implementations to opt
      out of fully coherent blending and instead behave as though only
      KHR_blend_equation_advanced were supported.

    Some implementations may support KHR_blend_equation_advanced without
    supporting KHR_blend_equation_advanced_coherent.

    In unextended OpenGL, the set of blending equations is limited, and can be
    expressed very simply.  The MIN and MAX blend equations simply compute
    component-wise minimums or maximums of source and destination color
    components.  The FUNC_ADD, FUNC_SUBTRACT, and FUNC_REVERSE_SUBTRACT
    multiply the source and destination colors by source and destination
    factors and either add the two products together or subtract one from the
    other.  This limited set of operations supports many common blending
    operations but precludes the use of more sophisticated transparency and
    blending operations commonly available in many dedicated imaging APIs.

    This extension provides a number of new "advanced" blending equations.
    Unlike traditional blending operations using the FUNC_ADD equation, these
    blending equations do not use source and destination factors specified by
    BlendFunc.  Instead, each blend equation specifies a complete equation
    based on the source and destination colors.  These new blend equations are
    used for both RGB and alpha components; they may not be used to perform
    separate RGB and alpha blending (via functions like
    BlendEquationSeparate).

    These blending operations are performed using premultiplied source and
    destination colors, where RGB colors produced by the fragment shader and
    stored in the framebuffer are considered to be multiplied by alpha
    (coverage).  Many of these advanced blending equations are formulated
    where the result of blending source and destination colors with partial
    coverage have three separate contributions:  from the portions covered by
    both the source and the destination, from the portion covered only by the
    source, and from the portion covered only by the destination.  Such
    equations are defined assuming that the source and destination coverage
    have no spatial correlation within the pixel.

    In addition to the coherency issues on implementations not supporting
    KHR_blend_equation_advanced_coherent, this extension has several
    limitations worth noting.  First, the new blend equations are not
    supported while rendering to more than one color buffer at once; an
    INVALID_OPERATION will be generated if an application attempts to render
    any primitives in this unsupported configuration.  Additionally, blending
    precision may be limited to 16-bit floating-point, which could result in a
    loss of precision and dynamic range for framebuffer formats with 32-bit
    floating-point components, and in a loss of precision for formats with 12-
    and 16-bit signed or unsigned normalized integer components.

New Procedures and Functions

    void BlendBarrierKHR(void);

New Tokens

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

        BLEND_ADVANCED_COHERENT_KHR                     0x9285

    Note:  The BLEND_ADVANCED_COHERENT_KHR enable is provided if and only if
    the KHR_blend_equation_advanced_coherent extension is supported.  On
    implementations supporting only KHR_blend_equation_advanced, this enable
    is considered not to exist.

    Accepted by the <mode> parameter of BlendEquation and BlendEquationi:

        MULTIPLY_KHR                                    0x9294
        SCREEN_KHR                                      0x9295
        OVERLAY_KHR                                     0x9296
        DARKEN_KHR                                      0x9297
        LIGHTEN_KHR                                     0x9298
        COLORDODGE_KHR                                  0x9299
        COLORBURN_KHR                                   0x929A
        HARDLIGHT_KHR                                   0x929B
        SOFTLIGHT_KHR                                   0x929C
        DIFFERENCE_KHR                                  0x929E
        EXCLUSION_KHR                                   0x92A0

        HSL_HUE_KHR                                     0x92AD
        HSL_SATURATION_KHR                              0x92AE
        HSL_COLOR_KHR                                   0x92AF
        HSL_LUMINOSITY_KHR                              0x92B0

    NOTE:  These enums are not accepted by the <modeRGB> or <modeAlpha>
    parameters of BlendEquationSeparate or BlendEquationSeparatei.


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

    None.

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

    None.

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

    Modify Section 4.1.8, Blending (p. 359).

    (modify the first paragraph, p. 361, allowing for new values in the
    <mode> parameter) ... <modeRGB> and <modeAlpha> must be one of
    FUNC_ADD, FUNC_SUBTRACT, FUNC_REVERSE_SUBTRACT, MIN, or MAX as listed
    in Table 4.1.  <mode> must be one of the mode values in Table 4.1,
    or one of the blend equations listed in tables X.1 and X.2. ...

    (modify the third paragraph, p. 361, specifying minimum precision and
    dynamic range for blend operations) ... Blending computations are treated
    as if carried out in floating-point.  For the equations in table 4.1,
    blending computations will be performed with a precision and dynamic range
    no lower than that used to represent destination components.  For the
    equations in table X.1 and X.2, blending computations will be performed
    with a precision and dynamic range no lower than the smaller of that used
    to represent destination components or that used to represent 16-bit
    floating-point values as described in section 2.1.1.

    (add unnumbered subsection prior to "Dual Source Blending and Multiple
     Draw Buffers", p. 363)

    Advanced Blend Equations

    The advanced blend equations are those listed in tables X.1 and X.2.  When
    using one of these equations, blending is performed according to the
    following equations:

      R = f(Rs',Rd')*p0(As,Ad) + Y*Rs'*p1(As,Ad) + Z*Rd'*p2(As,Ad)
      G = f(Gs',Gd')*p0(As,Ad) + Y*Gs'*p1(As,Ad) + Z*Gd'*p2(As,Ad)
      B = f(Bs',Bd')*p0(As,Ad) + Y*Bs'*p1(As,Ad) + Z*Bd'*p2(As,Ad)
      A =          X*p0(As,Ad) +     Y*p1(As,Ad) +     Z*p2(As,Ad)

    where the function f and terms X, Y, and Z are specified in the table.
    The R, G, and B components of the source color used for blending are
    considered to have been premultiplied by the A component prior to
    blending.  The base source color (Rs',Gs',Bs') is obtained by dividing
    through by the A component:

      (Rs', Gs', Bs') =
        (0, 0, 0),              if As == 0
        (Rs/As, Gs/As, Bs/As),  otherwise

    The destination color components are always considered to have been
    premultiplied by the destination A component and the base destination
    color (Rd', Gd', Bd') is obtained by dividing through by the A component:

      (Rd', Gd', Bd') =
        (0, 0, 0),               if Ad == 0
        (Rd/Ad, Gd/Ad, Bd/Ad),   otherwise

    When blending using advanced blend equations, we expect that the R, G, and
    B components of premultiplied source and destination color inputs be
    stored as the product of non-premultiplied R, G, and B components and the
    A component of the color.  If any R, G, or B component of a premultiplied
    input color is non-zero and the A component is zero, the color is
    considered ill-formed, and the corresponding component of the blend result
    will be undefined.

    The weighting functions p0, p1, and p2 are defined as follows:

      p0(As,Ad) = As*Ad
      p1(As,Ad) = As*(1-Ad)
      p2(As,Ad) = Ad*(1-As)

    In these functions, the A components of the source and destination colors
    are taken to indicate the portion of the pixel covered by the fragment
    (source) and the fragments previously accumulated in the pixel
    (destination).  The functions p0, p1, and p2 approximate the relative
    portion of the pixel covered by the intersection of the source and
    destination, covered only by the source, and covered only by the
    destination, respectively.  The equations defined here assume that there
    is no correlation between the source and destination coverage.


      Mode                      Blend Coefficients
      --------------------      -----------------------------------
      MULTIPLY_KHR              (X,Y,Z)  = (1,1,1)
                                f(Cs,Cd) = Cs*Cd

      SCREEN_KHR                (X,Y,Z)  = (1,1,1)
                                f(Cs,Cd) = Cs+Cd-Cs*Cd

      OVERLAY_KHR               (X,Y,Z)  = (1,1,1)
                                f(Cs,Cd) = 2*Cs*Cd, if Cd <= 0.5
                                           1-2*(1-Cs)*(1-Cd), otherwise

      DARKEN_KHR                (X,Y,Z)  = (1,1,1)
                                f(Cs,Cd) = min(Cs,Cd)

      LIGHTEN_KHR               (X,Y,Z)  = (1,1,1)
                                f(Cs,Cd) = max(Cs,Cd)

      COLORDODGE_KHR            (X,Y,Z)  = (1,1,1)
                                f(Cs,Cd) =
                                  0, if Cd <= 0
                                  min(1,Cd/(1-Cs)), if Cd > 0 and Cs < 1
                                  1, if Cd > 0 and Cs >= 1

      COLORBURN_KHR             (X,Y,Z)  = (1,1,1)
                                f(Cs,Cd) =
                                  1, if Cd >= 1
                                  1 - min(1,(1-Cd)/Cs), if Cd < 1 and Cs > 0
                                  0, if Cd < 1 and Cs <= 0

      HARDLIGHT_KHR             (X,Y,Z)  = (1,1,1)
                                f(Cs,Cd) = 2*Cs*Cd, if Cs <= 0.5
                                           1-2*(1-Cs)*(1-Cd), otherwise

      SOFTLIGHT_KHR             (X,Y,Z)  = (1,1,1)
                                f(Cs,Cd) =
                                  Cd-(1-2*Cs)*Cd*(1-Cd),
                                    if Cs <= 0.5
                                  Cd+(2*Cs-1)*Cd*((16*Cd-12)*Cd+3),
                                    if Cs > 0.5 and Cd <= 0.25
                                  Cd+(2*Cs-1)*(sqrt(Cd)-Cd),
                                    if Cs > 0.5 and Cd > 0.25

      DIFFERENCE_KHR            (X,Y,Z)  = (1,1,1)
                                f(Cs,Cd) = abs(Cd-Cs)

      EXCLUSION_KHR             (X,Y,Z)  = (1,1,1)
                                f(Cs,Cd) = Cs+Cd-2*Cs*Cd

      Table X.1, Advanced Blend Equations


    When using one of the HSL blend equations in table X.2 as the blend
    equation, the RGB color components produced by the function f() are
    effectively obtained by converting both the non-premultiplied source and
    destination colors to the HSL (hue, saturation, luminosity) color space,
    generating a new HSL color by selecting H, S, and L components from the
    source or destination according to the blend equation, and then converting
    the result back to RGB.  The HSL blend equations are only well defined
    when the values of the input color components are in the range [0..1].
    In the equations below, a blended RGB color is produced according to the
    following pseudocode:

      float minv3(vec3 c) {
        return min(min(c.r, c.g), c.b);
      }
      float maxv3(vec3 c) {
        return max(max(c.r, c.g), c.b);
      }
      float lumv3(vec3 c) {
        return dot(c, vec3(0.30, 0.59, 0.11));
      }
      float satv3(vec3 c) {
        return maxv3(c) - minv3(c);
      }

      // If any color components are outside [0,1], adjust the color to
      // get the components in range.
      vec3 ClipColor(vec3 color) {
        float lum = lumv3(color);
        float mincol = minv3(color);
        float maxcol = maxv3(color);
        if (mincol < 0.0) {
          color = lum + ((color-lum)*lum) / (lum-mincol);
        }
        if (maxcol > 1.0) {
          color = lum + ((color-lum)*(1-lum)) / (maxcol-lum);
        }
        return color;
      }

      // Take the base RGB color <cbase> and override its luminosity
      // with that of the RGB color <clum>.
      vec3 SetLum(vec3 cbase, vec3 clum) {
        float lbase = lumv3(cbase);
        float llum = lumv3(clum);
        float ldiff = llum - lbase;
        vec3 color = cbase + vec3(ldiff);
        return ClipColor(color);
      }

      // Take the base RGB color <cbase> and override its saturation with
      // that of the RGB color <csat>.  The override the luminosity of the
      // result with that of the RGB color <clum>.
      vec3 SetLumSat(vec3 cbase, vec3 csat, vec3 clum)
      {
        float minbase = minv3(cbase);
        float sbase = satv3(cbase);
        float ssat = satv3(csat);
        vec3 color;
        if (sbase > 0) {
          // Equivalent (modulo rounding errors) to setting the
          // smallest (R,G,B) component to 0, the largest to <ssat>,
          // and interpolating the "middle" component based on its
          // original value relative to the smallest/largest.
          color = (cbase - minbase) * ssat / sbase;
        } else {
          color = vec3(0.0);
        }
        return SetLum(color, clum);
      }


      Mode                      Result
      --------------------      ----------------------------------------
      HSL_HUE_KHR               (X,Y,Z)  = (1,1,1)
                                f(Cs,Cd) = SetLumSat(Cs,Cd,Cd);

      HSL_SATURATION_KHR        (X,Y,Z)  = (1,1,1)
                                f(Cs,Cd) = SetLumSat(Cd,Cs,Cd);

      HSL_COLOR_KHR             (X,Y,Z)  = (1,1,1)
                                f(Cs,Cd) = SetLum(Cs,Cd);

      HSL_LUMINOSITY_KHR        (X,Y,Z)  = (1,1,1)
                                f(Cs,Cd) = SetLum(Cd,Cs);

      Table X.2, Hue-Saturation-Luminosity Advanced Blend Equations


    Advanced blending equations are supported only when rendering to a single
    color buffer using fragment color zero.  If any non-NONE draw buffer uses
    a blend equation found in table X.1 or X.2, the error INVALID_OPERATION is
    generated by [[Compatibility Profile:  Begin or any operation that
    implicitly calls Begin (such as DrawElements)]] [[Core Profile and OpenGL
    ES:  DrawArrays and the other drawing commands defined in section 2.8.3]]
    if:

      * the draw buffer for color output zero selects multiple color buffers
        (e.g., FRONT_AND_BACK in the default framebuffer); or

      * the draw buffer for any other color output is not NONE.

    [[ The following paragraph applies to KHR_blend_equation_advanced only. ]]

    When using advanced blending equations, applications should split their
    rendering into a collection of blending passes, none of which touch an
    individual sample in the framebuffer more than once.  The results of
    blending are undefined if the sample being blended has been touched
    previously in the same pass.  The command

      void BlendBarrierKHR(void);

    specifies a boundary between passes when using advanced blend equations.
    Any command that causes the value of a sample to be modified using the
    framebuffer is considered to touch the sample, including clears, blended
    or unblended primitives, and BlitFramebuffer copies.

    [[ The following paragraph applies to KHR_blend_equation_advanced_coherent
       only. ]]

    When using advanced blending equations, blending is typically done
    coherently and in primitive order.  When an individual sample is covered
    by multiple primitives, blending for that sample is performed sequentially
    in the order in which the primitives were submitted.  This coherent
    blending is enabled by default, but can be enabled or disabled by calling
    Enable or Disable with the symbolic constant BLEND_ADVANCED_COHERENT_KHR.
    If coherent blending is disabled, applications should split their
    rendering into a collection of blending passes, none of which touch an
    individual sample in the framebuffer more than once.  When coherent
    blending is disabled, the results of blending are undefined if the sample
    being blended has been touched previously in the same pass.  The command

      void BlendBarrierKHR(void);

    specifies a boundary between passes when using advanced blend equations.
    Any command that causes the value of a sample to be modified using the
    framebuffer is considered to touch the sample, including clears, blended
    or unblended primitives, and BlitFramebuffer copies.

    Advanced blending equations require the use of a fragment shader with a
    matching "blend_support" layout qualifier.  If the current blend equation
    is found in table X.1 or X.2, and the active fragment shader does not
    include the layout qualifier matching the blend equation or
    "blend_support_all_equations", the error INVALID_OPERATION is generated by
    [[Compatibility Profile:  Begin or any operation that implicitly calls
    Begin (such as DrawElements)]] [[Core Profile and OpenGL ES:  DrawArrays
    and the other drawing commands defined in section 2.8.3]] The set of
    layout qualifiers supported in fragment shaders is specified in sectino
    4.3.8.2 of the OpenGL Shading Language Specification.


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

    None.

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

    None.

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

    None.

Additions to the AGL/GLX/WGL/EGL Specifications

    None.

Additions to the OpenGL Shading Language Specification, Version 4.10

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

      #extension GL_KHR_blend_equation_advanced : <behavior>

    where <behavior> is as specified in section 3.3.

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

      #define GL_KHR_blend_equation_advanced 1

    Modify Section 4.3.8.2, Output Layout Qualifiers, p. 47

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

    Fragment shaders additionally support the following layout qualifiers,
    specifying a set of advanced blend equations supported when the fragment
    shader is used.  These layout qualifiers are only permitted on the
    interface qualifier out, and use the identifiers specified in the "Layout
    Qualifier" column of Table X.3.

    If a layout qualifier in Table X.3 is specified in the fragment shader,
    the fragment shader may be used with the corresponding advanced blend
    equation in the "Blend Equation(s) Supported" column.  Additionally, the
    special qualifier "blend_support_all_equations" indicates that the shader
    may be used with any advanced blending equation supported by the OpenGL
    Specification.  It is not an error to specify more than one of these
    identifiers in any fragment shader.  Specifying more than one qualifier or
    "blend_support_all_equations" means that the fragment shader may be used
    with multiple advanced blend equations.  Additionally, it is not an error
    to specify any single any of these layout qualifiers more than once.

        Layout Qualifier                Blend Equation(s) Supported
        ------------------------        ------------------------------
        blend_support_multiply          MULTIPLY_KHR
        blend_support_screen            SCREEN_KHR
        blend_support_overlay           OVERLAY_KHR
        blend_support_darken            DARKEN_KHR
        blend_support_lighten           LIGHTEN_KHR
        blend_support_colordodge        COLORDODGE_KHR
        blend_support_colorburn         COLORBURN_KHR
        blend_support_hardlight         HARDLIGHT_KHR
        blend_support_softlight         SOFTLIGHT_KHR
        blend_support_difference        DIFFERENCE_KHR
        blend_support_exclusion         EXCLUSION_KHR
        blend_support_hsl_hue           HSL_HUE_KHR
        blend_support_hsl_saturation    HSL_SATURATION_KHR
        blend_support_hsl_color         HSL_COLOR_KHR
        blend_support_hsl_luminosity    HSL_LUMINOSITY_KHR
        blend_support_all_equations     /all blend equations/

      Table X.3, Fragment Shader Output Layout Qualifiers for Blend Support

    A draw-time error will be generated in the OpenGL API if an application
    attempts to render using an advanced blending equation without having a
    matching layout qualifier specified in the active fragment shader.

GLX Protocol

    !!! TBD

Dependencies on OpenGL 4.0

    If OpenGL 4.0 is not supported, references to the BlendEquationi API should
    be removed.

Dependencies on OpenGL 4.1 (Core Profile)

    This extension throws an INVALID_OPERATION when Begin is called if advanced
    blend equations are used in conjunction with multiple draw buffers.  For
    the core profile of OpenGL 4.1 (and other versions of OpenGL), there is no
    Begin command; instead, the error is thrown by other rendering commands
    such as DrawArrays.  The language in this specification documenting the
    error has separate versions for the core and compatibility profiles.

Dependencies on OpenGL 4.3 or later (any Profile)

    References to Chapter 4 are replaced with references to Chapter 17 (Writing
    Fragments and Samples to the Framebuffer).
    References to section 4.1.8 are replaced with references to section 17.3.8.
    References to Table 4.1 are replace with references to Table 17.1.
    References to section 2.1.1 are replaced with references to section 2.3.3.

Dependencies on OpenGL ES 2.0

    If unextended OpenGL ES 2.0 is supported, references to BlendEquationi,
    BlendEquationSeparatei, GetInteger64v, and GetDoublev should be ignored.

    Ignore any references to multiple draw buffers if EXT_draw_buffers or
    NV_draw_buffers is not supported.

Dependencies on EXT_blend_minmax

    Requires EXT_blend_minmax on OpenGL ES 2.0 implementations and references
    to MIN and MAX should be replace by references to MIN_EXT and MAX_EXT as
    introduced by that extension.

Dependencies on OpenGL ES 3.0

    If unextended OpenGL ES 3.0 is supported, references to BlendEquationi,
    BlendEquationSeparatei, and GetDoublev should be ignored.

Dependencies on NV_path_rendering

    When NV_path_rendering is supported, covering geometry generated by the
    commands CoverFillPathNV, CoverFillPathInstancedNV, CoverStrokePathNV, and
    CoverStrokePathInstancedNV will automatically be blended coherently
    relative to previous geometry when using the blend equations in this
    extension.  This guarantee is provided even on implementations supporting
    only NV_blend_equation_advanced.

    Insert the following language after the discussion of the
    BlendBarrierKHR() command for both extensions:

      [[ For KHR_blend_equation_advanced only: ]]

      The commands CoverFillPathNV, CoverFillPathInstancedNV,
      CoverStrokePathNV, and CoverStrokePathInstancedNV are considered to
      start a new blending pass, as though BlendBarrierKHR were called prior
      to the cover operation.  If a cover primitive is followed by subsequent
      non-cover primitives using advanced blend equations and touching the
      same samples, applications must call BlendBarrierKHR after the cover
      primitives to ensure defined blending results.

      [[ For KHR_blend_equation_advanced_coherent, the language immediately
         above should be used, but the first sentence should be prefixed with
         "When coherent blending is disabled, ...". ]]


Errors

    If any non-NONE draw buffer uses a blend equation found in table X.1 or
    X.2, the error INVALID_OPERATION is generated by Begin or any operation
    that implicitly calls Begin (such as DrawElements) if:

      * the draw buffer for color output zero selects multiple color buffers
        (e.g., FRONT_AND_BACK in the default framebuffer); or

      * the draw buffer for any other color output is not NONE.

New State
                                             Initial
    Get Value             Type  Get Command   Value         Description               Sec    Attribute
    --------------------  ----  ------------  ------------  ------------------------  -----  ------------
    BLEND_ADVANCED_        B    IsEnabled     TRUE          are advanced blending     4.1.8  color-buffer
      COHERENT_KHR                                          equations guaranteed to
                                                            be evaluated coherently?

    Note:  The BLEND_ADVANCED_COHERENT_KHR enable is provided if and only if
    the KHR_blend_equation_advanced_coherent extension is supported.  On
    implementations supporting only KHR_blend_equation_advanced, this enable
    is considered not to exist.

New Implementation Dependent State

    None.

Issues

    Note:  These issues apply specifically to the definition of the
    KHR_blend_equation_advanced specification, which was derived from the
    extension NV_blend_equation_advanced.  The issues from the original
    NV_blend_equation_advanced specification have been removed, but can be
    found (as of August 2013) in the OpenGL Registry at:

      http://www.opengl.org/registry/specs/NV/blend_equation_advanced.txt

    (0) How does this extension differ from the NV_blend_equation_advanced
        extension for OpenGL and OpenGL ES?

      RESOLVED:  A number of features have been removed from
      NV_blend_equation_advanced, including:

      * The BlendParameterivNV API has been removed, and with it, the
        BLEND_PREMULTIPLIED_SRC_NV and BLEND_OVERLAP_NV parameters.  The spec
        has been refactored to assume premultipled source colors and
        uncorrelated source and destination coverage.

      * A number of less commonly used blend modes have been removed,
        including:

         - certain "X/Y/Z" blending modes supported by few, if any, standards
           (INVERT, INVERT_RGB_NV, LINEARDODGE_NV, LINEARBURN_NV,
           VIVIDLIGHT_NV, LINEARLIGHT_NV, PINLIGHT_NV, HARDMIX_NV)

         - various versions of additive and subtractive modes (PLUS_NV,
           PLUS_CLAMPED_NV, PLUS_CLAMPED_ALPHA_NV, PLUS_DARKER_NV, MINUS_NV,
           MINUS_CLAMPED_NV)

         - other uncommon miscellaneous modes (CONTRAST_NV, INVERT_OVG_NV,
           RED, GREEN, BLUE)

      Additionally, this extension adds blending support layout qualifiers to
      the fragment shader (qualifying "out").  Each fragment shader can
      specify a set of advanced blend equations that can be used when it is
      active.  For example:

        layout(blend_support_hardlight, blend_support_softlight) out;

      specifies that the HARDLIGHT_KHR and SOFTLIGHT_KHR equations are allowed
      when using the shader.  A draw-time error will be generated if an
      advanced blend equation is enabled in the API and a matching layout
      qualifier is not specified in the active fragment shader.

    (1) What should we do about the BLEND_PREMULTIPLIED_SRC_NV blend parameter
        from NV_blend_equation_advanced?

      RESOLVED:  Remove this parameter for simplicity.  All equations in this
      extension assume that the source and destination colors are both
      premultiplied.

    (2) What should we do about the BLEND_OVERLAP_NV blend parameter from
        NV_blend_equation_advanced?

      RESOLVED:  Remove this parameter for simplicitly.  All equations in this
      extension assume an UNCORRELATED_NV overlap mode.  Blending using the
      UNCORRELATED_NV overlap mode is usually mathematically simpler than
      blending using the DISJOINT_NV or CONJOINT_NV modes.

    (3) What set of "complex" blending equations should we support in this
        extension?

      RESOLVED:  During standardization of this extensions, the set of
      equations provided in this extension has been reduced to a smaller
      subset for simplicitly.  The remaining equations are typically found in
      a wide collection of compositing standards.  In particular, the
      standarization process removed several classes of blend equations from
      the NV_blend_equation_advanced, as described in "differences" issue (0)
      above.

    (4) Should we support the "Porter-Duff" blend equations (e.g.,
        SRC_OVER_NV) from NV_blend_equation_advanced?

      RESOLVED:  All of these blend equations should be supportable in
      unextended OpenGL ES 3.0, and have been removed for simplicity.  The
      primary rationale for this decision is to reduce the number of internal
      paths required by the driver; some implementations may have separate
      paths for traditional OpenGL blending and for the new advanced blending
      equations.  Redirecting "simple" advanced blending equations to
      traditional fixed-function blending hardware may involved more driver
      implementation work and may have different performance characteristics
      than other "complex" blending equations.

      This approach does mean that an application wanting to use both
      Porter-Duff blend equations and advanced blending equations provided by
      this extension will need GL_to program blending somewhat differently
      when using the Porter-Duff equations:

        if (isPorterDuff(equation)) {
          glBlendEquation(GL_FUNC_ADD);        // enable sf*S+df*D blending
          glBlendFunc(srcFactor, dstFactor);   // and program blend factors
        } else {
          glBlendEquation(equation);  // advanced eqs. don't use BlendFunc
        }

    (5) Should we impose any requirements on fragment shaders when used in
        conjunction with advanced blend equations?

      RESOLVED:  Yes.  This extension adds fragment shader layout qualifiers
      allowing individual shaders to specify that they will be used with one
      or multiple advanced blending equations.  When using an advanced
      blending equation from this extension, it is necessary to use a fragment
      shader with a matching layout qualifier.  A draw-time error will be
      generated if the current fragment shader doesn't include a layout
      qualifier matching the current advanced blending mode.

      The rationale for this decision is that some implementations of this
      extension may require special fragment shader code when using advanced
      blending equations, and may perhaps perform the entire blending
      operation in the fragment shader.  Knowing the set of blending equations
      that a fragment shader will be used with at compile time may reduce the
      extent of run-time fragment shader re-compilation when the shader is
      used.

      Note that NV_blend_equation_advanced doesn't include layout qualifiers
      or the draw-time error specified here.

    (6) How do we handle coherency when a fragment is hit multiple times?

      RESOLVED:  In this extension, blending equations will be done coherently
      and in primitive order by default, as is the case with traditional
      blending in OpenGL and OpenGL ES.

      The NVIDIA extension provides two separate extension string entries:

        * NV_blend_equation_advanced
        * NV_blend_equation_advanced_coherent

      Exposing the former without the latter signals that the implementation
      can support blending with these equations, but is unable to ensure that
      fragments are blended in order when the same (x,y) is touched multiple
      times.  To ensure coherent results and proper ordering using the
      non-coherent version of the extension, an application must separate its
      rendering into "passes" that touch each (x,y) at most once, and call
      BlendBarrierNV between passes.  There are important use cases (e.g.,
      many path rendering algorithms) where this limitation isn't too
      restrictive, and NVIDIA chose to expose the non-coherent version to
      allow the functionality to be used on a larger set of GPUs.

      This extension is functionally comparable to an implementation of the
      NVIDIA extension exposing both strings, where coherent behavior is
      enabled by default.  NV_blend_equation_advanced_coherent and this
      extension both provide the ability to opt out of this automatic
      coherence by disabling BLEND_ADVANCED_COHERENT_KHR and using
      BlendBarrierKHR manually.  This could theoretically result in higher
      performance -- see issue (32) of the NVIDIA extension for more
      discussion.

    (7) How should the blend equations COLORDODGE_KHR and COLORBURN_KHR be
        expressed mathematically?

      RESOLVED:  NVIDIA changed the definition of these equations after the
      NV_blend_equation_advanced spec was originally published, as discussed
      below.  These changes add new special cases to the COLORDODGE_KHR and
      COLORBURN_KHR equations that are found in newer compositing standard
      specifications and in a number of implementations of old and new
      standards.  They believe that the omission of the special case in other
      older specifications is a bug.  They have no plans to add new blend
      equation tokens to support "equivalent" modes without the new special
      case.  We are adopting the same approach in this extension.

      Note, however, that older versions of this extension and older NVIDIA
      drivers implementing it will lack these special cases.  A driver update
      may be required to get the new behavior.

      There is some disagreement in different published specifications about
      how these two blend equations should be handled.  At the time the NVIDIA
      extension was initially developed, all specifications they found that
      specified blending equations mathematically (see issue 28 of
      NV_blend_equation_advanced) were written the same way.  Since then, they
      discovered that newer working drafts of the W3C Compositing and Blending
      Level 1 specification (for CSS and SVG) express "color-burn" as follows
      (translated to our nomenclature):

        if (Cd == 1)            // their Cb (backdrop) is our Cd (destination)
          f(Cs,Cd) = 1          // their B() is our f()
        else if (Cs == 0)
          f(Cs,Cd) = 0
        else
          f(Cs,Cd) = 1 - min(1, (1-Cd)/Cs)

      http://www.w3.org/TR/2013/WD-compositing-1-20131010/
        #blendingcolorburn

      Earlier versions of the same W3C specification, an older SVG compositing
      draft specification, the Adobe PDF specification (and the ISO 32000-1
      standard), and the KHR_advanced_blending extension to OpenVG all specify
      the following equation without the initial special case:

        if (Cs == 0)
          f(Cs,Cd) = 0
        else
          f(Cs,Cd) = 1 - min(1, (1-Cd)/Cs)

        http://www.w3.org/TR/2012/WD-compositing-20120816/
          #blendingcolorburn
        http://www.w3.org/TR/2011/WD-SVGCompositing-20110315/
        http://www.adobe.com/content/dam/Adobe/en/devnet/acrobat/
          pdfs/pdf_reference_1-7.pdf
        http://www.khronos.org/registry/vg/extensions/KHR/
          advanced_blending.txt

      For the Adobe PDF specification, the corrected blend equations are
      published in an Adobe supplement to ISO 32000-1 and are expected to be
      accepted in a future version of the standard:

        http://wwwimages.adobe.com/www.adobe.com/content/dam/Adobe/en/
          devnet/pdf/pdfs/adobe_supplement_iso32000_1.pdf

      The author's understanding is that multiple shipping implementations of
      these blending modes implement the special case for "Cd==1" above,
      including various Adobe products and the open-source Ghostscript
      project.

      We believe that the extra special case in this specification is
      consistent with the physical model of color burning.  Burning is
      described in

        http://en.wikipedia.org/wiki/Dodging_and_burning

      as making a print with normal exposure, and then adding additional
      exposure to darken the overall image.  In the general equation:

        1 - min(1, (1-Cd)/Cs)

      Cs operates as a sort of fudge factor where a value of 1.0 implies no
      additional exposure time and 0.0 implies arbitrarily long additional
      exposure time, where the initial amount of exposure (1-Cd) is multiplied
      by 1/Cs and then clamped to maximum exposure by the min() operation.
      The Cd==1 special case here implies that we get zero exposure in the
      initial print, since 1-Cd==0.  No amount of extra exposure time will
      generate any additional exposure.  This would imply that the final
      result should have zero exposure and thus a final f() value of 1.  This
      matches the initial special case.  Without that special case, we would
      hit the second special case if Cs==0 (infinite exposure time), which
      would yield an incorrect final value of 0 (full exposure).

      A similar issue applies to COLORDODGE_KHR, where some specifications
      include a special case for Cb==0 while others do not.  We have added a
      special case there as well.

    (8) The NV_blend_equation_advanced extension has two variants:
        NV_blend_equation_advanced and NV_blend_equation_advanced_coherent.
        Some implementations of that extension are not capable of performing
        fully coherent blending when samples are touched more than once
        without a barrier, and may expose only the former.  Should we follow
        this pattern here or support only the "coherent" variant?

      RESOLVED:  Yes.  The working group originally decided to support only
      the "coherent" variant (revision 4) for simplicity but later decided to
      support both extension string entries as some implementations on both
      OpenGL and OpenGL ES are unable to support the "coherent" variant.
      Applications not wanting to manage coherency manually should look for
      the KHR_blend_equation_advanced_coherent extension and ignore
      KHR_blend_equation_advanced.

    (9) We don't permit the use of advanced blend equations with multiple draw
        buffers.  Should we produce compile-, link-, or draw-time errors if we
        encounter a shader that includes both (a) one or more layout
        qualifiers indicating that the shader wants to use advanced blending
        and (b) a color output with a location other than zero?

      RESOLVED:  No.

      In the current extension, there is a draw-time error generated if you
      try to use one of the new blend equations with multiple color targets
      (glDrawBuffers with a count > 1).  With this restriction, any "extra"
      fragment shader color outputs could never be successfully blended into
      the framebuffer with one of these equations.

      When only one draw buffer is enabled when using a shader with multiple
      outputs, "extra" outputs will simply be dropped and have no effect on
      the framebuffer.  You can already do this in unextended OpenGL and
      OpenGL ES without generating an error.  We didn't feel that the value of
      such a warning/error justifies the draw-time overhead needed to detect
      and report such a condition.

      Since this extension requires that you declare the intent to use
      advanced blending using layout qualifers, it is possible to identify a
      shader that may want to use "extra" color outputs with advanced blending
      at compile time, with no draw-time overhead.  We decided not to treat
      this condition as an error for several reasons:

       - Advanced blending layout qualifiers don't require that blending
         actually be enabled.  Multiple draw buffers with multiple outputs
         work just fine in that case.

       - If we treated this condition as an error and a future extension
         relaxed the DrawBuffers restriction, it would be necessary to also
         add a GLSL language feature to disable the now-undesirable error.

    (10) What happens when converting a premultiplied color with an alpha of
         zero to a non-premultiplied color?

      RESOLVED:  We specify that a premultiplied color of (0,0,0,0) should
      produce non-premultiplied (R,G,B) values of (0,0,0).  A premultiplied
      color with an alpha of zero and a non-zero R, G, or B component is
      considered to be ill-formed and will produce undefined blending results.

      For a non-premultiplied color (R',G',B',A'), the corresponding
      premultiplied color (R,G,B,A) should satisfy the equation:

        (R,G,B,A) = (R'*A', G'*A', B'*A', A')

      If the alpha of a non-premultiplied color is zero, the corresponding
      premultiplied color (R,G,B,A) should be (0,0,0,0).

      We specify that ill-formed premultiplied colors produce undefined
      blending results to enable certain performance optimizations.  In many
      of these blending equations, the alpha component used as a denominator
      to compute the non-premultiplied color ends up being multiplied by the
      same alpha component in the coverage, resulting in cancellation.  For
      example, implementations may want to substitute a premultiplied
      destination color into the last term of the basic blend equation:

        R = f(Rs',Rd')*p0(As,Ad) + Y*Rs'*p1(As,Ad) + Z*Rd'*p2(As,Ad)
          =                                    ... + Z*Rd'*(Ad*(1-As))
          =                                    ... + Z*(Rd'*Ad)*(1-As)
          =                                    ... + Z* Rd * (1-As)

      This substitution would be invalid for ill-formed premultiplied
      destination colors.  We choose to specify undefined results for invalid
      input colors rather than requiring implementations to skip such
      optimizations or include logic to check for zero alpha values for each
      input.

    (11) For "HSL" blend equations, the blend equation involves a clipping
         step where colors may be "clipped" if the blend would produce
         components are outside the range [0,1]. Are there inputs where this
         blend could produce ill-defined or nonsensical results?
         
      RESOLVED: Yes, the results of HSL blend equations are undefined if the
      input colors have components outside the range [0,1]. Even if the input
      colors are in-range, the basic color adjustment done in these blends
      could produce result components outside the range [0,1]. To compensate,
      the ClipColor() function in the specification interpolates the result
      color and a greyscale value that matches the luminance of the result.
      The math for the clipping operation assumes the luminance of the result
      color is in the range [0,1]. If that isn't the case, the clipping
      operation could result in a divide by zero (when all result components
      have the same out-of-bounds value) or perform an otherwise nonsensical
      computation.


Revision History

    Revision 17, February 14, 2018

      Fix ClipColor() equation where in the "if (maxcol > 1.0)" body the
      "(color-lum)*lum" term should have been "(color-lum)*(1-lum)". Also
      add new issue 11 for the case where the inputs to SetLum() are outside
      the range [0..1] and could cause a divide-by-zero in ClipColor().

    Revision 16, April 16, 2016 (from a September 30, 2014 edit that wasn't
                                 published)

      Fix incorrectly specified color clamping in the HSL blend modes.

    Revision 15, May 9, 2015

      Renumber as OpenGL ARB extension instead of vendor extension, by
      symmetry with other KHR Khronos-approved extensions. Add copyright
      notice.

    Revision 14, March 14, 2014

      Cast as KHR extension.

    Revisions 12 and 13, March 5, 2014

      For non-coherent blending, clarify that all writes to a sample are
      considered to "touch" that sample and require a BlendBarrierKHR call
      before blending overlapping geometry.  Clears, non-blended geometry, and
      copies by BlitFramebuffer or TexSubImage are all considered to "touch" a
      sample (bug 11738).  Specify that non-premultiplied values corresponding
      to ill-conditioned premultiplied colors such as (1,1,1,0) are undefined
      (bug 11739).  Add issue (10) related to the ill-conditioned
      premultiplied color issue.

    Revision 11, January 30, 2014

      Cast as OES extension.

    Revision 10, January 22, 2014

      Add issue (9), where we decided not to add compile- or link-time errors
      when using both advanced blending and multiple color outputs (bug
      11468).

    Revision 9, January 2, 2014

      Fix typo in issue (0).

    Revision 8, November 6, 2013

      Restore support for non-coherent-only implementations that was removed
      in revision 4.  Fix the language about non-coherent blending to specify
      that results are undefined only if an individual *sample* is touched
      more than once (instead of *pixel*).  Minor language tweaks to use
      "equations" consistently, instead of sometimes using "modes".

    Revision 7, October 21, 2013

      Add a reference to the Adobe supplement to ISO 32000-1, which includes
      the corrected equations for COLORDODGE_NV and COLORBURN_NV.  Move
      "NVIDIA Implementation Details" down a bit in the spec.

    Revision 6, October 16, 2013

      Add new special cases for COLORDODGE_KHR and COLORBURN_KHR, as described
      in issue (7).  Mark issue (7) as resolved.

    Revision 5, October 15, 2013

      Remove Porter-Duff blend equations from the specification (issue 4).
      Add a Draw-time error if an advanced blending equation is used without
      specifying a matching layout qualifier in the fragment shader (issue 5).

      Add issues for the spec issues discussed during standardization in
      Khronos.  Remove OpenGL ES 2.0 and 3.0 interactions dealing with
      handling tokens present in OpenGL but not the core OpenGL ES
      specification, since the relevant equations (ZERO and XOR) have been
      removed.

    Revision 4, September 6, 2013

      Removed support for non-coherent-only implementations.  Implementations
      that could support NV_blend_equation_advanced (app-managed coherency
      only) but not NV_blend_equation_advanced_coherent will be unable to
      support this extension.

    Revision 3, August 19, 2013

      Fixed typos in the OpenGL ES 2.0 and 3.0 interactions section of
      NV_blend_equation_advanced.

    Revision 2, August 13, 2013

      Removed issues from the original NV_blend_equation_advanced
      specification.  Rename "NV" prefixes and suffixes to "XXX" since the
      future status of this extension is unknown.  Remove the
      BlendParameterivNV function and the BLEND_PREMULTIPLIED_SRC_NV and
      BLEND_OVERLAP_NV parameters.  Source colors are assumed to be
      premultiplied.  The source and destination pixel coverage, derived from
      their respective alpha components, is assumed to be uncorrelated.
      Removed the miscellaneous blend modes (PLUS_NV, PLUS_CLAMPED_NV,
      PLUS_CLAMPED_ALPHA_NV, PLUS_DARKER_NV, MINUS_NV, MINUS_CLAMPED_NV,
      CONTRAST_NV, INVERT_OVG_NV, RED, GREEN, BLUE) from Table X.4 of
      NV_blend_equation_advanced.  Removed some of the less common "X/Y/Z"
      blend modes (INVERT, INVERT_RGB_NV, LINEARDODGE_NV, LINEARBURN_NV,
      VIVIDLIGHT_NV, LINEARLIGHT_NV, PINLIGHT_NV, HARDMIX_NV).  Add layout
      qualifiers to the OpenGL Shading Language to indicate the set of
      advanced blend equations are supported with a particular fragment
      shader; using blend equations not identified in the current fragment
      shader result in undefined blending results.

    Revision 1, August 13, 2013

      Forked the original NV_blend_equation_advanced specification.