NV_blend_minmax_factor

GL_NV_blend_minmax_factor

Jeff Bolz
Pierre Boudier
Charles Hansen
Bill Sebastian, Visual Music Systems
Graham Sellers, original AMD specification

Mark Kilgard, NVIDIA (mjk 'at' nvidia.com)

Implemented in NVIDIA's August 2017 SIGGRAPH driver

Last Modified Date:         July 26, 2017
Author Revision:            3

OpenGL Extension #510
OpenGL ES Extension #285

The extension is written against the OpenGL 4.1 (Core) Specification.

OpenGL 1.0 or ES 2.0 is required.

This extension interacts with
NVX_blend_equation_advanced_multi_draw_buffers as specified.

This extension interacts with ARB_blend_func_extended,
EXT_blend_func_extended (for ES), or OpenGL 3.3 as specified.

This extension interacts with NV_blend_equation_advanced,
NV_blend_equation_advanced_coherent, KHR_blend_equation_advanced,
KHR_blend_equation_advanced_coherent, OpenGL 4.5, or ES 3.2 as
specified.

The EXT_blend_minmax extension extended the GL's blending
functionality to allow the blending equation to be specified by the
application. That extension introduced the MIN_EXT and MAX_EXT blend
equations, which caused the result of the blend equation to become
the minimum or maximum of the source color and destination color,
respectively.

The MIN_EXT and MAX_EXT blend equations, however, do not include the
source or destination blend factors in the arguments to the min and
max functions.  This extension provides two new blend equations that
produce the minimum or maximum of the products of the source color
and source factor, and the destination color and destination factor.

This NVIDIA extension has some limitations relative to the
AMD_blend_minmax_factor extension.  See issues #1, #2, and #3.

None.

Accepted by the <mode> parameter of BlendEquation and BlendEquationi, and by
the <modeRGB> and <modeAlpha> parameters of BlendEquationSeparate and
BlendEquationSeparatei:

    FACTOR_MIN_AMD                              0x901C
    FACTOR_MAX_AMD                              0x901D

None.

None.

Modify the list of accepted tokens for <mode>, <modeRGB> and <modeAlpha>
in the description of BlendEquation{i} and BlendEquationSeparate{i}, p.262:

"... <mode>, <modeRGB>, <modeAlpha> must be one of FUNC_ADD, FUNC_SUBTRACT,
FUNC_REVERSE_SUBTRACT, MIN, MAX, FACTOR_MIN_AMD, or FACTOR_MAX_AMD. ..."

Add to Table 4.1: RGB and Alpha Blend Equations

+-----------------+---------------------------+-----------------------------+
| Mode            | RGB Components            | Alpha Component             |
+-----------------+---------------------------+-----------------------------+
| FACTOR_MIN_AMD  | R = min(Rs * Sr, Rd * Dr) | A = min(As * Sa, Ad * Da)   |
|                 | G = min(Gs * Sg, Gd * Dg) |                             |
|                 | B = min(Bs * Sb, Bd * Db) |                             |
+-----------------+---------------------------+-----------------------------+
| FACTOR_MAX_AMD  | R = max(Rs * Sr, Rd * Dr) | A = max(As * Sa, Ad * Da)   |
|                 | G = max(Gs * Sg, Gd * Dg) |                             |
|                 | B = max(Bs * Sb, Bd * Db) |                             |
+-----------------+---------------------------+-----------------------------+

Add the following precision limitation after table 4.1:

"An implementation may perform the computations for the FACTOR_MIN_AMD
and FACTOR_MAX_AMD modes in half-precsion floating-point even
when the representable range of the framebuffer is can represent
single-precision or better color components."

Add the following orthogonality restriction after table 4.1:

