Merge pull request #227 from cmpt376Kor/master
Fix errors in README.adoc
diff --git a/api/GL/glcorearb.h b/api/GL/glcorearb.h
index 33b01e2..a95bbb8 100755
--- a/api/GL/glcorearb.h
+++ b/api/GL/glcorearb.h
@@ -4638,6 +4638,11 @@
#define GL_WEIGHTED_AVERAGE_EXT 0x9367
#endif /* GL_EXT_texture_filter_minmax */
+#ifndef GL_EXT_texture_sRGB_R8
+#define GL_EXT_texture_sRGB_R8 1
+#define GL_SR8_EXT 0x8FBD
+#endif /* GL_EXT_texture_sRGB_R8 */
+
#ifndef GL_EXT_texture_sRGB_decode
#define GL_EXT_texture_sRGB_decode 1
#define GL_TEXTURE_SRGB_DECODE_EXT 0x8A48
diff --git a/api/GL/glext.h b/api/GL/glext.h
index c452a05..39267fe 100644
--- a/api/GL/glext.h
+++ b/api/GL/glext.h
@@ -51,7 +51,7 @@
#define GLAPI extern
#endif
-#define GL_GLEXT_VERSION 20181031
+#define GL_GLEXT_VERSION 20181130
#include <KHR/khrplatform.h>
@@ -8512,6 +8512,11 @@
#define GL_COMPRESSED_SRGB_ALPHA_S3TC_DXT5_EXT 0x8C4F
#endif /* GL_EXT_texture_sRGB */
+#ifndef GL_EXT_texture_sRGB_R8
+#define GL_EXT_texture_sRGB_R8 1
+#define GL_SR8_EXT 0x8FBD
+#endif /* GL_EXT_texture_sRGB_R8 */
+
#ifndef GL_EXT_texture_sRGB_decode
#define GL_EXT_texture_sRGB_decode 1
#define GL_TEXTURE_SRGB_DECODE_EXT 0x8A48
diff --git a/api/GL/glxext.h b/api/GL/glxext.h
index 966409b..38f6c67 100755
--- a/api/GL/glxext.h
+++ b/api/GL/glxext.h
@@ -34,7 +34,7 @@
** https://github.com/KhronosGroup/OpenGL-Registry
*/
-#define GLX_GLXEXT_VERSION 20181031
+#define GLX_GLXEXT_VERSION 20181130
/* Generated C header for:
* API: glx
@@ -476,7 +476,6 @@
#define GLX_RENDERER_OPENGL_COMPATIBILITY_PROFILE_VERSION_MESA 0x818B
#define GLX_RENDERER_OPENGL_ES_PROFILE_VERSION_MESA 0x818C
#define GLX_RENDERER_OPENGL_ES2_PROFILE_VERSION_MESA 0x818D
-#define GLX_RENDERER_ID_MESA 0x818E
typedef Bool ( *PFNGLXQUERYCURRENTRENDERERINTEGERMESAPROC) (int attribute, unsigned int *value);
typedef const char *( *PFNGLXQUERYCURRENTRENDERERSTRINGMESAPROC) (int attribute);
typedef Bool ( *PFNGLXQUERYRENDERERINTEGERMESAPROC) (Display *dpy, int screen, int renderer, int attribute, unsigned int *value);
diff --git a/api/GL/wgl.h b/api/GL/wgl.h
index 3d0c92b..3391185 100644
--- a/api/GL/wgl.h
+++ b/api/GL/wgl.h
@@ -39,7 +39,7 @@
#include <windows.h>
#endif
-/* Generated on date 20181031 */
+/* Generated on date 20181130 */
/* Generated C header for:
* API: wgl
diff --git a/api/GL/wglext.h b/api/GL/wglext.h
index 48e4de2..a9a5a5b 100755
--- a/api/GL/wglext.h
+++ b/api/GL/wglext.h
@@ -39,7 +39,7 @@
#include <windows.h>
#endif
-#define WGL_WGLEXT_VERSION 20181031
+#define WGL_WGLEXT_VERSION 20181130
/* Generated C header for:
* API: wgl
diff --git a/api/GLES/gl.h b/api/GLES/gl.h
index e3303b6..0d49769 100644
--- a/api/GLES/gl.h
+++ b/api/GLES/gl.h
@@ -36,7 +36,7 @@
#include <GLES/glplatform.h>
-/* Generated on date 20181031 */
+/* Generated on date 20181130 */
/* Generated C header for:
* API: gles1
diff --git a/api/GLES/glext.h b/api/GLES/glext.h
index 040bba6..41de807 100644
--- a/api/GLES/glext.h
+++ b/api/GLES/glext.h
@@ -38,7 +38,7 @@
#define GL_APIENTRYP GL_APIENTRY*
#endif
-/* Generated on date 20181031 */
+/* Generated on date 20181130 */
/* Generated C header for:
* API: gles1
diff --git a/api/GLES2/gl2.h b/api/GLES2/gl2.h
index 996fcd5..cf3b7f3 100644
--- a/api/GLES2/gl2.h
+++ b/api/GLES2/gl2.h
@@ -44,7 +44,7 @@
#define GL_GLES_PROTOTYPES 1
#endif
-/* Generated on date 20181031 */
+/* Generated on date 20181130 */
/* Generated C header for:
* API: gles2
diff --git a/api/GLES2/gl2ext.h b/api/GLES2/gl2ext.h
index 4f3bcfb..81d712e 100644
--- a/api/GLES2/gl2ext.h
+++ b/api/GLES2/gl2ext.h
@@ -38,7 +38,7 @@
#define GL_APIENTRYP GL_APIENTRY*
#endif
-/* Generated on date 20181109 */
+/* Generated on date 20181130 */
/* Generated C header for:
* API: gles2
diff --git a/api/GLES3/gl3.h b/api/GLES3/gl3.h
index 6b3f320..4570785 100644
--- a/api/GLES3/gl3.h
+++ b/api/GLES3/gl3.h
@@ -44,7 +44,7 @@
#define GL_GLES_PROTOTYPES 1
#endif
-/* Generated on date 20181031 */
+/* Generated on date 20181130 */
/* Generated C header for:
* API: gles2
diff --git a/extensions/ARB/ARB_compute_shader.txt b/extensions/ARB/ARB_compute_shader.txt
index 598893f..4899269 100644
--- a/extensions/ARB/ARB_compute_shader.txt
+++ b/extensions/ARB/ARB_compute_shader.txt
@@ -29,8 +29,8 @@
Version
- Last Modified Date: July 24, 2014
- Revision: 27
+ Last Modified Date: December 10, 2018
+ Revision: 28
Number
@@ -249,7 +249,7 @@
validation succeeded, no INVALID_OPERATION validation error will be
generated if <pipeline> were bound and no program were made current via
UseProgram, given the current state. If validation failed, such errors
- will be generated under the current state.
+ will be generated under the current state.
In subsection 2.11.12, "Shader Execution":
@@ -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
- local 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 local work 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 local 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 local 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 local 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 local 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.
@@ -452,49 +452,49 @@
4.20 (Overview of OpenGL Shading)
Replace the last sentence of the first paragraph of the overview with
- the following:
+ the following:
- "Currently, these processors are the vertex, tessellation control,
+ "Currently, these processors are the vertex, tessellation control,
tessellation evaluation, geometry, fragment, and compute processors."
Replace the last sentence of the second paragraph of the overview with
the following:
"The specific languages will be referred to by the name of the processor
- they target: vertex, tessellation control, tessellation evaluation,
+ they target: vertex, tessellation control, tessellation evaluation,
geometry, fragment, or compute."
Add a new Section 2.6 titled "Compute Processor" with the following text:
"The <compute processor> is a programmable unit that operates independently
from the other shader processors. Compilation units written in the OpenGL
- Shading Language to run on this processor are called <compute shaders>.
- When a complete set of compute shaders are compiled and linked, they
- result in a <compute shader executable> that runs on the compute processor.
+ Shading Language to run on this processor are called <compute shaders>.
+ When a complete set of compute shaders are compiled and linked, they
+ result in a <compute shader executable> that runs on the compute processor.
A compute shader has access to many of the same resources as fragment and
- other shader processors, such as textures, buffers, image variables,
- atomic counters, and so on. It does not have any predefined inputs
+ other shader processors, such as textures, buffers, image variables,
+ atomic counters, and so on. It does not have any predefined inputs
nor any fixed-function outputs. It is not part of the graphics pipeline
- and its visible side effects are through actions on images, storage
- buffers, and atomic counters.
+ 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)
- Modify section 4.4.1, second paragraph from
+ Modify section 4.4.1, second paragraph from
"All shaders allow input layout qualifiers on input variable declarations."
to
-
- "All shaders, except compute shaders, allow input layout location qualifiers on
+
+ "All shaders, except compute shaders, allow input layout location qualifiers on
input variable declarations."
Modify Section 4.3. Add to the table at the start of Section 4.3:
@@ -503,7 +503,7 @@
| Storage Qualifier | Meaning |
+-------------------+-----------------------------------------------------------+
| <shared> | variable storage is shared across all work items in a |
- | | local work group for compute shaders |
+ | | workgroup for compute shaders |
+-------------------+-----------------------------------------------------------+
Add the following paragraph to Section 4.3.4, "Input Variables"
@@ -526,32 +526,31 @@
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 local 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 local 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 local 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
+ 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
employed using the barrier() function (see Section 8.15).
There is a limit to the total size of all variables declared as
<shared> in a single program object. This limit, expressed in units of
- basic machine units may be determined by using the OpenGL API to query the
+ basic machine units may be determined by using the OpenGL API to query the
value of MAX_COMPUTE_SHARED_MEMORY_SIZE.
Add Section 4.4.1.4, "Compute-Shader Inputs"
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
@@ -578,18 +577,18 @@
layout (local_size_x = 8) in;
effectively specifies that a one-dimensional compute shader is being
- compiled, and its size is 8 elements.
+ compiled, and its size is 8 elements.
If the local size of the shader in any dimension is greater than the
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 local
- work-group size; otherwise a compile-time error results. If multiple compute
- shaders attached to a single program object declare local work-group size,
+ than once in the same shader, all those declarations must indicate the same
+ 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 local work
- 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)
@@ -599,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;
@@ -615,50 +614,51 @@
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
+ <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 local 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.
- The values stored in <gl_WorkGroupSize> match those specified in the
+ 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 local 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 local work group
- within the global work group that the current invocation is executing in.
- The possible values for this variable range across the local 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 local and global work groups initiated by the current
+ value uniquely identifies this invocation from all other invocations
+ across all workgroups initiated by the current
DispatchCompute call. This is computed as:
- gl_GlobalInvocationID =
+ gl_GlobalInvocationID =
gl_WorkGroupID * gl_WorkGroupSize + gl_LocalInvocationID.
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 local work group for this
+ gl_LocalInvocationID. This is useful for uniquely identifying a
+ 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 +
+
+ gl_LocalInvocationIndex =
+ gl_LocalInvocationID.z * gl_WorkGroupSize.x * gl_WorkGroupSize.y +
+ gl_LocalInvocationID.y * gl_WorkGroupSize.x +
gl_LocalInvocationID.x;
Add to the list of built-in constants in Section 7.3:
@@ -687,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 local 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.
@@ -696,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. |
+----------------+--------------------------------------------------------------------------+
@@ -750,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. |
+-----------------------------------+----------------------------------------------------------------------------------------+
@@ -789,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
@@ -818,7 +818,7 @@
DispatchComputeIndirect with a resident buffer object without requiring
that it be bound to the DISPATCH_INDIRECT_BUFFER target. The following
additional edits apply:
-
+
Accepted by the <cap> parameter of GetBufferParameterui64vNV:
DISPATCH_INDIRECT_BUFFER (defined above)
@@ -829,8 +829,8 @@
DISPATCH_INDIRECT_UNIFIED_NV 0x90FD
- Accepted by the <pname> parameter of BufferAddressRangeNV
- and the <value> parameter of GetIntegerui64vNV:
+ Accepted by the <pname> parameter of BufferAddressRangeNV
+ and the <value> parameter of GetIntegerui64vNV:
DISPATCH_INDIRECT_ADDRESS_NV 0x90FE
@@ -889,7 +889,7 @@
COMPUTE_WORK_GROUP_SIZE and either the program has not been linked
successfully, or has been linked but contains no compute shaders.
- LinkProgram will fail if <program> contains a combination of compute and
+ LinkProgram will fail if <program> contains a combination of compute and
non-compute shaders.
New State
@@ -911,7 +911,7 @@
+----------------------------------------------------+-----------+-------------------------+---------------+-----------------------------------------------------------------------+---------+
| Get Value | Type | Get Command | Initial Value | Description | Sec. |
+----------------------------------------------------+-----------+-------------------------+---------------+-----------------------------------------------------------------------+---------+
- | COMPUTE_WORK_GROUP_SIZE | 3 x Z+ | GetProgramiv | { 0, ... } | Local work 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 | | |
@@ -931,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 local 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 |
@@ -960,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 local work group for
+ sharing. For example, what is the equivalent for a workgroup for
vertex shaders?
2) Can we expose atomics on <shared> variables?
@@ -975,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
- compile time? What is the default local dimensions?
+ 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 local 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
- dimensions can be set to 1.
+ 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 local work 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.
@@ -1070,7 +1070,7 @@
a single program. Since no single program can have more than five
stages, these limits don't need to be increased.
- 10) How do the shader built-in variables relate to DirectCompute's
+ 10) How do the shader built-in variables relate to DirectCompute's
built-in system values (SV_*)?
OpenGL Compute DirectCompute
@@ -1118,10 +1118,10 @@
errors for Draw* calls if the current program specified by UseProgram
is a compute program?
- RESOLVED: Not in the current spec. If a compute shader is made
- current with UseProgram, there will be no active program for either the
- vertex and fragment stages. In this case, the results of vertex and
- fragment processing are undefined, but no error is generated. This
+ RESOLVED: Not in the current spec. If a compute shader is made
+ current with UseProgram, there will be no active program for either the
+ vertex and fragment stages. In this case, the results of vertex and
+ fragment processing are undefined, but no error is generated. This
behavior is already specified in unextended OpenGL 4.2.
We don't generate errors in this case for several reasons:
@@ -1168,26 +1168,28 @@
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/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).
26 01/30/14 Jon Leech Add table 6.31 COMPUTE_SHADER entry for
program pipeline objects (Bug 11539).
- 25 10/23/12 pbrown Remove the restriction forbidding the use of
- barrier() inside potentially divergent flow
+ 25 10/23/12 pbrown Remove the restriction forbidding the use of
+ barrier() inside potentially divergent flow
control. Instead, we will allow barrier() to
- be executed anywhere, but specify undefined
- results (including hangs or program termination)
+ be executed anywhere, but specify undefined
+ results (including hangs or program termination)
if the flow control is divergent (bug 9367).
24 07/01/12 Jon Leech Fix typo (bug 8984).
23 06/28/12 johnk Remove two other references to "thread", add
@@ -1229,18 +1231,18 @@
Other minor wording improvements.
17 06/15/12 johnk Don't allow location layout qualifiers for
compute shader inputs.
- 16 06/15/12 johnk In the intro material, allow work groups to
- only potentially execute in parallel, and use
+ 16 06/15/12 johnk In the intro material, allow work groups to
+ only potentially execute in parallel, and use
control barriers to synchronize. Other minor
fixes.
15 06/15/12 dgkoch Added Additions to Ch.2 of Shading Language.
- Renamed shader built-in variables, explained
+ Renamed shader built-in variables, explained
them better, made them uvec3 instead of int[3].
Added derived shading language variables.
Renamed and changed built-in constants for
consistency with the variables. Removed
gl_MaxComputeWorkDimensions since it is no
- longer necessary. Renamed API constants to
+ longer necessary. Renamed API constants to
be consistent with shading language terminology.
Remove a few rogue references to variable
number of dispatch arguments. Added Issue 10.
@@ -1264,12 +1266,12 @@
13 06/14/12 Jon Leech Copy description of MAX_COMPUTE_SHARED_MEMORY_SIZE
into API spec from GLSL spec (bug 9069).
12 05/14/12 pbrown Add interaction with ARB_shader_storage_buffer_
- object. The built-in functions provided there
+ object. The built-in functions provided there
for atomic memory operations on buffer variables
are also supported for the shared variables
provided here. The functions themselves are
documented fully in the other specification.
- 11 05/14/12 johnk Keep the previous logical contents of the last
+ 11 05/14/12 johnk Keep the previous logical contents of the last
paragraph of the memory shader control functions.
10 04/26/12 gsellers Count max compute shared variable size in bytes.
Make shared variables implicitly coherent.
@@ -1293,9 +1295,9 @@
5 01/20/12 gsellers Make compute dispatch honor conditional
rendering. Add indirect dispatch.
Change 'global work size' to 'num work groups',
- make global size in multiples of local work size.
+ make global size in multiples of work group size.
4 01/10/12 gsellers Fix typos and other small corrections.
- Make specification of local work size at compile
+ Make specification of work group size at compile
time compulsory.
Add COMPUTE_WORK_DIMENSION_ARB and
COMPUTE_LOCAL_WORK_SIZE_ARB queries.
diff --git a/extensions/ARB/ARB_compute_variable_group_size.txt b/extensions/ARB/ARB_compute_variable_group_size.txt
index 2b6130b..bd03ee5 100644
--- a/extensions/ARB/ARB_compute_variable_group_size.txt
+++ b/extensions/ARB/ARB_compute_variable_group_size.txt
@@ -28,8 +28,8 @@
Version
- Last Modified Date: May 30, 2013
- Revision: 8
+ 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 local work 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 local work 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 local work 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 local work 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 local 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 local 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 local 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 local 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 local 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 local 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 local 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 local 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 local 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 local 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,6 +497,10 @@
Revision History
+ 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;
that limit applies only to shaders with variable group sizes.
@@ -544,7 +548,7 @@
respectively.
- Mark various issues as resolved based on work group discussions.
- Add new issue (7) about different implementation-dependent size limits
- for compute shaders with variable-size local work groups.
+ for compute shaders with variable-size work groups.
Revision 1, January 20, 2013
- Initial revision.
diff --git a/extensions/ARB/ARB_gl_spirv.txt b/extensions/ARB/ARB_gl_spirv.txt
index 8fb28a5..3583aa1 100644
--- a/extensions/ARB/ARB_gl_spirv.txt
+++ b/extensions/ARB/ARB_gl_spirv.txt
@@ -29,8 +29,8 @@
Version
- Last Modified Date: 29-May-2018
- Revision: 40
+ 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,6 +2077,9 @@
Rev. Date Author Changes
---- ----------- ------------ ---------------------------------
+ 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 1106e2c..156bf77 100644
--- a/extensions/ARB/ARB_shader_group_vote.txt
+++ b/extensions/ARB/ARB_shader_group_vote.txt
@@ -26,8 +26,8 @@
Version
- Last Modified Date: May 30, 2013
- Revision: 6
+ 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 local 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
- local 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 local 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 local 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 local 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 local 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,6 +385,10 @@
Revision History
+ 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 5c4cd07..d6bbdef 100644
--- a/extensions/EXT/EXT_shader_group_vote.txt
+++ b/extensions/EXT/EXT_shader_group_vote.txt
@@ -21,8 +21,8 @@
Version
- Last Modified Date: October 21, 2015
- Revision: 2
+ 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 local 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
- local 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,6 +194,9 @@
Revision History
+ 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 1360c62..fb24876 100644
--- a/extensions/EXT/EXT_tessellation_shader.txt
+++ b/extensions/EXT/EXT_tessellation_shader.txt
@@ -42,8 +42,8 @@
Version
- Last Modified Date: February 3, 2017
- Revision: 24
+ 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 local 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,6 +2698,9 @@
Rev. Date Author Changes
---- -------- --------- -------------------------------------------------
+ 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/EXT/EXT_texture_sRGB_R8.txt b/extensions/EXT/EXT_texture_sRGB_R8.txt
index da5eb71..50f886e 100644
--- a/extensions/EXT/EXT_texture_sRGB_R8.txt
+++ b/extensions/EXT/EXT_texture_sRGB_R8.txt
@@ -13,6 +13,7 @@
Daniel Koch
Tobias Hector
Jan-Harald Fredriksen
+ Sourav Parmar
Contact
@@ -24,18 +25,28 @@
Version
- Last Modified Date: January 28, 2015
- Revision: #4.0
+ Last Modified Date: November 30, 2018
+ Revision: 5
Number
OpenGL ES Extension #221
+ OpenGL Extension #594
Dependencies
- OpenGL ES 3.0 is required.
+ OpenGL ES 3.0 or OpenGL 1.2 is required.
- This extension is written against the OpenGL ES 3.1 specification.
+ This extension is written against the OpenGL ES 3.1 and
+ OpenGL 4.6 (Core Profile) specifications.
+
+ This extension interacts with ARB_texture_view.
+
+ This extension interacts with EXT_texture_view.
+
+ This extension interacts with OES_texture_view.
+
+ This extension interacts with ARB_direct_state_access.
Overview
@@ -49,13 +60,14 @@
New Tokens
- Accepted by the <internalformat> parameters of TexImage2D, TexImage3D,
- TexStorage2D and TexStorage3D:
+ Accepted by the <internalformat> parameters of TexImage3D, TexImage2D,
+ TexImage1D, TexStorage3D, TexStorage2D, TexStorage1D, TextureStorage3D,
+ TextureStorage2D, and TextureStorage1D:
SR8_EXT 0x8FBD
-Additions to Chapter 8 of the OpenGL ES 3.1 Specification (Textures and
-Samplers)
+Additions to Chapter 8 of the OpenGL ES 3.1 Specification [GL 4.6 core
+specification] (Textures and Samplers)
The following table entry is added to Table 8.2 (Valid combinations of
format, type and sized internalformat):
@@ -64,20 +76,53 @@
------ ---- ------------------------ ---------------
RED UNSIGNED_BYTE 1 SR8_EXT
- The following table entry is added to Table 8.13 (Correspondence of sized
- internal color formats to base internal formats):
+ The following table entry is added to Table 8.13 [8.12 in the GL 4.6 core
+ profile] (Correspondence of sized internal color formats to base internal
+ formats):
Sized Internal Format Base Internal Format R G B A S CR TF Req. rend. Req. tex.
--------------------- -------------------- - - - - - -- -- ---------- ---------
SR8_EXT RED 8 X X
- The following table entry is added to Table 8.24 (sRGB texture internal
- formats):
+ The following table entry is added to Table 8.22 in the GL 4.6 core profile
+ (Compatible internal formats for TextureView):
+
+ Class Internal formats
+ --------------- ----------------
+ VIEW_CLASS_8_BITS SR8_EXT
+
+ The following table entry is added to Table 8.24 [8.24 in the GL 4.6 core
+ profile] (sRGB texture internal formats):
Internal Format
---------------
SR8_EXT
+Dependencies on OpenGL
+
+ If OpenGL is not supported, ignore all references to 1D textures,
+ including TexImage1D, TexStorage1D, and TextureStorage1D.
+
+Dependencies on OpenGL 4.5 and ARB_direct_state_access
+
+ If neither OpenGL 4.5 nor ARB_direct_state_access are supported,
+ ignore all references to TextureStorage3D, TextureStorage2D, and
+ TextureStorage1D.
+
+Dependencies on ARB_texture_view
+
+ If ARB_texture_view is supported, add SR8_EXT to the Internal formats
+ column of the VIEW_CLASS_8_BITS row in Table 3.X.2.
+
+Dependencies on EXT_texture_view
+
+ If EXT_texture_view is supported, add SR8_EXT to the Internal formats
+ column of the VIEW_CLASS_8_BITS row in Table 8.X.2.
+
+Dependencies on OES_texture_view
+
+ If OES_texture_view is supported, add SR8_EXT to the Internal formats
+ column of the VIEW_CLASS_8_BITS row in Table 8.X.2.
Errors
@@ -89,7 +134,11 @@
Revision History
- #01 1/9/2015 Sam Holmes Initial revision.
- #02 1/21/2015 Maurice Ribble Cleanup minor issues
- #03 1/22/2015 Tobias Hector Removed "GL_" prefix and somewhat confusing version language.
- #04 1/28/2015 Sam Holmes Remove redundant specification of errors and clean up internal format name.
+
+ Rev Date Author Description
+ ---- ---------- -------------- ---------------------------------
+ 1 1/9/2015 Sam Holmes Initial revision.
+ 2 1/21/2015 Maurice Ribble Cleanup minor issues
+ 3 1/22/2015 Tobias Hector Removed "GL_" prefix and somewhat confusing version language.
+ 4 1/28/2015 Sam Holmes Remove redundant specification of errors and clean up internal format name.
+ 5 11/30/2018 Sourav Parmar Add GL interactions and register for GL.
diff --git a/extensions/KHR/KHR_texture_compression_astc_hdr.txt b/extensions/KHR/KHR_texture_compression_astc_hdr.txt
index ce45b74..77fbf67 100644
--- a/extensions/KHR/KHR_texture_compression_astc_hdr.txt
+++ b/extensions/KHR/KHR_texture_compression_astc_hdr.txt
@@ -90,9 +90,10 @@
New Tokens
- Accepted by the <internalformat> parameter of CompressedTexImage2D,
- CompressedTexSubImage2D, CompressedTexImage3D, CompressedTexSubImage3D,
- TexStorage2D, TextureStorage2D, TexStorage3D, and TextureStorage3D:
+ Accepted by the <format> parameter of CompressedTexSubImage2D and
+ CompressedTexSubImage3D, and by the <internalformat> parameter of
+ CompressedTexImage2D, CompressedTexImage3D, TexStorage2D,
+ TextureStorage2D, TexStorage3D, and TextureStorage3D:
COMPRESSED_RGBA_ASTC_4x4_KHR 0x93B0
COMPRESSED_RGBA_ASTC_5x4_KHR 0x93B1
@@ -182,8 +183,8 @@
not TEXTURE_2D_ARRAY, TEXTURE_CUBE_MAP_ARRAY, or TEXTURE_3D.
An INVALID_OPERATION error is generated by CompressedTexImage3D if
- <internalformat> is TEXTURE_CUBE_MAP_ARRAY and the "Cube Map Array"
- column of table 8.19 is *not* checked, or if <internalformat> is
+ <target> is TEXTURE_CUBE_MAP_ARRAY and the "Cube Map Array"
+ column of table 8.19 is *not* checked, or if <target> is
TEXTURE_3D and the "3D Tex." column of table 8.19 is *not* checked"
Modify the fifth and sixth paragraphs on p. 170:
@@ -205,8 +206,8 @@
TEXTURE_2D_ARRAY, TEXTURE_CUBE_MAP_ARRAY, or TEXTURE_3D.
An INVALID_OPERATION error is generated by CompressedTexSubImage3D if
- <format> is TEXTURE_CUBE_MAP_ARRAY and the "Cube Map Array" column of
- table 8.19 is *not* checked, or if <format> is TEXTURE_3D and the "3D
+ <target> is TEXTURE_CUBE_MAP_ARRAY and the "Cube Map Array" column of
+ table 8.19 is *not* checked, or if <target> is TEXTURE_3D and the "3D
Tex." column of table 8.19 is *not* checked"
Modify the final error in the same section, on p. 171:
diff --git a/extensions/MESA/GLX_MESA_query_renderer.txt b/extensions/MESA/GLX_MESA_query_renderer.txt
index d8ed446..10f68ec 100644
--- a/extensions/MESA/GLX_MESA_query_renderer.txt
+++ b/extensions/MESA/GLX_MESA_query_renderer.txt
@@ -20,7 +20,7 @@
Version
- Version 8, 14-February-2014
+ Version 9, 09 November 2018
Number
@@ -32,9 +32,6 @@
GLX_ARB_create_context and GLX_ARB_create_context_profile are required.
- This extension interacts with GLX_EXT_create_context_es2_profile and
- GLX_EXT_create_context_es_profile.
-
Overview
In many situations, applications want to detect characteristics of a
@@ -95,18 +92,13 @@
GLX_RENDERER_VENDOR_ID_MESA
GLX_RENDERER_DEVICE_ID_MESA
- Accepted as an attribute name in <*attrib_list> in
- glXCreateContextAttribsARB:
-
- GLX_RENDERER_ID_MESA 0x818E
-
Additions to the OpenGL / WGL Specifications
None. This specification is written for GLX.
Additions to the GLX 1.4 Specification
- [Add the following to Section X.Y.Z of the GLX Specification]
+ [Add to Section 3.3.2 "GLX Versioning" of the GLX Specification]
To obtain information about the available renderers for a particular
display and screen,
@@ -206,29 +198,6 @@
format as the string that would be returned by glGetString of GL_RENDERER.
It may, however, have a different value.
-
- [Add to section section 3.3.7 "Rendering Contexts"]
-
- The attribute name GLX_RENDERER_ID_MESA specified the index of the render
- against which the context should be created. The default value of
- GLX_RENDERER_ID_MESA is 0.
-
-
- [Add to list of errors for glXCreateContextAttribsARB in section section
- 3.3.7 "Rendering Contexts"]
-
- * If the value of GLX_RENDERER_ID_MESA specifies a non-existent
- renderer, BadMatch is generated.
-
-Dependencies on GLX_EXT_create_context_es_profile and
-GLX_EXT_create_context_es2_profile
-
- If neither extension is supported, remove all mention of
- GLX_RENDERER_OPENGL_ES2_PROFILE_VERSION_MESA from the spec.
-
- If GLX_EXT_create_context_es_profile is not supported, remove all mention of
- GLX_RENDERER_OPENGL_ES_PROFILE_VERSION_MESA from the spec.
-
Issues
1) How should the difference between on-card and GART memory be exposed?
@@ -408,3 +377,9 @@
read GLX_RENDERER_ID_MESA. The VENDOR/DEVICE_ID
example given in issue #17 should be 0x5143 and
0xFFFFFFFF respectively.
+
+ Version 9, 2018/11/09 - Remove GLX_RENDERER_ID_MESA, which has never been
+ implemented. Remove the unnecessary interactions
+ with the GLX GLES profile extensions. Note the
+ official GL extension number. Specify the section
+ of the GLX spec to modify.
diff --git a/extensions/NV/NV_vdpau_interop2.txt b/extensions/NV/NV_vdpau_interop2.txt
index 45c371c..6d2106e 100644
--- a/extensions/NV/NV_vdpau_interop2.txt
+++ b/extensions/NV/NV_vdpau_interop2.txt
@@ -17,7 +17,7 @@
Status
- XXX - Not complete yet!!!
+ Complete
Version
@@ -203,4 +203,6 @@
1. 02 Oct 2018 - Manoj Bonda
Initial version
+ 2. 21 Nov 2018 - Manoj Bonda
+ Changed status to complete.
diff --git a/extensions/OES/OES_tessellation_shader.txt b/extensions/OES/OES_tessellation_shader.txt
index 027feb6..12f70f4 100644
--- a/extensions/OES/OES_tessellation_shader.txt
+++ b/extensions/OES/OES_tessellation_shader.txt
@@ -43,8 +43,8 @@
Version
- Last Modified Date: May 31, 2016
- Revision: 6
+ 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 local 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.
@@ -2685,7 +2685,10 @@
Revision History
Rev. Date Author Changes
- ---- ---------- -------- -------------------------------------------------
+ ---- ---------- --------- -------------------------------------------------
+ 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).
diff --git a/extensions/OES/OES_texture_compression_astc.txt b/extensions/OES/OES_texture_compression_astc.txt
index 7e103b0..db04dee 100644
--- a/extensions/OES/OES_texture_compression_astc.txt
+++ b/extensions/OES/OES_texture_compression_astc.txt
@@ -103,9 +103,9 @@
New Tokens
- Accepted by the <internalformat> parameter of CompressedTexImage2D,
- CompressedTexSubImage2D, TexStorage2D, TextureStorage2D, TexStorage3D,
- and TextureStorage3D:
+ Accepted by the <format> parameter of CompressedTexSubImage2D, and
+ by the <internalformat> parameter of CompressedTexImage2D, TexStorage2D,
+ TextureStorage2D, TexStorage3D, and TextureStorage3D:
COMPRESSED_RGBA_ASTC_4x4_KHR 0x93B0
COMPRESSED_RGBA_ASTC_5x4_KHR 0x93B1
@@ -141,8 +141,9 @@
accepted by TexStorage2DEXT, TextureStorage2DEXT, TexStorage3DEXT and
TextureStorage3DEXT.
- Accepted by the <internalformat> parameter of CompressedTexImage3D,
- CompressedTexSubImage3D, TexStorage3D, and TextureStorage3D:
+ Accepted by the <format> parameter of CompressedTexSubImage3D, and
+ by the <internalformat> parameter of CompressedTexImage3D, TexStorage3D,
+ and TextureStorage3D:
COMPRESSED_RGBA_ASTC_3x3x3_OES 0x93C0
COMPRESSED_RGBA_ASTC_4x3x3_OES 0x93C1
@@ -1791,7 +1792,7 @@
w00 = 16 - fs - ft + w11;
i = (p00*w00 + p01*w01 + p10*w10 + p11*w11 + 8) >> 4;
- For 3D, simplex interpolation is used as it is cheaper than a naïve
+ For 3D, simplex interpolation is used as it is cheaper than a naïve
trilinear interpolation. First, we pick some parameters for the inter-
polation based on comparisons of the fractional parts of the texel
position:
diff --git a/extensions/esext.php b/extensions/esext.php
index 3b718da..e4967a9 100644
--- a/extensions/esext.php
+++ b/extensions/esext.php
@@ -639,4 +639,6 @@
</li>
<li value=307><a href="extensions/QCOM/QCOM_YUV_texture_gather.txt">GL_QCOM_YUV_texture_gather</a>
</li>
+<li value=308><a href="extensions/NV/NV_compute_shader_derivatives.txt">GL_NV_compute_shader_derivatives</a>
+</li>
</ol>
diff --git a/extensions/glext.php b/extensions/glext.php
index 56fcdc8..aab9187 100644
--- a/extensions/glext.php
+++ b/extensions/glext.php
@@ -1005,4 +1005,6 @@
</li>
<li value=593><a href="extensions/NV/NV_vdpau_interop2.txt">GL_NV_vdpau_interop2</a>
</li>
+<li value=594><a href="extensions/EXT/EXT_texture_sRGB_R8.txt">GL_EXT_texture_sRGB_R8</a>
+</li>
</ol>
diff --git a/extensions/registry.py b/extensions/registry.py
index 1d0fb8b..5fd7989 100644
--- a/extensions/registry.py
+++ b/extensions/registry.py
@@ -2496,6 +2496,7 @@
'url' : 'extensions/EXT/EXT_texture_sRGB.txt',
},
'GL_EXT_texture_sRGB_R8' : {
+ 'number' : 594,
'esnumber' : 221,
'flags' : { 'public' },
'url' : 'extensions/EXT/EXT_texture_sRGB_R8.txt',
diff --git a/xml/gl.xml b/xml/gl.xml
index 3b7805e..192a9e9 100644
--- a/xml/gl.xml
+++ b/xml/gl.xml
@@ -45200,7 +45200,7 @@
<enum name="GL_COMPRESSED_SRGB_ALPHA_S3TC_DXT5_EXT"/>
</require>
</extension>
- <extension name="GL_EXT_texture_sRGB_R8" supported="gles2">
+ <extension name="GL_EXT_texture_sRGB_R8" supported="gles2|gl|glcore">
<require>
<enum name="GL_SR8_EXT"/>
</require>
diff --git a/xml/glx.xml b/xml/glx.xml
index f903576..810d55f 100644
--- a/xml/glx.xml
+++ b/xml/glx.xml
@@ -583,8 +583,7 @@
<enum value="0x818B" name="GLX_RENDERER_OPENGL_COMPATIBILITY_PROFILE_VERSION_MESA"/>
<enum value="0x818C" name="GLX_RENDERER_OPENGL_ES_PROFILE_VERSION_MESA"/>
<enum value="0x818D" name="GLX_RENDERER_OPENGL_ES2_PROFILE_VERSION_MESA"/>
- <enum value="0x818E" name="GLX_RENDERER_ID_MESA"/>
- <unused start="0x818F"/>
+ <unused start="0x818E" end="0x818F"/>
</enums>
<!-- Please remember that new enumerant allocations must be obtained by
@@ -1898,7 +1897,6 @@
<enum name="GLX_RENDERER_OPENGL_COMPATIBILITY_PROFILE_VERSION_MESA"/>
<enum name="GLX_RENDERER_OPENGL_ES_PROFILE_VERSION_MESA"/>
<enum name="GLX_RENDERER_OPENGL_ES2_PROFILE_VERSION_MESA"/>
- <enum name="GLX_RENDERER_ID_MESA"/>
<command name="glXQueryCurrentRendererIntegerMESA"/>
<command name="glXQueryCurrentRendererStringMESA"/>
<command name="glXQueryRendererIntegerMESA"/>
