[Mesa-dev] [PATCH 03/13] docs: Initial version of INTEL_shader_atomic_float_minmax spec
From: Ian Romanick v2: Describe interactions with the capabilities added by SPV_INTEL_shader_atomic_float_minmax v3: Remove 64-bit float support. v4: Explain NaN issues. Explain issues with atomicMin(-0, +0) and atomicMax(-0, +0). Signed-off-by: Ian Romanick --- docs/specs/INTEL_shader_atomic_float_minmax.txt | 200 1 file changed, 200 insertions(+) create mode 100644 docs/specs/INTEL_shader_atomic_float_minmax.txt diff --git a/docs/specs/INTEL_shader_atomic_float_minmax.txt b/docs/specs/INTEL_shader_atomic_float_minmax.txt new file mode 100644 index 000..5c8322ce5a6 --- /dev/null +++ b/docs/specs/INTEL_shader_atomic_float_minmax.txt @@ -0,0 +1,200 @@ +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 : + +where 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 +extensi
Re: [Mesa-dev] [PATCH 03/13] docs: Initial version of INTEL_shader_atomic_float_minmax spec
Hello, > +(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., The two lines above have different indentations, maybe the "Computes..." line should be starting with a TAB. > +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. Couldn't find the SPIR-V extension, but I guess is work in progress. Is there a Vulkan extension too? > +* 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 For the two items above, is it implicit that the result will be quietized? This matters when using such result with other operation with a real value, e.g. is "fmin(fmin(x, sNaN), y)" equals to "y" or to "sNaN"? The PRM for Skylake says "Max(x, sNaN) = Max(sNaN, x) = qNaN (quietized value corresponding to the input sNaN) and signal the Invalid Operation exception." Thanks, Caio ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 03/13] docs: Initial version of INTEL_shader_atomic_float_minmax spec
On 08/16/2018 06:02 PM, Caio Marcelo de Oliveira Filho wrote: > Hello, > >> +(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., > > The two lines above have different indentations, maybe the > "Computes..." line should be starting with a TAB. I'll check the indentation. It should all be spaces, but there may be issues. >> +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. > > Couldn't find the SPIR-V extension, but I guess is work in > progress. Is there a Vulkan extension too? Both are in-progress, yeah. >> +* 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 > > For the two items above, is it implicit that the result will be > quietized? This matters when using such result with other operation > with a real value, e.g. is "fmin(fmin(x, sNaN), y)" equals to "y" or > to "sNaN"? > > The PRM for Skylake says > > "Max(x, sNaN) = Max(sNaN, x) = qNaN (quietized value corresponding > to the input sNaN) and signal the Invalid Operation exception." That is interesting... the Bspec says something similar, but it has an extra note that sNaN is not quieted on SKL+. It /seems/ like this was intention and won't be changed. My tests on SKL seem to confirm that, with respect to fmin and fmax, once you have sNaN, you will always have sNaN. > Thanks, > Caio ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
