KHR_blend_equation_advanced

GL_KHR_blend_equation_advanced
GL_KHR_blend_equation_advanced_coherent

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

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

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

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

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

Last Modified Date:         February 14, 2018
Revision:                   17

ARB Extension #174
OpenGL ES Extension #168

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.

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.

void BlendBarrierKHR(void);

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.

None.

None.

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.

None.

None.

None.

None.

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.

!!! TBD

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

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.

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.

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.

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.

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

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

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.

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.

None.

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