Use 'workgroup' instead of 'work group' per earlier ARB decision
diff --git a/extensions/ARB/ARB_compute_shader.txt b/extensions/ARB/ARB_compute_shader.txt
index 1505f4a..4899269 100644
--- a/extensions/ARB/ARB_compute_shader.txt
+++ b/extensions/ARB/ARB_compute_shader.txt
@@ -29,7 +29,7 @@
Version
- Last Modified Date: December 7, 2018
+ Last Modified Date: December 10, 2018
Revision: 28
Number
@@ -356,57 +356,57 @@
COMPUTE_SHADER. They are attached to and used in program objects as
described in section 2.11.3.
- Compute workloads are formed from groups of work items called work
- groups and processed by the executable code for a compute program. A work
- group is a collection of shader invocations that execute the same code,
- potentially in parallel. An invocation within a work group may share data
- with other members of the same work group through shared variables and
+ Compute workloads are formed from groups of work items called
+ _workgroups_ and processed by the executable code for a compute program.
+ A workgroup is a collection of shader invocations that execute the same code,
+ potentially in parallel. An invocation within a workgroup may share data
+ with other members of the same workgroup through shared variables and
issue memory and control barriers to synchronize with other members of the
- same work group. One or more work groups is launched by calling:
+ same workgroup. One or more workgroups is launched by calling:
void DispatchCompute(uint num_groups_x,
uint num_groups_y,
uint num_groups_z);
- Each work group is processed by the active program object for the
+ Each workgroup is processed by the active program object for the
compute shader stage. The error INVALID_OPERATION will be generated if
there is no active program object for the compute shader stage. The
active program for the compute shader stage will be determined in the same
manner as the active program for other pipeline stages, as described in
- section 2.11.3. While the individual shader invocations within a work
- group are executed as a unit, work groups are executed completely
+ section 2.11.3. While the individual shader invocations within a
+ workgroup are executed as a unit, workgroups are executed completely
independently and in unspecified order.
<num_groups_x>, <num_groups_y> and <num_groups_z> specify the number of
- work groups that will be dispatched in the X, Y and Z dimensions,
+ workgroups that will be dispatched in the X, Y and Z dimensions,
respectively. The builtin vector variable gl_NumWorkGroups will be
initialized with the contents of the <num_groups_x>, <num_groups_y> and
- <num_groups_z> parameters. The maximum number of work groups that may be
+ <num_groups_z> parameters. The maximum number of workgroups that may be
dispatched at one time may be determined by calling GetIntegeri_v with
<pname> set to MAX_COMPUTE_WORK_GROUP_COUNT and <index> must be zero, one,
or two, representing the X, Y, and Z dimensions, respectively. The
values in the <num_groups_x>, <num_groups_y> and <num_groups_z> array must
- be less than or equal to the maximum work group count for the corresponding
- dimension, otherwise an INVALID_VALUE error is generated. If the work group
- count in any dimension is zero, no work groups are dispatched.
+ be less than or equal to the maximum workgroup count for the corresponding
+ dimension, otherwise an INVALID_VALUE error is generated. If the workgroup
+ count in any dimension is zero, no workgroups are dispatched.
- The work group size in each dimension are specified at compile time
+ The workgroup size in each dimension are specified at compile time
using an input layout qualifier in one or more of the compute shaders
attached to the program (see Section 4 of the OpenGL Shading Language
- Specification). After the program has been linked, the work group size
+ Specification). After the program has been linked, the workgroup size
of the program may be retrieved by calling GetProgramiv with <pname> set to
COMPUTE_WORK_GROUP_SIZE. This will return an array of three integers
- containing the work group size of the compute program as specified by
+ containing the workgroup size of the compute program as specified by
its input layout qualifier(s). If <program> is the name of a program that
has not been successfully linked, or is the name of a linked program object
that contains no compute shaders, then an INVALID_OPERATION error is
generated.
- The maximum size of a work group may be determined by calling
+ The maximum size of a workgroup may be determined by calling
GetIntegeri_v with <pname> set to MAX_COMPUTE_WORK_GROUP_SIZE
and <index> set to 0, 1, or 2 to retrieve the maximum work size in the
X, Y and Z dimension, respectively. Furthermore, the maximum number of
- invocations in a single work group (i.e., the product of the three
+ invocations in a single workgroup (i.e., the product of the three
dimensions) may be determined by calling GetIntegerv with <pname> set to
MAX_COMPUTE_WORK_GROUP_INVOCATIONS.
@@ -479,11 +479,11 @@
and its visible side effects are through actions on images, storage
buffers, and atomic counters.
- A compute shader operates on a group of work items called a work group.
- A work group is a collection of shader invocations that execute the same
- code, potentially in parallel. An invocation within a work group may share data with
- other members of the same work group through shared variables and issue
- memory and control barriers to synchronize with other members of the same work group."
+ A compute shader operates on a group of work items called a workgroup.
+ A workgroup is a collection of shader invocations that execute the same
+ code, potentially in parallel. An invocation within a workgroup may share data with
+ other members of the same workgroup through shared variables and issue
+ memory and control barriers to synchronize with other members of the same workgroup."
Additions to Chapter 4 of the OpenGL Shading Language Specification, Version
4.20 (Variables and Types)
@@ -503,7 +503,7 @@
| Storage Qualifier | Meaning |
+-------------------+-----------------------------------------------------------+
| <shared> | variable storage is shared across all work items in a |
- | | work group for compute shaders |
+ | | workgroup for compute shaders |
+-------------------+-----------------------------------------------------------+
Add the following paragraph to Section 4.3.4, "Input Variables"
@@ -526,16 +526,16 @@
Add Section 4.3.7, "Shared", renumber subsequent sections
The <shared> qualifier is used to declare variables that have storage
- shared between all work items of a compute shader work
- group. Variables declared as <shared> may only be used in compute shaders
+ shared between all work items of a compute shader workgroup.
+ Variables declared as <shared> may only be used in compute shaders
(see Section 5.5, "Compute Shaders"). Shared variables are implicitly
coherent. That is, writes to shared variables from one shader invocation
- will eventually be seen by other invocations within the same work group.
+ will eventually be seen by other invocations within the same workgroup.
Variables declared as <shared> may not have initializers and their
contents are undefined at the beginning of shader execution. Any data
written to <shared> variables will be visible to other shaders executing
- the same shader within the same work group. Order of execution
+ the same shader within the same workgroup. Order of execution
with regards to reads and writes to the same <shared> variables by different
invocations of a shader is not defined. In order to achieve ordering with
respect to reads and writes to <shared> variables, memory barriers must be
@@ -550,7 +550,7 @@
There are no layout location qualifiers for compute shader inputs.
- Layout qualifier identifiers for compute shader inputs are the work group
+ Layout qualifier identifiers for compute shader inputs are the workgroup
size qualifiers:
layout-qualifier-id
@@ -583,12 +583,12 @@
maximum size supported by the implementation for that dimension, a
compile-time error results. Also, if such a layout qualifier is declared more
than once in the same shader, all those declarations must indicate the same
- work group size; otherwise a compile-time error results. If multiple compute
- shaders attached to a single program object declare the work group size,
+ workgroup size; otherwise a compile-time error results. If multiple compute
+ shaders attached to a single program object declare the workgroup size,
the declarations must be identical; otherwise a link-time error results.
Furthermore, if a program object contains any compute shaders, at
- least one must contain an input layout qualifier specifying the work
- group sizes of the program, or a link-time error will occur.
+ least one must contain an input layout qualifier specifying the
+ workgroup sizes of the program, or a link-time error will occur.
Additions to Chapter 7 of the OpenGL Shading Language Specification, Version
4.20 (Built-in Variables)
@@ -598,11 +598,11 @@
In the compute language, the built-in variables are declared as follows:
- // work group dimensions
+ // workgroup dimensions
in uvec3 gl_NumWorkGroups;
const uvec3 gl_WorkGroupSize;
- // work group and invocation IDs
+ // workgroup and invocation IDs
in uvec3 gl_WorkGroupID;
in uvec3 gl_LocalInvocationID;
@@ -614,37 +614,37 @@
The built-in variable <gl_NumWorkGroups> is a compute-shader input
variable containing the total number of global work items in each
- dimension of the work group that will execute the compute shader.
+ dimension of the workgroup that will execute the compute shader.
Its content is equal to the values specified in the <num_groups_x>,
<num_groups_y>, and <num_groups_z> parameters passed to the
DispatchCompute API entry point.
The built-in constant <gl_WorkGroupSize> is a compute-shader constant
- containing the work group size of the shader. The size of the work
- group in the X, Y, and Z dimensions is stored in the x, y, and z components.
+ containing the workgroup size of the shader. The size of the workgroup
+ in the X, Y, and Z dimensions is stored in the x, y, and z components.
The values stored in <gl_WorkGroupSize> match those specified in the
required <local_size_x>, <local_size_y>, and <local_size_z> layout
qualifiers for the current shader. This value is constant so that
it can be used to size arrays of memory that can be shared within
- the work group.
+ the workgroup.
The built-in variable <gl_WorkGroupID> is a compute-shader input
- variable containing the 3-dimensional index of the global work group
+ variable containing the 3-dimensional index of the global workgroup
that the current invocation is executing in. The possible values range
across the parameters passed into DispatchCompute, i.e., from (0, 0, 0) to
(gl_NumWorkGroups.x - 1, gl_NumWorkGroups.y - 1, gl_NumWorkGroups.z - 1).
The built-in variable <gl_LocalInvocationID> is a compute-shader input
- variable containing the 3-dimensional index of the work group
- within the global work group that the current invocation is executing in.
- The possible values for this variable range across the work group
+ variable containing the 3-dimensional index of the workgroup
+ within the global workgroup that the current invocation is executing in.
+ The possible values for this variable range across the workgroup
size, i.e. (0,0,0) to (gl_WorkGroupSize.x - 1, gl_WorkGroupSize.y - 1,
gl_WorkGroupSize.z - 1).
The built-in variable <gl_GlobalInvocationID> is a compute shader input
variable containing the global index of the current work item. This
value uniquely identifies this invocation from all other invocations
- across all work groups initiated by the current
+ across all workgroups initiated by the current
DispatchCompute call. This is computed as:
gl_GlobalInvocationID =
@@ -653,8 +653,9 @@
The built-in variable <gl_LocalInvocationIndex> is a compute shader
input variable that contains the 1-dimensional representation of the
gl_LocalInvocationID. This is useful for uniquely identifying a
- unique region of shared memory within the work group for this
+ unique region of shared memory within the workgroup for this
invocation to use. This is computed as:
+
gl_LocalInvocationIndex =
gl_LocalInvocationID.z * gl_WorkGroupSize.x * gl_WorkGroupSize.y +
gl_LocalInvocationID.y * gl_WorkGroupSize.x +
@@ -686,7 +687,7 @@
The shader invocation control function is only available in tessellation
control shaders and compute shaders. It is used to control the relative
execution order of multiple shader invocations used to process a patch
- (in the case of tessellation control shaders) or a work group (in the
+ (in the case of tessellation control shaders) or a workgroup (in the
case of compute shaders), which are otherwise executed with an undefined
order.
@@ -695,7 +696,7 @@
+----------------+--------------------------------------------------------------------------+
| barrier | For any given static instance of barrier() appearing in a tessellation |
| | control shader or compute shader, all invocations for a single patch |
- | | or work group, respectively, must enter it before any will continue |
+ | | or workgroup, respectively, must enter it before any will continue |
| | beyond it. |
+----------------+--------------------------------------------------------------------------+
@@ -749,7 +750,7 @@
| | Only available in compute shaders. |
+-----------------------------------+----------------------------------------------------------------------------------------+
| void groupMemoryBarrier() | Control the ordering of all memory transactions issued within a single shader |
- | | invocation, as viewed by other invocations in the same work group. |
+ | | invocation, as viewed by other invocations in the same workgroup. |
| | Only available in compute shaders. |
+-----------------------------------+----------------------------------------------------------------------------------------+
@@ -788,7 +789,7 @@
stores, selected other shader invocations will never see the results of
the second store before seeing those of the first. When using the
function groupMemoryBarrier(), this ordering guarantee applies only to
- other shader invocations in the same compute shader work group; all other
+ other shader invocations in the same compute shader workgroup; all other
memory barrier functions provide the guarantee to all other shader
invocations. No memory barrier is required to guarantee the order of
memory stores as observed by the invocation performing the stores; an
@@ -910,7 +911,7 @@
+----------------------------------------------------+-----------+-------------------------+---------------+-----------------------------------------------------------------------+---------+
| Get Value | Type | Get Command | Initial Value | Description | Sec. |
+----------------------------------------------------+-----------+-------------------------+---------------+-----------------------------------------------------------------------+---------+
- | COMPUTE_WORK_GROUP_SIZE | 3 x Z+ | GetProgramiv | { 0, ... } | Work group size of a linked compute program | 5.5 |
+ | COMPUTE_WORK_GROUP_SIZE | 3 x Z+ | GetProgramiv | { 0, ... } | Workgroup size of a linked compute program | 5.5 |
| UNIFORM_BLOCK_REFERENCED_BY_COMPUTE_SHADER | B | GetActiveUniformBlockiv | FALSE | True if uniform block is referenced by the compute stage | 2.17.7 |
| ATOMIC_COUNTER_BUFFER_REFERENCED_BY_COMPUTE_SHADER | B | GetActiveAtomicCounter- | FALSE | AACB has a counter used by compute shaders | 2.17.7 |
| | | Bufferiv | FALSE | | |
@@ -930,10 +931,10 @@
+-----------------------------------------+-----------+---------------+---------------------+-----------------------------------------------------------------------+---------+
| Get Value | Type | Get Command | Minimum Value | Description | Sec. |
+-----------------------------------------+-----------+---------------+---------------------+-----------------------------------------------------------------------+---------+
- | MAX_COMPUTE_WORK_GROUP_COUNT | 3 x Z+ | GetIntegeri_v | 65535 | Maximum number of work groups that may be dispatched by a single | 5.5 |
+ | MAX_COMPUTE_WORK_GROUP_COUNT | 3 x Z+ | GetIntegeri_v | 65535 | Maximum number of workgroups that may be dispatched by a single | 5.5 |
| | | | | dispatch command (per dimension) | |
- | MAX_COMPUTE_WORK_GROUP_SIZE | 3 x Z+ | GetIntegeri_v | 1024 (x, y), 64 (z) | Maximum local size of a compute work group (per dimension) | 5.5 |
- | MAX_COMPUTE_WORK_GROUP_INVOCATIONS | Z+ | GetIntegerv | 1024 | Maximum total compute shader invocations in a single work group | 5.5 |
+ | MAX_COMPUTE_WORK_GROUP_SIZE | 3 x Z+ | GetIntegeri_v | 1024 (x, y), 64 (z) | Maximum local size of a compute workgroup (per dimension) | 5.5 |
+ | MAX_COMPUTE_WORK_GROUP_INVOCATIONS | Z+ | GetIntegerv | 1024 | Maximum total compute shader invocations in a single workgroup | 5.5 |
| MAX_COMPUTE_UNIFORM_BLOCKS | Z+ | GetIntegerv | 12 | Maximum number of uniform blocks per compute program | 2.11.7 |
| MAX_COMPUTE_TEXTURE_IMAGE_UNITS | Z+ | GetIntegerv | 16 | Maximum number of texture image units accessible by a compute shader | 2.11.12 |
| MAX_COMPUTE_ATOMIC_COUNTER_BUFFERS | Z+ | GetIntegerv | 8 | Number of atomic counter buffers accessed by a compute shader | 2.11.17 |
@@ -959,7 +960,7 @@
RESOLVED: Support only in compute shaders. While some hardware may be
able to support shared variables in shader stages other than compute,
it is difficult to clearly define what the semantics are as far as
- sharing. For example, what is the equivalent for a work group for
+ sharing. For example, what is the equivalent for a workgroup for
vertex shaders?
2) Can we expose atomics on <shared> variables?
@@ -974,18 +975,18 @@
want to use such variables in cases where atomic access (and the
related overhead) is not required.
- 3) Should the local size and dimensions of the work group be specified at
+ 3) Should the local size and dimensions of the workgroup be specified at
compile time? What are the default local dimensions?
- RESOLVED: Dimension is always 3 and a work group size declaration is
+ RESOLVED: Dimension is always 3 and a workgroup size declaration is
compulsory at compile time. There is no default. The value used is
- queriable. To use a 1- or 2-dimensional work group, the extra
+ queriable. To use a 1- or 2-dimensional workgroup, the extra
dimension(s) can be set to 1.
4) Do we need the local_work_size parameter in dispatch if the local size
may be specified at compile time in the shader?
- RESOLVED: The specification of the work group size is now mandatory in
+ RESOLVED: The specification of the workgroup size is now mandatory in
the shader source at compile time and the local_work_size may no longer
be specified at dispatch time.
@@ -1167,18 +1168,18 @@
void groupMemoryBarrier();
- that only order transactions as viewed by other threads in the same work
- group, which might not require synchronization with other shader cores.
- Since shared memory is only accessible to threads within a single work
- group, memoryBarrierShared() also only requires synchronization with
- other threads in the same work group.
+ that only order transactions as viewed by other threads in the same
+ workgroup, which might not require synchronization with other shader cores.
+ Since shared memory is only accessible to threads within a single
+ workgroup, memoryBarrierShared() also only requires synchronization with
+ other threads in the same workgroup.
Revision History
Rev. Date Author Changes
---- -------- --------- -----------------------------------------
- 28 12/07/18 Jon Leech Use 'work group' consistently throughout (Bug
- 11723).
+ 28 12/10/18 Jon Leech Use 'workgroup' consistently throughout (Bug
+ 11723, internal API issue 87).
27 07/24/14 Jon Leech Change value of GLSL limit
gl_MaxComputeUniformComponents to 512 for
consistency with the API (Bug 12370).
diff --git a/extensions/ARB/ARB_compute_variable_group_size.txt b/extensions/ARB/ARB_compute_variable_group_size.txt
index 889ceb1..bd03ee5 100644
--- a/extensions/ARB/ARB_compute_variable_group_size.txt
+++ b/extensions/ARB/ARB_compute_variable_group_size.txt
@@ -28,7 +28,7 @@
Version
- Last Modified Date: December 7, 2018
+ Last Modified Date: December 10, 2018
Revision: 9
Number
@@ -50,12 +50,12 @@
Overview
This extension allows applications to write generic compute shaders that
- operate on work groups with arbitrary dimensions. Instead of specifying a
- fixed work group size in the compute shader, an application can use a
+ operate on workgroups with arbitrary dimensions. Instead of specifying a
+ fixed workgroup size in the compute shader, an application can use a
compute shader using the /local_size_variable/ layout qualifer to indicate
- a variable work group size. When using such compute shaders, the new
- command DispatchComputeGroupSizeARB should be used to specify both a work
- group size and work group count.
+ a variable workgroup size. When using such compute shaders, the new
+ command DispatchComputeGroupSizeARB should be used to specify both a
+ workgroup size and workgroup count.
In this extension, compute shaders with fixed group sizes must be
dispatched by DispatchCompute and DispatchComputeIndirect. Compute
@@ -95,7 +95,7 @@
(modify second paragraph, p. 585)
- ... One or more work groups is launched by calling
+ ... One or more workgroups is launched by calling
void DispatchCompute(uint num_groups_x, uint num_groups_y,
uint num_groups_z)
@@ -108,30 +108,30 @@
(modify second paragraph, p. 586)
- For DispatchCompute, the work group size in each dimension must be
+ For DispatchCompute, the workgroup size in each dimension must be
specified at compile time in the active program for the compute shader
- stage. The work group size is specified using an input layout qualifer
+ stage. The workgroup size is specified using an input layout qualifer
...
(insert after second paragraph, p. 586)
- For DispatchComputeGroupSizeARB, the work group size must be specified as
+ For DispatchComputeGroupSizeARB, the workgroup size must be specified as
variable in the active program for the compute shader stage. The group
size used to execute the compute shader is taken from the <group_size_x>,
<group_size_y>, and <group_size_z> parameters. For the purposes of the
- COMPUTE_WORK_GROUP_SIZE query, a program without a work group size
+ COMPUTE_WORK_GROUP_SIZE query, a program without a workgroup size
specified at compile time will be considered to have a size of zero in
each dimension.
(modify the third paragraph, p. 586)
- The maximum size of a work group may be determined by calling
+ The maximum size of a workgroup may be determined by calling
GetIntegeri_v with <index> set to 0, 1, or 2 to retrieve the maximum work
size in the X, Y and Z dimension, respectively. <target> should be set to
MAX_COMPUTE_FIXED_GROUP_SIZE_ARB for compute shaders with fixed group
sizes or MAX_COMPUTE_VARIABLE_GROUP_SIZE_ARB for compute shaders with
variable local group sizes. Furthermore, the maximum number of
- invocations in a single work group (i.e., the product of the three
+ invocations in a single workgroup (i.e., the product of the three
dimensions) may be determined by calling GetIntegerv with <pname> set to
MAX_COMPUTE_FIXED_GROUP_INVOCATIONS_ARB for compute shaders with fixed
group sizes or MAX_COMPUTE_VARIABLE_GROUP_INVOCATIONS_ARB for compute
@@ -141,11 +141,11 @@
shared between DispatchCompute and DispatchComputeGroupSizeARB, p. 586)
An INVALID_OPERATION error is generated by DispatchCompute if the active
- program for the compute shader stage has a variable work group
+ program for the compute shader stage has a variable workgroup
size.
An INVALID_OPERATION error is generated by DispatchComputeGroupSizeARB if
- the active program for the compute shader stage has a fixed work group
+ the active program for the compute shader stage has a fixed workgroup
size.
(insert at the end of the first error block, shared between
@@ -153,13 +153,13 @@
An INVALID_VALUE error is generated by DispatchComputeGroupSizeARB if any
of <group_size_x>, <group_size_y>, or <group_size_z> is less than or equal
- to zero or greater than the maximum work group size for compute
+ to zero or greater than the maximum workgroup size for compute
shaders with variable group size (MAX_COMPUTE_VARIABLE_GROUP_SIZE_ARB) in
the corresponding dimension.
An INVALID_VALUE error is generated by DispatchComputeGroupSizeARB if the
product of <group_size_x>, <group_size_y>, and <group_size_z> exceeds the
- implementation-dependent maximum work group invocation count for
+ implementation-dependent maximum workgroup invocation count for
compute shaders with variable group size
(MAX_COMPUTE_VARIABLE_GROUP_INVOCATIONS_ARB).
@@ -167,7 +167,7 @@
p. 587)
An INVALID_OPERATION error is generated if the active program for the
- compute shader stage has a variable work group size.
+ compute shader stage has a variable workgroup size.
Modifications to the OpenGL Shading Language Specification, Version 4.30
@@ -245,19 +245,19 @@
(insert after third paragraph, p. 113)
The built-in variable /gl_LocalGroupSizeARB/ is a compute-shader input
- variable containing the work group size for the current compute-
- shader work group. For compute shaders with a fixed local group size (using
+ variable containing the workgroup size for the current compute-
+ shader workgroup. For compute shaders with a fixed local group size (using
*local_size_x*, *local_size_y*, or *local_size_z* layout qualifiers), its
value will be the same as the constant /gl_WorkGroupSize/. For compute
shaders with a variable local group size (using *local_size_variable*),
- the value of /gl_LocalGroupSizeARB/ will be the work
- group size specified in the OpenGL API command dispatching the current
+ the value of /gl_LocalGroupSizeARB/ will be the workgroup
+ size specified in the OpenGL API command dispatching the current
compute shader work.
(modify next-to-last paragraph, p. 113)
The built-in variable gl_LocalInvocationID ... The possible values for
- this varaible range across the work group size, i.e., (0,0,0) to
+ this varaible range across the workgroup size, i.e., (0,0,0) to
(gl_LocalGroupSizeARB.x - 1, gl_LocalGroupSizeARB.y - 1,
gl_LocalGroupSizeARB.z - 1).
@@ -290,7 +290,7 @@
Dependencies on NV_compute_program5
- If NV_compute_program5 is supported, variable work group sizes are
+ If NV_compute_program5 is supported, variable workgroup sizes are
supported for assembly programs. Make the following edits to the
NV_compute_program5 specification:
@@ -299,19 +299,19 @@
If a compute attribute binding matches "invocation.groupsize", the "x",
"y", and "z" components of the invocation attribute variable are filled
- the "x", "y", and "z" dimensions, respectively, of the work group,
+ the "x", "y", and "z" dimensions, respectively, of the workgroup,
as specified by the GROUP_SIZE declaration for programs with fixed-size
- work groups or through the OpenGL API for programs with variable-size work
- groups. The "w" component of the attribute is undefined.
+ workgroups or through the OpenGL API for programs with variable-size
+ workgroups. The "w" component of the attribute is undefined.
(add to section 2.X.6 of the NV_gpu_program4/5 spec, Program Options)
+ Compute Shader Variable Group Size (ARB_compute_variable_group_size)
If a program specifies the "ARB_compute_variable_group_size" option, it
- supports variable-size work groups. Compute programs with a variable work
- group size must be dispatched with DispatchComputeGroupSizeARB. Compute
- programs with a fixed work group size must be dispatched with
+ supports variable-size workgroups. Compute programs with a variable
+ workgroup size must be dispatched with DispatchComputeGroupSizeARB. Compute
+ programs with a fixed workgroup size must be dispatched with
DispatchCompute or DispatchComputeIndirect.
(modify Section 2.X.7.Y, Compute Program Declarations)
@@ -319,7 +319,7 @@
- Shader Thread Group Size (GROUP_SIZE)
The GROUP_SIZE statement declares the number of shader threads in a one-,
- two-, or three-dimensional work group. The statement must have one
+ two-, or three-dimensional workgroup. The statement must have one
to three unsigned integer arguments. Each argument must be less than or
equal to the value of the implementation-dependent limit
MAX_COMPUTE_LOCAL_WORK_SIZE for its corresponding dimension (X, Y, or Z).
@@ -333,21 +333,21 @@
An INVALID_OPERATION error is generated by DispatchCompute or
DispatchComputeIndirect if the active program for the compute shader stage
- has a variable work group size.
+ has a variable workgroup size.
An INVALID_OPERATION error is generated by DispatchComputeGroupSizeARB if
- the active program for the compute shader stage has a fixed work group
+ the active program for the compute shader stage has a fixed workgroup
size.
An INVALID_VALUE error is generated by DispatchComputeGroupSizeARB if any
of <group_size_x>, <group_size_y>, or <group_size_z> is less than or equal
- to zero or greater than the maximum work group size for compute
+ to zero or greater than the maximum workgroup size for compute
shaders with variable group size (MAX_COMPUTE_VARIABLE_GROUP_SIZE_ARB) in
the corresponding dimension.
An INVALID_VALUE error is generated by DispatchComputeGroupSizeARB if the
product of <group_size_x>, <group_size_y>, and <group_size_z> exceeds the
- implementation-dependent maximum work group invocation count for
+ implementation-dependent maximum workgroup invocation count for
compute shaders with variable group size
(MAX_COMPUTE_VARIABLE_GROUP_INVOCATIONS_ARB).
@@ -379,29 +379,29 @@
Issues
- (1) If a compute shader declares a work group size, can it be dispatched
- using OpenGL APIs accepting an explicit work group size as part of the
+ (1) If a compute shader declares a workgroup size, can it be dispatched
+ using OpenGL APIs accepting an explicit workgroup size as part of the
command? If so, what happens?
RESOLVED: No. Attempting to do so will generate an INVALID_OPERATION
error.
- Since the fixed work group size may affect the compilation of the shader
+ Since the fixed workgroup size may affect the compilation of the shader
and the value of certain built-in constants, having the OpenGL API
- override the work group size baked into the compute shader seems
- suspect. We could conceivably allow an explicit work group size in the
- OpenGL API and require that it match the work group size baked into the
+ override the workgroup size baked into the compute shader seems
+ suspect. We could conceivably allow an explicit workgroup size in the
+ OpenGL API and require that it match the workgroup size baked into the
compute shader, but doing so seems to be of limited value.
- (2) If a compute shader doesn't declare a work group size, can it be
- dispatched using OpenGL APIs that do not accept an explicit work group
+ (2) If a compute shader doesn't declare a workgroup size, can it be
+ dispatched using OpenGL APIs that do not accept an explicit workgroup
size as part of the command? If so, what happens?
RESOLVED: No. Attempting to do so will generate an INVALID_OPERATION
error.
We could theoretically treat this case as allowing OpenGL
- implementations to pick a work group size that "works well" on a
+ implementations to pick a workgroup size that "works well" on a
particular piece of hardware. However, that wouldn't resolve the
question of what the "num_groups" arguments to DispatchCompute would
mean if the group size were implementation-dependent. One could
@@ -415,18 +415,18 @@
RESOLVED: We will provide a new built-in variable exposing the group
size specified in the API. The name choice is potentially tricky, since
- we now have two different "work group size" variables -- a previously
- existing constant for the fixed work group size and now a second input
- for the variable work group size specified in the API. We choose the
+ we now have two different "workgroup size" variables -- a previously
+ existing constant for the fixed workgroup size and now a second input
+ for the variable workgroup size specified in the API. We choose the
name "gl_LocalGroupSizeARB" here, which seems to fit reasonably well with
existing inputs such as "gl_LocalInvocationID".
If we had provided this functionality in the original compute shader
extension, maybe we could have only had "gl_LocalGroupSizeARB"?
However, the constant "gl_WorkGroupSize" would still be useful for
- sizing built-in arrays for shaders with a fixed work group size. For
+ sizing built-in arrays for shaders with a fixed workgroup size. For
example, a shader might want to declare a shared variable with one
- instance per work group invocation, such as:
+ instance per workgroup invocation, such as:
shared float shared_values[gl_WorkGroupSize.x * gl_WorkGroupSize.y *
gl_WorkGroupSize.z];
@@ -435,15 +435,15 @@
"gl_LocalGroupSizeARB".
(4) Do we need to modify the behavior of existing GLSL built-ins for
- compute shaders without an explicit work group size?
+ compute shaders without an explicit workgroup size?
RESOLVED: No, not really.
The constant gl_WorkGroupSize seems like it would be affected by
- omitting an explicit work group size. However, it is already an error
- to use gl_WorkGroupSize in a shader before a work group size layout
+ omitting an explicit workgroup size. However, it is already an error
+ to use gl_WorkGroupSize in a shader before a workgroup size layout
qualifier is declared. That would make its use illegal in shaders where
- work group size layout qualifiers are not declared at all.
+ workgroup size layout qualifiers are not declared at all.
We do need to make minor modifications to the language describing other
built-in inputs such as gl_LocalInvocationIndex, that are today defined
@@ -451,25 +451,25 @@
definitions to use the input gl_LocalGroupSizeARB instead.
(5) Should we provide a function (e.g.,
- DispatchComputeIndirectGroupSizeARB) that takes both a work group
- count and a work group size from indirect dispatch buffers? If so,
- what do we do if the work group size is not positive or exceeds
+ DispatchComputeIndirectGroupSizeARB) that takes both a workgroup
+ count and a workgroup size from indirect dispatch buffers? If so,
+ what do we do if the workgroup size is not positive or exceeds
implementation-dependent limits?
RESOLVED: No, let's leave this out of this extension.
(6) Is it necessary for compute shaders to include a "#extension"
directive to enable this extension in order to link successfully
- without a fixed work group size?
+ without a fixed workgroup size?
RESOLVED: Yes, compute shaders will have to use the
- "local_size_variable" layout qualifier to declare a variable work group
+ "local_size_variable" layout qualifier to declare a variable workgroup
size, and an "#extension" directive is required to be able to use that
layout qualifier.
In unextended OpenGL 4.3, we get a link error if no shaders in the
- program exercise an existing language feature (declaring the fixed work
- group size). We could have simply removed this error, but the general
+ program exercise an existing language feature (declaring the fixed
+ workgroup size). We could have simply removed this error, but the general
rule for "#extension" is that a user should be able to determine if a
shader were legal or not simply by examining the source code.
@@ -497,8 +497,9 @@
Revision History
- Revision 9, December 7, 2018 (Jon Leech)
- - Use 'work group' consistently throughout (Bug 11723).
+ Revision 9, December 10, 2018 (Jon Leech)
+ - Use 'workgroup' consistently throughout (Bug 11723, internal API
+ issue 87).
Revision 8, May 30, 2013 (pbrown)
- Fix a typo in the MAX_COMPUTE_VARIABLE_GROUP_SIZE_ARB description;
diff --git a/extensions/ARB/ARB_gl_spirv.txt b/extensions/ARB/ARB_gl_spirv.txt
index e5e0569..3583aa1 100644
--- a/extensions/ARB/ARB_gl_spirv.txt
+++ b/extensions/ARB/ARB_gl_spirv.txt
@@ -29,7 +29,7 @@
Version
- Last Modified Date: December 7, 2018
+ Last Modified Date: December 10, 2018
Revision: 41
Number
@@ -1319,7 +1319,7 @@
"This leaves gl_WorkGroupSize.y as a non-specialization constant, with
gl_WorkGroupSize being a partially specialized vector. Its x and z
components can be later specialized using the ids 18 and 19. These ids
- are declared independently from declaring the work group size:
+ are declared independently from declaring the workgroup size:
layout(local_size_x = 32, local_size_y = 32) in; // size is (32,32,1)
layout(local_size_x_id = 18) in; // constant_id for x
@@ -2077,8 +2077,9 @@
Rev. Date Author Changes
---- ----------- ------------ ---------------------------------
- 41 07-Dec-2018 Jon Leech Use 'work group' consistently
- throughout (Bug 11723).
+ 41 10-Dec-2018 Jon Leech Use 'workgroup' consistently
+ throughout (Bug 11723, internal API
+ issue 87).
40 29-May-2018 dgkoch note post decrement for atomicCounterDecrement
mapping
39 25-Apr-2018 JohnK add mappings of barriers and atomics
diff --git a/extensions/ARB/ARB_shader_group_vote.txt b/extensions/ARB/ARB_shader_group_vote.txt
index 88dbc91..156bf77 100644
--- a/extensions/ARB/ARB_shader_group_vote.txt
+++ b/extensions/ARB/ARB_shader_group_vote.txt
@@ -26,7 +26,7 @@
Version
- Last Modified Date: December 7, 2018
+ Last Modified Date: December 10, 2018
Revision: 7
Number
@@ -55,12 +55,12 @@
implementation-dependent, and this extension provides no guarantee over
how individual shader invocations are assigned to such sets. In
particular, the set of shader invocations has no necessary relationship
- with the compute shader work group -- a pair of shader invocations
- in a single compute shader work group may end up in different sets used by
+ with the compute shader workgroup -- a pair of shader invocations
+ in a single compute shader workgroup may end up in different sets used by
these built-ins.
Compute shaders operate on an explicitly specified group of threads (a
- work group), but many implementations of OpenGL 4.3 will even group
+ workgroup), but many implementations of OpenGL 4.3 will even group
non-compute shader invocations and execute them in a SIMD fashion. When
executing code like
@@ -211,45 +211,45 @@
Issues
(1) Should we provide built-ins exposing a fixed implementation-dependent
- SIMD work group size and/or the "location" of a single invocation
- within a fixed-size SIMD work group?
+ SIMD workgroup size and/or the "location" of a single invocation
+ within a fixed-size SIMD workgroup?
RESOLVED: Not in this extension.
(2) Should we provide mechanisms for sharing arbitrary data values across
- SIMD work groups?
+ SIMD workgroups?
RESOLVED: Not in this extension.
For compute shaders, shared memory may already be used to share values
- across invocations in a single work group.
+ across invocations in a single workgroup.
(3) Is this capability supported for all shader types or just compute
shaders?
RESOLVED: All shader types.
- (4) For compute shaders, is there any relationship between the work
- group and the SIMD invocation group across which conditions are
+ (4) For compute shaders, is there any relationship between the
+ workgroup and the SIMD invocation group across which conditions are
evaluated?
RESOLVED: No.
- (5) Is there any necessary relationship between SIMD work groups in this
- extension and the work groups for compute shaders?
+ (5) Is there any necessary relationship between SIMD workgroups in this
+ extension and the workgroups for compute shaders?
- RESOLVED: No. It is expected that the SIMD work groups in this
- extension are relatively small compared to a maximum-sized compute work
- group. On current NVIDIA GPUs, the SIMD work group size will be 32;
- however, maximum work group size (MAX_COMPUTE_WORK_GROUP_INVOCATIONS)
+ RESOLVED: No. It is expected that the SIMD workgroups in this
+ extension are relatively small compared to a maximum-sized compute
+ workgroup. On current NVIDIA GPUs, the SIMD workgroup size will be 32;
+ however, maximum workgroup size (MAX_COMPUTE_WORK_GROUP_INVOCATIONS)
for OpenGL 4.3 compute shaders is 1024.
- Perhaps there might be some small value in guaranteeing that a SIMD work
- group doesn't span compute work groups. However, it's not clear
+ Perhaps there might be some small value in guaranteeing that a SIMD
+ workgroup doesn't span compute workgroups. However, it's not clear
that there is any specific value in doing so, and having such a
- restriction could limit parallelism for very small compute work groups
- (where one might be able to fit multiple work groups in a single SIMD
- work group).
+ restriction could limit parallelism for very small compute workgroups
+ (where one might be able to fit multiple workgroups in a single SIMD
+ workgroup).
(6) How do the built-in functions work when called in conditionally
executed code?
@@ -385,8 +385,9 @@
Revision History
- Revision 7, December 7, 2018 (Jon Leech)
- - Use 'work group' consistently throughout (Bug 11723).
+ Revision 7, December 10, 2018 (Jon Leech)
+ - Use 'workgroup' consistently throughout (Bug 11723, internal API
+ issue 87).
Revision 6, May 30, 2013
- Mark issue (13) as resolved.
diff --git a/extensions/EXT/EXT_shader_group_vote.txt b/extensions/EXT/EXT_shader_group_vote.txt
index 1ab9730..d6bbdef 100644
--- a/extensions/EXT/EXT_shader_group_vote.txt
+++ b/extensions/EXT/EXT_shader_group_vote.txt
@@ -21,7 +21,7 @@
Version
- Last Modified Date: December 7, 2018
+ Last Modified Date: December 10, 2018
Revision: 3
Number
@@ -45,12 +45,12 @@
implementation-dependent, and this extension provides no guarantee over
how individual shader invocations are assigned to such sets. In
particular, the set of shader invocations has no necessary relationship
- with the compute shader work group -- a pair of shader invocations
- in a single compute shader work group may end up in different sets used by
+ with the compute shader workgroup -- a pair of shader invocations
+ in a single compute shader workgroup may end up in different sets used by
these built-ins.
Compute shaders operate on an explicitly specified group of threads (a
- work group), but many implementations of OpenGL ES 3.0 will even group
+ workgroup), but many implementations of OpenGL ES 3.0 will even group
non-compute shader invocations and execute them in a SIMD fashion. When
executing code like
@@ -194,8 +194,9 @@
Revision History
- Revision 3, December 7, 2018 (Jon Leech)
- - Use 'work group' consistently throughout (Bug 11723).
+ Revision 3, December 10, 2018 (Jon Leech)
+ - Use 'workgroup' consistently throughout (Bug 11723, internal API
+ issue 87).
Revision 2, October 21, 2015
- Promoted to EXT
Revision 1, October 23, 2014
diff --git a/extensions/EXT/EXT_tessellation_shader.txt b/extensions/EXT/EXT_tessellation_shader.txt
index cdfb153..fb24876 100644
--- a/extensions/EXT/EXT_tessellation_shader.txt
+++ b/extensions/EXT/EXT_tessellation_shader.txt
@@ -42,7 +42,7 @@
Version
- Last Modified Date: December 7, 2018
+ Last Modified Date: December 10, 2018
Revision: 25
Number
@@ -2407,7 +2407,7 @@
The shader invocation control function is only available in tessellation
control and compute shaders. It is used to control the relative
execution order of multiple shader invocations used to process a patch
- (in the case of tessellation control shaders) or a work group (in
+ (in the case of tessellation control shaders) or a workgroup (in
the case of compute shaders), which are otherwise executed with an
undefined order.
@@ -2698,8 +2698,8 @@
Rev. Date Author Changes
---- -------- --------- -------------------------------------------------
- 25 12/07/18 Jon Leech Use 'work group' consistently throughout (Bug
- 11723).
+ 25 12/10/18 Jon Leech Use 'workgroup' consistently throughout (Bug
+ 11723, internal API issue 87).
24 02/03/17 Jon Leech Add issue 17 noting missing GLSL built-in constants
(public bug 1427).
diff --git a/extensions/OES/OES_tessellation_shader.txt b/extensions/OES/OES_tessellation_shader.txt
index 47cb78d..12f70f4 100644
--- a/extensions/OES/OES_tessellation_shader.txt
+++ b/extensions/OES/OES_tessellation_shader.txt
@@ -43,7 +43,7 @@
Version
- Last Modified Date: December 7, 2018
+ Last Modified Date: December 10, 2018
Revision: 7
Number
@@ -2408,7 +2408,7 @@
The shader invocation control function is only available in tessellation
control and compute shaders. It is used to control the relative
execution order of multiple shader invocations used to process a patch
- (in the case of tessellation control shaders) or a work group (in
+ (in the case of tessellation control shaders) or a workgroup (in
the case of compute shaders), which are otherwise executed with an
undefined order.
@@ -2686,8 +2686,9 @@
Rev. Date Author Changes
---- ---------- --------- -------------------------------------------------
- 7 12/07/2018 Jon Leech Use 'work group' consistently throughout (Bug
- 11723).
+ 7 12/10/2018 Jon Leech Use 'workgroup' consistently throughout (Bug
+ 11723, internal API issue 87).
+
6 05/31/2016 Jon Leech Note that primitive ID counters are reset to zero
after each instance drawn (Bug 14024).
