1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
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 : <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).
|