"When the NVX_blend_equation_advanced_multi_draw_buffers is not
supported, the FACTOR_MIN_AMD and FACTOR_MAX_AMD blending equations
are supported only when rendering to a single color buffer using
fragment color zero.  In this case, if any non-NONE draw buffer
enabled for blending uses either the FACTOR_MIN_AMD and FACTOR_MAX_AMD
blending equations, the error INVALID_OPERATION is generated by
[[Compatibility Profile:  Begin or any operation that implicitly
calls Begin (such as DrawElements)]] [[Core Profile:  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.

Alternatively when the NVX_blend_equation_advanced_multi_draw_buffers
is supported, if any non-NONE draw buffer enabled for blending uses
a blend equation of either FACTOR_MIN_AMD or FACTOR_MAX_AMD for
either RGB or alpha, the error INVALID_OPERATION is generated by
[[Compatibility Profile:  Begin or any operation that implicitly
calls Begin (such as DrawElements)]] [[Core Profile:  DrawArrays
and the other drawing commands defined in section 2.8.3]] if any
other non-NONE draw buffer uses a different combination of the
first draw buffer's RGB and alpha blend equation." In other words,
the FACTOR_MIN_AMD or FACTOR_MAX_AMD blend equations are now allowed
with multiple draw buffers as long as they use they use identical
blend equations for RGB and alpha for all non-NONE draw buffers.

If any non-NONE draw buffer enabled for blending uses any of
SRC1_COLOR, SRC1_ALPHA, ONE_MINUS_SRC1_COLOR, or ONE_MINUS_SRC1_ALPHA
for a source or destination blend function, the error
INVALID_OPERATION is generated by [[Compatibility Profile:  Begin or
any operation that implicitly calls Begin (such as DrawElements)]]
[[Core Profile:  DrawArrays and the other drawing commands defined
in section 2.8.3]]."

None.

None.

None.

None.

None.

Modify Table 6.21: Pixel Operations (cont.) p.343

Change entries for BLEND_EQUATION_ALPHA and BLEND_EQUATION_RGB to:

+----------------------+---------+---------------+---------------+-------------------------+-------+
| Get Value            | Type    | Get Command   | Initial Value | Description             | Sec.  |
+----------------------+---------+---------------+---------------+-------------------------+-------+
| BLEND_EQUATION_RGB   | 8* x Z7 | GetIntegeri_v | FUNC_ADD      | RGB Blending Equation   | 4.1.7 |
|                      |         |               |               | for Draw Buffer i       |       |
+----------------------+---------+---------------+---------------+-------------------------+-------+
| BLEND_EQUATION_ALPHA | 8* x Z7 | GetIntegeri_v | FUNC_ADD      | Alpha Blending Equation | 4.1.7 |
|                      |         |               |               | for Draw Buffer i       |       |
+----------------------+---------+---------------+---------------+-------------------------+-------+

* Note that the only change change is that BLEND_EQUATION_RGB and
  BLEND_EQUATION_ALPHA are now Z7 rather than Z5.

1)  Why not just implement AMD_blend_factor_minmax?

    RESOLVED:  NVIDIA has a precision limitation and orthogonality
    restrictions.

    Rather than pollute the AMD extension with an incomplete
    implementation, this comparable NV version is API-consistent
    (uses the same token values) and same blending math but documents
    its precision limitation and restrictions.

2)  What is the precision limitation?

    The GL_FACTOR_MIN_AMD and GL_FACTOR_MAX_AMD blend functions are
    allowed to compute their blend results in half-precision even
    when the framebuffer format is single-precision.  In practice,
    this means the blend modes work but will quantize results
    to the representable range of half-precision, even if the
    framebuffer is full precision.

    This limitation matches the allowance of the advanced blend
    equations introduced by NV_blend_equation_advanced (and
    standardized by KHR_blend_equation and OpenGL 4.5 and ES 3.2).

    This means magnitudes beyond the largest representable magnitude
    of half-precision may be mapped to infinity.  Magnitudes less
    than the smallest representable non-zero magnitude may be mapped
    to zero.  Mantissa bits may be quantied.

    While this limitation allows implementations to perform these
    blend modes in half-precision, it does not require the blend
    modes to be performed in half-precsion.  Implementations are
    allowed to blend with better numerics than half-precision.
    This being said, expect NVIDIA implementations circa 2017 to
    implement these blend modes using half-precision numerics.

3)  What are the orthogonality restrictions?

    If more than one draw buffer is configured
    with glDrawBuffers (or similar command) and
    NVX_blend_equation_advanced_multi_draw_buffers is supported and at
    least one of the non-NONE draw buffers has GL_FACTOR_MIN_AMD or
    GL_FACTOR_MAX_AMD configured as the buffer's RGB or alpha blend
    equation, then all non-NONE draw buffers must have identical
    blend equations configuration for RGB and alpha; otherwise the
    error GL_INVALID_OPERATION is generated.

    If more than one draw buffer is configured
    with glDrawBuffers (or similar command) and
    NVX_blend_equation_advanced_multi_draw_buffers is NOT
    supported and any one or more of the non-NONE draw buffers has
    GL_FACTOR_MIN_AMD or GL_FACTOR_MAX_AMD configured as the buffer's
    blend equation, the error GL_INVALID_OPERATION is generated.

    If any source or destination blend factor is one of GL_SRC1_COLOR
    for that  draw buffer, GL_SRC1_ALPHA, GL_ONE_MINUS_SRC1_COLOR,
    or GL_ONE_MINUS_SRC1_ALPHA (the dual-source blending factors
    introduced by ARB_blend_func_extended and EXT_blend_func_extended
    and standardized by OpenGL 3.3) for a given enabled draw buffer,
    the error GL_INVALID_OPERATION is generated.

4)  Do the blend parameters GL_BLEND_PREMULTIPLIED_SRC_NV and
    GL_BLEND_OVERLAP_NV apply to GL_FACTOR_MIN_AMD and GL_FACTOR_MAX_AMD.

    RESOLVED:  No.

    These blend parameters are intended to affect advanced blend modes
    expressed as RGBA compositing operators.  GL_FACTOR_MIN_ARM and
    GL_FACTOR_MAX_AMD can be used separately for RGB and alpha so these
    blend parameters should not apply to them.

5)  Will these blend modes be coherent
    if NV_blend_equation_advanced_coherent or
    KHR_blend_equation_advanced_coherent are not supported?

    RESOLVED:  No, but they should still operate if
    NV_blend_minmax_factor is advertised.  glBlendBarrierNV or
    glBlendBarrierKHR will be needed to ensure coherency for
    overlapping primitives.

6)  What NVIDIA GPUs can be expected to implement this extension?

    RESOLVED:  The same set that advertise
    KHR_blend_equation_advanced_coherent and
    NV_blend_equation_advanced_coherent.

    In practice, this is Maxwell GPUs and beyond.

7)  Does this extension support OpenGL ES?

    RESOLVED:  Yes.

Rev.    Date      Author    Changes
----  --------    --------  -----------------------------------------
 3    07/26/2017  mjk       public release