| Name |
| |
| INTEL_shader_atomic_float_minmax |
| |
| Name Strings |
| |
| GL_INTEL_shader_atomic_float_minmax |
| |
| Contact |
| |
| Ian Romanick (ian . d . romanick 'at' intel . com) |
| |
| Contributors |
| |
| |
| Status |
| |
| In progress |
| |
| Version |
| |
| Last Modified Date: 06/22/2018 |
| Revision: 4 |
| |
| Number |
| |
| TBD |
| |
| Dependencies |
| |
| OpenGL 4.2, OpenGL ES 3.1, ARB_shader_storage_buffer_object, or |
| ARB_compute_shader is required. |
| |
| This extension is written against version 4.60 of the OpenGL Shading |
| Language Specification. |
| |
| Overview |
| |
| This extension provides GLSL built-in functions allowing shaders to |
| perform atomic read-modify-write operations to floating-point buffer |
| variables and shared variables. Minimum, maximum, exchange, and |
| compare-and-swap are enabled. |
| |
| |
| New Procedures and Functions |
| |
| None. |
| |
| New Tokens |
| |
| None. |
| |
| IP Status |
| |
| None. |
| |
| Modifications to the OpenGL Shading Language Specification, Version 4.60 |
| |
| Including the following line in a shader can be used to control the |
| language features described in this extension: |
| |
| #extension GL_INTEL_shader_atomic_float_minmax : <behavior> |
| |
| where <behavior> is as specified in section 3.3. |
| |
| New preprocessor #defines are added to the OpenGL Shading Language: |
| |
| #define GL_INTEL_shader_atomic_float_minmax 1 |
| |
| Additions to Chapter 8 of the OpenGL Shading Language Specification |
| (Built-in Functions) |
| |
| Modify Section 8.11, "Atomic Memory Functions" |
| |
| (add a new row after the existing "atomicMin" table row, p. 179) |
| |
| float atomicMin(inout float mem, float data) |
| |
| |
| Computes a new value by taking the minimum of the value of data and |
| the contents of mem. If one of these is an IEEE signaling NaN (i.e., |
| a NaN with the most-significant bit of the mantissa cleared), it is |
| always considered smaller. If one of these is an IEEE quiet NaN |
| (i.e., a NaN with the most-significant bit of the mantissa set), it is |
| always considered larger. If both are IEEE quiet NaNs or both are |
| IEEE signaling NaNs, the result of the comparison is undefined. |
| |
| (add a new row after the exiting "atomicMax" table row, p. 179) |
| |
| float atomicMax(inout float mem, float data) |
| |
| Computes a new value by taking the maximum of the value of data and |
| the contents of mem. If one of these is an IEEE signaling NaN (i.e., |
| a NaN with the most-significant bit of the mantissa cleared), it is |
| always considered larger. If one of these is an IEEE quiet NaN (i.e., |
| a NaN with the most-significant bit of the mantissa set), it is always |
| considered smaller. If both are IEEE quiet NaNs or both are IEEE |
| signaling NaNs, the result of the comparison is undefined. |
| |
| (add to "atomicExchange" table cell, p. 180) |
| |
| float atomicExchange(inout float mem, float data) |
| |
| (add to "atomicCompSwap" table cell, p. 180) |
| |
| float atomicCompSwap(inout float mem, float compare, float data) |
| |
| Interactions with OpenGL 4.6 and ARB_gl_spirv |
| |
| If OpenGL 4.6 or ARB_gl_spirv is supported, then |
| SPV_INTEL_shader_atomic_float_minmax must also be supported. |
| |
| The AtomicFloatMinmaxINTEL capability is available whenever the OpenGL or |
| OpenGL ES implementation supports INTEL_shader_atomic_float_minmax. |
| |
| Issues |
| |
| 1) Why call this extension INTEL_shader_atomic_float_minmax? |
| |
| RESOLVED: Several other extensions already set the precedent of |
| VENDOR_shader_atomic_float and VENDOR_shader_atomic_float64 for extensions |
| that enable floating-point atomic operations. Using that as a base for |
| the name seems logical. |
| |
| There already exists NV_shader_atomic_float, but the two extensions have |
| nearly zero overlap in functionality. NV_shader_atomic_float adds |
| atomicAdd and image atomic operations that currently shipping Intel GPUs |
| do not support. Calling this extension INTEL_shader_atomic_float would |
| likely have been confusing. |
| |
| Adding something to describe the actual functions added by this extension |
| seemed reasonable. INTEL_shader_atomic_float_compare was considered, but |
| that name was deemed to be not properly descriptive. Calling this |
| extension INTEL_shader_atomic_float_min_max_exchange_compswap is right |
| out. |
| |
| 2) What atomic operations should we support for floating-point targets? |
| |
| RESOLVED. Exchange, min, max, and compare-swap make sense, and these are |
| all supported by the hardware. Future extensions may add other functions. |
| |
| For buffer variables and shared variables it is not possible to bit-cast |
| the memory location in GLSL, so existing integer operations, such as |
| atomicOr, cannot be used. However, the underlying hardware implementation |
| can do this by treating the memory as an integer. It would be possible to |
| implement atomicNegate using this technique with atomicXor. It is unclear |
| whether this provides any actual utility. |
| |
| 3) What should be said about the NaN behavior? |
| |
| RESOLVED. There are several aspects of NaN behavior that should be |
| documented in this extension. However, some of this behavior varies based |
| on NaN concepts that do not exist in the GLSL specification. |
| |
| * atomicCompSwap performs the comparison as the floating-point equality |
| operator (==). That is, if either 'mem' or 'compare' is NaN, the |
| comparison result is always false. |
| |
| * atomicMin and atomicMax implement the IEEE specification with respect to |
| NaN. IEEE considers two different kinds of NaN: signaling NaN and quiet |
| NaN. A quiet NaN has the most significant bit of the mantissa set, and |
| a signaling NaN does not. This concept does not exist in SPIR-V, |
| Vulkan, or OpenGL. Let qNaN denote a quiet NaN and sNaN denote a |
| signaling NaN. atomicMin and atomicMax specifically implement |
| |
| - fmin(qNaN, x) = fmin(x, qNaN) = fmax(qNaN, x) = fmax(x, qNaN) = x |
| - fmin(sNaN, x) = fmin(x, sNaN) = fmax(sNaN, x) = fmax(x, sNaN) = sNaN |
| - fmin(sNaN, qNaN) = fmin(qNaN, sNaN) = fmax(sNaN, qNaN) = |
| fmax(qNaN, sNaN) = sNaN |
| - fmin(sNaN, sNaN) = sNaN. This specification does not define which of |
| the two arguments is stored. |
| - fmax(sNaN, sNaN) = sNaN. This specification does not define which of |
| the two arguments is stored. |
| - fmin(qNaN, qNaN) = qNaN. This specification does not define which of |
| the two arguments is stored. |
| - fmax(qNaN, qNaN) = qNaN. This specification does not define which of |
| the two arguments is stored. |
| |
| Further details are available in the Skylake Programmer's Reference |
| Manuals available at |
| https://01.org/linuxgraphics/documentation/hardware-specification-prms. |
| |
| 4) What about atomicMin and atomicMax with (+0.0, -0.0) or (-0.0, +0.0) |
| arguments? |
| |
| RESOLVED. atomicMin should store -0.0, and atomicMax should store +0.0. |
| Due to a known issue in shipping Skylake GPUs, the incorrectly signed 0 is |
| stored. This behavior may change in later GPUs. |
| |
| Revision History |
| |
| Rev Date Author Changes |
| --- ---------- -------- --------------------------------------------- |
| 1 04/19/2018 idr Initial version |
| 2 05/05/2018 idr Describe interactions with the capabilities |
| added by SPV_INTEL_shader_atomic_float_minmax. |
| 3 05/29/2018 idr Remove mention of 64-bit float support. |
| 4 06/22/2018 idr Resolve issue #2. |
| Add issue #3 (regarding NaN behavior). |
| Add issue #4 (regarding atomicMin(-0, +0). |
