Publish new NVIDIA OpenGL extensions.
This commit does not add new enums in gl.xml to the appropriate enum
groups. Some of the types we touched aren't correctly set up today
(e.g., enums accepted by GetIntegeri_v).
diff --git a/extensions/NV/NV_compute_shader_derivatives.txt b/extensions/NV/NV_compute_shader_derivatives.txt
new file mode 100644
index 0000000..9c4ef8e
--- /dev/null
+++ b/extensions/NV/NV_compute_shader_derivatives.txt
@@ -0,0 +1,92 @@
+Name
+
+ NV_compute_shader_derivatives
+
+Name Strings
+
+ GL_NV_compute_shader_derivatives
+
+Contact
+
+ Pat Brown, NVIDIA (pbrown 'at' nvidia.com)
+
+Contributors
+
+ Ashwin Lele, NVIDIA
+ Jeff Bolz, NVIDIA
+
+Status
+
+ Shipping
+
+Version
+
+ Last Modified: September 15, 2018
+ Revision: 1
+
+Number
+
+ OpenGL Extension #525
+
+Dependencies
+
+ This extension is written against the OpenGL 4.6 Specification
+ (Compatibility Profile), dated October 24, 2016.
+
+ OpenGL 4.5 is required.
+
+ This extension requires support for the OpenGL Shading Language (GLSL)
+ extension "NV_compute_shader_derivatives", which can be found at the
+ Khronos Group Github site here:
+
+ https://github.com/KhronosGroup/GLSL
+
+Overview
+
+ This extension adds OpenGL API support for the OpenGL Shading Language
+ (GLSL) extension "NV_compute_shader_derivatives".
+
+ That extension, when enabled, allows applications to use derivatives in
+ compute shaders. It adds compute shader support for explicit derivative
+ built-in functions like dFdx(), automatic derivative computation in
+ texture lookup functions like texture(), use of the optional LOD bias
+ parameter to adjust the computed level of detail values in texture lookup
+ functions, and the texture level of detail query function
+ textureQueryLod().
+
+New Procedures and Functions
+
+ None
+
+New Tokens
+
+ None
+
+Modifications to the OpenGL 4.6 Specification (Compatibility Profile)
+
+ None
+
+Additions to the AGL/GLX/WGL Specifications
+
+ None
+
+Errors
+
+ None
+
+New State
+
+ None
+
+New Implementation Dependent State
+
+ None
+
+Issues
+
+ None, but please refer to issues in the GLSL extension specification.
+
+Revision History
+
+ Revision 1 (pbrown)
+ - Internal revisions.
diff --git a/extensions/NV/NV_fragment_shader_barycentric.txt b/extensions/NV/NV_fragment_shader_barycentric.txt
new file mode 100644
index 0000000..d3c171f
--- /dev/null
+++ b/extensions/NV/NV_fragment_shader_barycentric.txt
@@ -0,0 +1,247 @@
+Name
+
+ NV_fragment_shader_barycentric
+
+Name Strings
+
+ GL_NV_fragment_shader_barycentric
+
+Contact
+
+ Pat Brown, NVIDIA (pbrown 'at' nvidia.com)
+
+Contributors
+
+ Ashwin Lele, NVIDIA
+ Jeff Bolz, NVIDIA
+
+Status
+
+ Shipping
+
+Version
+
+ Last Modified: September 15, 2018
+ Revision: 1
+
+Number
+
+ OpenGL Extension #526
+
+Dependencies
+
+ This extension is written against the OpenGL 4.6 Specification
+ (Compatibility Profile), dated July 30, 2017.
+
+ OpenGL 4.5 is required.
+
+ This extension requires support for the OpenGL Shading Language (GLSL)
+ extension "NV_fragment_shader_barycentric", which can be found at the
+ Khronos Group Github site here:
+
+ https://github.com/KhronosGroup/GLSL
+
+Overview
+
+ This extension advertises OpenGL support for the OpenGL Shading Language
+ (GLSL) extension "NV_fragment_shader_barycentric", which provides fragment
+ shader built-in variables holding barycentric weight vectors that identify
+ the location of the fragment within its primitive. Additionally, the GLSL
+ extension allows fragment the ability to read raw attribute values for
+ each of the vertices of the primitive that produced the fragment.
+
+New Procedures and Functions
+
+ None
+
+New Tokens
+
+ None
+
+Modifications to the OpenGL 4.6 Specification (Compatibility Profile)
+
+ Modify Section 15.2.2, Shader Inputs (p. 586)
+
+ (insert new paragraphs after the first paragraph, p. 589)
+
+ Fragment shader input variables can be declared as per-vertex inputs using
+ the GLSL interpolation qualifier "pervertexNV". Such inputs are not
+ produced by attribute interpolation, but are instead taken directly from
+ corresponding output variables written by the previous shader stage, prior
+ to primitive clipping and rasterization. When reading per-vertex inputs,
+ a fragment shader specifies a vertex number (0, 1, or 2) that identifies a
+ specific vertex in the point, line, or triangle primitive that produced
+ the vertex.
+
+ When no tessellation or geometry shader is active, the vertices passed to
+ each draw call are arranged into point, line, or triangle primitives as
+ described in Section 10.1. If the <n> vertices passed to a draw call are
+ numbered 0 through <n>-1, and the point, line, and triangle primitives
+ produced by the draw call are numbered with consecutive integers beginning
+ with zero, Table X.1 and Table X.2 indicate the original vertex numbers
+ used as vertex 0, vertex 1, and vertex 2 when sourcing per-vertex
+ attributes for fragments produced by the primitive numbered <i>. Table
+ X.1 applies when the provoking vertex convention is
+ FIRST_VERTEX_CONVENTION, while Table X.2 applies when the provoking vertex
+ convention is LAST_VERTEX_CONVENTION.
+
+ Primitive Type Vertex 0 Vertex 1 Vertex 2
+ ------------------------ -------- -------- --------
+ POINTS i - -
+ LINES 2i 2i+1 -
+ LINE_STRIP i i+1 -
+ LINE_LOOP i i+1 -
+ LINE_LOOP (last segment) n-1 0 -
+ TRIANGLES 3i 3i+1 3i+2
+ TRIANGLE_STRIP (even) i i+1 i+2
+ TRIANGLE_STRIP (odd) i i+2 i+1
+ TRIANGLE_FAN i+1 i+2 0
+ POLYGON 0 i i+1
+ LINES_ADJACENCY 4i+1 4i+2 -
+ LINES_STRIP_ADJACENCY i+1 i+2 -
+ TRIANGLES_ADJACENCY 6i 6i+2 6i+4
+ TRIANGLE_STRIP_ADJACENCY (even) 2i 2i+2 2i+4
+ TRIANGLE_STRIP_ADJACENCY (odd) 2i 2i+4 2i+2
+
+ Table X.1, Vertex Order for per-vertex attributes, using the provoking
+ vertex convention FIRST_VERTEX_CONVENTION.
+
+ Primitive Type Vertex 0 Vertex 1 Vertex 2
+ ------------------------ -------- -------- --------
+ POINTS i - -
+ LINES 2i 2i+1 -
+ LINE_STRIP i i+1 -
+ LINE_LOOP i i+1 -
+ LINE_LOOP (last segment) n-1 0 -
+ TRIANGLES 3i 3i+1 3i+2
+ TRIANGLE_STRIP (even) i i+1 i+2
+ TRIANGLE_STRIP (odd) i+1 i i+2
+ TRIANGLE_FAN 0 i+1 i+2
+ POLYGON 0 i i+1
+ LINES_ADJACENCY 4i+1 4i+2
+ LINES_STRIP_ADJACENCY i+1 i+2
+ TRIANGLES_ADJACENCY 6i 6i+2 6i+4
+ TRIANGLE_STRIP_ADJACENCY (even) 2i 2i+2 2i+4
+ TRIANGLE_STRIP_ADJACENCY (odd) 2i+2 2i 2i+4
+
+ Table X.2, Vertex Order for per-vertex attributes, using the provoking
+ vertex convention LAST_VERTEX_CONVENTION.
+
+ When using geometry shaders, vertices used for per-vertex fragment shader
+ inputs are determined using Table X.1 or X.2 by treating the primitive(s)
+ produced by the geometry shader as though they were passed to a DrawArrays
+ calls. When using a tessellation evaluation shader, or when using QUADS
+ or QUAD_STRIP primitives, the vertices used for reading per-vertex
+ fragment shader inputs are assigned in an implementation-dependent order.
+
+ The built-in variables gl_BaryCoordNV and gl_BaryCoordNoPerspNV are
+ three-component floating-point vectors holding barycentric coordinates for
+ the fragment. These built-ins are computed by clipping (Section 13.6.1)
+ and interpolating (Sections 14.5.1 and 14.6.1) a three-component vector
+ attribute. The vertices that are numbered 0, 1, and 2 for the purposes of
+ reading per-vertex fragment shader inputs are assigned values of (1,0,0),
+ (0,1,0), and (0,0,1), respectively. For gl_BaryCoordNV, these values are
+ clipped and interpolated using perspective correction. For
+ gl_BaryCoordNoPerspNV, these values are clipped and interpolated without
+ perspective correction, like other fragment shader inputs qualified with
+ "noperspective".
+
+
+Additions to the AGL/GLX/WGL Specifications
+
+ None
+
+Errors
+
+ None
+
+New State
+
+ None
+
+New Implementation Dependent State
+
+ None
+
+Issues
+
+ (1) Can applications use the original order of vertices in a draw call to
+ determine the order of the three vertices used when reading per-vertex
+ fragment shader inputs?
+
+ RESOLVED: Yes, in most cases.
+
+ This extension allows fragment shaders to read inputs qualified with
+ "pervertexNV" using a vertex number 0, 1, or 2. For most primitive
+ types, the OpenGL Specification already specifies how the original
+ vertices passed to a draw call are assigned to individual point, line,
+ or triangle primitives. The extension extends that language to define a
+ specific vertex order that will be used for sourcing per-vertex
+ attributes. In some cases, this vertex order depends on the provoking
+ vertex convention.
+
+ When using a tessellation evaluation shader, QUADS primitives, or
+ QUAD_STRIP primitives, the OpenGL Specification already indicates that
+ patches or quadrilaterals can be decomposed into finer primitives in an
+ implementation-dependent order. In these cases, we do not guarantee a
+ specific vertex order. However, we still guarantee that the vertices
+ numbered 0, 1, 2 have corresponding barycentric weights (gl_BaryCoordNV)
+ of (1,0,0), (0,1,0), and (0,0,1), respectively. With this guarantee,
+ interpolating attributes manually in a fragment shader with code like:
+
+ float value = (gl_BaryCoordNV.x * v[0].attrib +
+ gl_BaryCoordNV.y * v[1].attrib +
+ gl_BaryCoordNV.z * v[2].attrib);
+
+ should produce results approximately equal to those that would be
+ obtained via conventional attribute interpolation.
+
+ (2) How are clipped primitives handled when using "pervertexNV"
+ fragment shader inputs?
+
+ RESOLVED: In the OpenGL pipeline, clipped primitives are normally
+ handled by having the clipper remove one of the original vertices,
+ introduce one or more new vertices, and process the result as an
+ unclipped primitive. In this model, the provoking vertex still needs to
+ be maintained because inputs qualified with "flat" use the values from
+ that vertex even if the provoking vertex is clipped.
+
+ In this extension, we guarantee that the three sets of per-vertex values
+ available as fragment shader inputs are those of the original primitive
+ vertices prior to clipping. To ensure consistent attribute handling,
+ the barycentric weights are computed relative to the original primitive,
+ not the clipped one. For example, if the left half of triangle ABC
+ below is clipped away, the clipper introduces a new vertex D and
+ rasterizes triangle DBC instead.
+
+ + B (0,1,0)
+ /|\
+ / | \
+ / | \
+ / | \
+ / | \
+ / | \
+ (1,0,0) A +------+------+ C (0,0,1)
+ D
+
+ When we process the clipped triangle, the three vertices available for
+ "pervertexNV" inputs are actually A, B, and C (in undefined order).
+ If vertices "v[0]", "v[1]", and "v[2]" are assigned to A, B, and C,
+ respectively, fragments at A, B, and C will have barycentric coordinates
+ of (1,0,0), (0,1,0), and (0,0,1), respectively. A fragment at the
+ vertex D introduced by the clipper will have a weight like (0.5, 0.0,
+ 0.5) -- exactly the same value it would have if ABC were unclipped.
+
+ (3) Should we have any program interface query API support where
+ application code can inspect the active fragment shader inputs and
+ determine which ones were declared with "pervertexNV"?
+
+ RESOLVED: No. We don't have this for other interpolation qualifiers
+ like "flat" or "noperspective".
+
+ Also, please refer to issues in the GLSL extension specification.
+
+Revision History
+
+ Revision 1 (pbrown)
+ - Internal revisions.
diff --git a/extensions/NV/NV_mesh_shader.txt b/extensions/NV/NV_mesh_shader.txt
new file mode 100644
index 0000000..f415821
--- /dev/null
+++ b/extensions/NV/NV_mesh_shader.txt
@@ -0,0 +1,1082 @@
+Name
+
+ NV_mesh_shader
+
+Name String
+
+ GL_NV_mesh_shader
+
+Contact
+
+ Christoph Kubisch, NVIDIA (ckubisch 'at' nvidia.com)
+ Pat Brown, NVIDIA (pbrown 'at' nvidia.com)
+
+Contributors
+
+ Yury Uralsky, NVIDIA
+ Tyson Smith, NVIDIA
+
+Status
+
+ Shipping
+
+Version
+
+ Last Modified Date: September 17, 2018
+ NVIDIA Revision: 2
+
+Number
+
+ OpenGL Extension #527
+
+Dependencies
+
+ This extension is written against the OpenGL 4.5 Specification
+ (Compatibility Profile), dated June 29, 2017.
+
+ OpenGL 4.5 is required.
+
+ This extension requires support for the OpenGL Shading Language (GLSL)
+ extension "NV_mesh_shader", which can be found at the Khronos Group Github
+ site here:
+
+ https://github.com/KhronosGroup/GLSL
+
+ This extension interacts with ARB_indirect_parameters.
+
+ This extension interacts with NV_command_list.
+
+ This extension interacts with ARB_draw_indirect, EXT_draw_indirect, and
+ NV_vertex_buffer_unified_memory.
+
+ This extension interacts with OVR_multiview
+
+
+Overview
+
+ This extension provides a new mechanism allowing applications to use two
+ new programmable shader types -- the task and mesh shader -- to generate
+ collections of geometric primitives to be processed by fixed-function
+ primitive assembly and rasterization logic. When the task and mesh
+ shaders are drawn, they replace the standard programmable vertex
+ processing pipeline, including vertex array attribute fetching, vertex
+ shader processing, tessellation, and the geometry shader processing.
+
+New Procedures and Functions
+
+ void DrawMeshTasksNV(uint first, uint count);
+
+ void DrawMeshTasksIndirectNV(intptr indirect);
+
+ void MultiDrawMeshTasksIndirectNV(intptr indirect,
+ sizei drawcount,
+ sizei stride);
+
+ void MultiDrawMeshTasksIndirectCountNV( intptr indirect,
+ intptr drawcount,
+ sizei maxdrawcount,
+ sizei stride);
+
+New Tokens
+
+ Accepted by the <type> parameter of CreateShader and returned by the
+ <params> parameter of GetShaderiv:
+
+ MESH_SHADER_NV 0x9559
+ TASK_SHADER_NV 0x955A
+
+ Accepted by the <pname> parameter of GetIntegerv, GetBooleanv, GetFloatv,
+ GetDoublev and GetInteger64v:
+
+ MAX_MESH_UNIFORM_BLOCKS_NV 0x8E60
+ MAX_MESH_TEXTURE_IMAGE_UNITS_NV 0x8E61
+ MAX_MESH_IMAGE_UNIFORMS_NV 0x8E62
+ MAX_MESH_UNIFORM_COMPONENTS_NV 0x8E63
+ MAX_MESH_ATOMIC_COUNTER_BUFFERS_NV 0x8E64
+ MAX_MESH_ATOMIC_COUNTERS_NV 0x8E65
+ MAX_MESH_SHADER_STORAGE_BLOCKS_NV 0x8E66
+ MAX_COMBINED_MESH_UNIFORM_COMPONENTS_NV 0x8E67
+
+ MAX_TASK_UNIFORM_BLOCKS_NV 0x8E68
+ MAX_TASK_TEXTURE_IMAGE_UNITS_NV 0x8E69
+ MAX_TASK_IMAGE_UNIFORMS_NV 0x8E6A
+ MAX_TASK_UNIFORM_COMPONENTS_NV 0x8E6B
+ MAX_TASK_ATOMIC_COUNTER_BUFFERS_NV 0x8E6C
+ MAX_TASK_ATOMIC_COUNTERS_NV 0x8E6D
+ MAX_TASK_SHADER_STORAGE_BLOCKS_NV 0x8E6E
+ MAX_COMBINED_TASK_UNIFORM_COMPONENTS_NV 0x8E6F
+
+ MAX_MESH_WORK_GROUP_INVOCATIONS_NV 0x95A2
+ MAX_TASK_WORK_GROUP_INVOCATIONS_NV 0x95A3
+
+ MAX_MESH_TOTAL_MEMORY_SIZE_NV 0x9536
+ MAX_TASK_TOTAL_MEMORY_SIZE_NV 0x9537
+
+ MAX_MESH_OUTPUT_VERTICES_NV 0x9538
+ MAX_MESH_OUTPUT_PRIMITIVES_NV 0x9539
+
+ MAX_TASK_OUTPUT_COUNT_NV 0x953A
+
+ MAX_DRAW_MESH_TASKS_COUNT_NV 0x953D
+
+ MAX_MESH_VIEWS_NV 0x9557
+
+ MESH_OUTPUT_PER_VERTEX_GRANULARITY_NV 0x92DF
+ MESH_OUTPUT_PER_PRIMITIVE_GRANULARITY_NV 0x9543
+
+
+ Accepted by the <pname> parameter of GetIntegeri_v, GetBooleani_v,
+ GetFloati_v, GetDoublei_v and GetInteger64i_v:
+
+ MAX_MESH_WORK_GROUP_SIZE_NV 0x953B
+ MAX_TASK_WORK_GROUP_SIZE_NV 0x953C
+
+
+ Accepted by the <pname> parameter of GetProgramiv:
+
+ MESH_WORK_GROUP_SIZE_NV 0x953E
+ TASK_WORK_GROUP_SIZE_NV 0x953F
+
+ MESH_VERTICES_OUT_NV 0x9579
+ MESH_PRIMITIVES_OUT_NV 0x957A
+ MESH_OUTPUT_TYPE_NV 0x957B
+
+ Accepted by the <pname> parameter of GetActiveUniformBlockiv:
+
+ UNIFORM_BLOCK_REFERENCED_BY_MESH_SHADER_NV 0x959C
+ UNIFORM_BLOCK_REFERENCED_BY_TASK_SHADER_NV 0x959D
+
+ Accepted by the <pname> parameter of GetActiveAtomicCounterBufferiv:
+
+ ATOMIC_COUNTER_BUFFER_REFERENCED_BY_MESH_SHADER_NV 0x959E
+ ATOMIC_COUNTER_BUFFER_REFERENCED_BY_TASK_SHADER_NV 0x959F
+
+ Accepted in the <props> array of GetProgramResourceiv:
+
+ REFERENCED_BY_MESH_SHADER_NV 0x95A0
+ REFERENCED_BY_TASK_SHADER_NV 0x95A1
+
+ Accepted by the <programInterface> parameter of GetProgramInterfaceiv,
+ GetProgramResourceIndex, GetProgramResourceName, GetProgramResourceiv,
+ GetProgramResourceLocation, and GetProgramResourceLocationIndex:
+
+ MESH_SUBROUTINE_NV 0x957C
+ TASK_SUBROUTINE_NV 0x957D
+
+ MESH_SUBROUTINE_UNIFORM_NV 0x957E
+ TASK_SUBROUTINE_UNIFORM_NV 0x957F
+
+ Accepted by the <stages> parameter of UseProgramStages:
+
+ MESH_SHADER_BIT_NV 0x00000040
+ TASK_SHADER_BIT_NV 0x00000080
+
+Modifications to the OpenGL 4.5 Specification (Compatibility Profile)
+
+ Modify Chapter 3, Dataflow Model, p. 33
+
+ (insert at the end of the section after Figure 3.1, p. 35)
+
+ Figure 3.2 shows a block diagram of the alternate mesh processing pipeline
+ of the GL. The mesh processing pipeline produces a set of output
+ primitives similar to the primitives produced by the conventional GL
+ vertex processing pipeline.
+
+ Work on the mesh pipeline is initiated by the application drawing a
+ set of mesh tasks via an API command. If an optional task shader is
+ active, each task triggers the execution of a task shader work group that
+ will generate a new set of tasks upon completion. Each of these spawned
+ tasks, or each of the original drawn tasks if no task shader is
+ present, triggers the execution of a mesh shader work group that produces
+ an output mesh with a variable-sized number of primitives assembled from
+ vertices in the output mesh. The primitives from these output meshes are
+ processed by the rasterization, fragment shader, per-fragment-operations,
+ and framebuffer pipeline stages in the same manner as primitives produced
+ from draw calls sent to the conventional vertex processing pipeline
+ depicted in Figure 3.1.
+
+ Conventional From Application
+ Vertex |
+ Pipeline v
+ Draw Mesh Tasks <----- Draw Indirect Buffer
+ (Fig 3.1) |
+ | +---+-----+
+ | | |
+ | | |
+ | | Task Shader ---+
+ | | | |
+ | | v |
+ | | Task Generation | Image Load/Store
+ | | | | Atomic Counter
+ | +---+-----+ |<--> Shader Storage
+ | | | Texture Fetch
+ | v | Uniform Block
+ | Mesh Shader ----------+
+ | | |
+ +-------------> + |
+ | |
+ v |
+ Rasterization |
+ | |
+ v |
+ Fragment Shader ------+
+ |
+ v
+ Per-Fragment Operations
+ |
+ v
+ Framebuffer
+
+ Figure 3.2, GL Mesh Processing Pipeline
+
+
+ Modify Chapter 7, Programs and Shaders, p. 84
+
+ (Change the sentence starting with "Shader stages including vertex shaders")
+
+ Shader stages including vertex shaders, tessellation control shaders,
+ tessellation evaluation shaders, geometry shaders, mesh shaders, task
+ shaders, fragment shaders, and compute shaders can be created, compiled, and
+ linked into program objects
+
+ (replace the sentence starting with "A single program
+ object can contain all of these shaders, or any subset thereof.")
+
+ Mesh and Task shaders affect the assembly of primitives from
+ groups of shader invocations (see section 13).
+ A single program object cannot mix mesh and task shader stages
+ with vertex, tessellation or geometry shader stages. Furthermore
+ a task shader stage cannot be combined with a fragment shader stage
+ when the task shader stage is omitted. Other combinations as well
+ as their subsets are possible.
+
+ Modify Section 7.1, Shader Objects, p. 85
+
+ (add following entries to table 7.1)
+
+ type | Shader Stage
+ =================|===============
+ TASK_SHADER_NV | Task shader
+ MESH_SHADER_NV | Mesh shader
+
+ Modify Section 7.3, Program Objects, p.89
+
+ (add to the list of reasons why LinkProgram can fail, p. 92)
+
+ * program contains objects to form either a mesh or task shader (see
+ section 13), and
+ - the program also contains objects to form vertex, tessellation
+ control, tessellation evaluation, or geometry shaders.
+
+ * program contains objects to form a task shader (see section 13), and
+ - the program is not separable and contains no objects to form a mesh
+ shader.
+
+ Modify Section 7.3.1 Program Interfaces, p.96
+
+ (add to the list starting with VERTEX_SUBROUTINE, after GEOMETRY_SUBROUTINE)
+
+ TASK_SUBROUTINE_NV, MESH_SUBROUTINE_NV,
+
+ (add to the list starting with VERTEX_SUBROUTINE_UNIFORM, after
+ GEOMETRY_SUBROUTINE_UNIFORM)
+
+ TASK_SUBROUTINE_UNIFORM_NV, MESH_SUBROUTINE_UNIFORM_NV,
+
+ (add to the list of errors for GetProgramInterfaceiv, p 102,
+ after GEOMETRY_SUBROUTINE_UNIFORM)
+
+ TASK_SUBROUTINE_UNIFORM_NV, MESH_SUBROUTINE_UNIFORM_NV,
+
+ (modify entries for table 7.2 for GetProgramResourceiv, p. 105)
+
+ Property | Supported Interfaces
+ ==================================|=================================
+ ARRAY_SIZE | ..., TASK_SUBROUTINE_UNIFORM_NV,
+ | MESH_SUBROUTINE_UNIFORM_NV
+ ----------------------------------|-----------------------------
+ NUM_COMPATIBLE_SUBROUTINES, | ..., TASK_SUBROUTINE_UNIFORM_NV,
+ COMPATIBLE_SUBROUTINES | MESH_SUBROUTINE_UNIFORM_NV
+ ----------------------------------|-----------------------------
+ LOCATION |
+ ----------------------------------|-----------------------------
+ REFERENCED_BY_VERTEX_SHADER, ... | ATOMIC_COUNTER_BUFFER, ...
+ REFERENCED_BY_TASK_SHADER_NV, |
+ REFERENCED_BY_MESH_SHADER_NV |
+ ----------------------------------|-----------------------------
+
+ (add to list of the sentence starting with "For the properties
+ REFERENCED_BY_VERTEX_SHADER", after REFERENCED_BY_GEOMETRY_SHADER, p. 108)
+
+ REFERENCED_BY_TASK_SHADER_NV, REFERENCED_BY_MESH_SHADER_NV
+
+ (for the description of GetProgramResourceLocation and
+ GetProgramResourceLocationIndex, add to the list of the sentence
+ starting with "For GetProgramResourceLocation, programInterface must
+ be one of UNIFORM,", after GEOMETRY_SUBROUTINE_UNIFORM, p. 114)
+
+ TASK_SUBROUTINE_UNIFORM_NV, MESH_SUBROUTINE_UNIFORM_NV,
+
+ Modify Section 7.4, Program Pipeline Objects, p. 115
+
+ (modify the first paragraph, p. 118, to add new shader stage bits for mesh
+ and task shaders)
+
+ The bits set in <stages> indicate the program stages for which the program
+ object named by program becomes current. These stages may include
+ compute, vertex, tessellation control, tessellation evaluation, geometry,
+ fragment, mesh, and task shaders, indicated respectively by
+ COMPUTE_SHADER_BIT, VERTEX_SHADER_BIT, TESS_CONTROL_SHADER_BIT,
+ TESS_EVALUATION_SHADER_BIT, GEOMETRY_SHADER_BIT, FRAGMENT_SHADER_BIT,
+ MESH_SHADER_BIT_NV, and TASK_SHADER_BIT_NV, respectively. The constant
+ ALL_SHADER_BITS indicates <program> is to be made current for all shader
+ stages.
+
+ (modify the first error in "Errors" for UseProgramStages, p. 118 to allow
+ the use of mesh and task shader bits)
+
+ An INVALID_VALUE error is generated if stages is not the special value
+ ALL_SHADER_BITS, and has any bits set other than VERTEX_SHADER_BIT,
+ COMPUTE_SHADER_BIT, TESS_CONTROL_SHADER_BIT, TESS_EVALUATION_SHADER_BIT,
+ GEOMETRY_SHADER_BIT, FRAGMENT_SHADER_BIT, MESH_SHADER_BIT_NV, and
+ TASK_SHADER_BIT_NV.
+
+
+ Modify Section 7.6, Uniform Variables, p. 125
+
+ (add entries to table 7.4, p. 126)
+
+ Shader Stage | pname for querying default uniform
+ | block storage, in components
+ ==========================|=========================================
+ Task (see section 13) | MAX_TASK_UNIFORM_COMPONENTS_NV
+ Mesh (see section 13) | MAX_MESH_UNIFORM_COMPONENTS_NV
+
+ (add entries to table 7.5, p. 127)
+
+ Shader Stage | pname for querying combined uniform
+ | block storage, in components
+ ==========================|=========================================
+ Task (see section 13) | MAX_COMBINED_TASK_UNIFORM_COMPONENTS_NV
+ Mesh (see section 13) | MAX_COMBINED_MESH_UNIFORM_COMPONENTS_NV
+
+ (add entries to table 7.7, p. 131)
+
+ pname | prop
+ ===========================================|=============================
+ UNIFORM_BLOCK_REFERENCED_BY_TASK_SHADER_NV | REFERENCED_BY_TASK_SHADER_NV
+ UNIFORM_BLOCK_REFERENCED_BY_MESH_SHADER_NV | REFERENCED_BY_MESH_SHADER_NV
+
+ (add entries to table 7.8, p. 132)
+
+ pname | prop
+ ===========================================|=============================
+ ATOMIC_COUNTER_BUFFER_REFERENCED_- | REFERENCED_BY_TASK_SHADER_NV
+ BY_TASK_SHADER_NV |
+ -------------------------------------------|-----------------------------
+ ATOMIC_COUNTER_BUFFER_REFERENCED_- | REFERENCED_BY_MESH_SHADER_NV
+ BY_MESH_SHADER_NV |
+
+ (modify the sentence starting with "The limits for vertex" in 7.6.2
+ Uniform Blocks, p. 136)
+ ... geometry, task, mesh, fragment...
+ MAX_GEOMETRY_UNIFORM_BLOCKS, MAX_TASK_UNIFORM_BLOCKS_NV, MAX_MESH_UNIFORM_-
+ BLOCKS_NV, MAX_FRAGMENT_UNIFORM_BLOCKS...
+
+ (modify the sentence starting with "The limits for vertex", in
+ 7.7 Atomic Counter Buffers, p. 141)
+
+ ... geometry, task, mesh, fragment...
+ MAX_GEOMETRY_ATOMIC_COUNTER_BUFFERS, MAX_TASK_ATOMIC_COUNTER_BUFFERS_NV,
+ MAX_MESH_ATOMIC_COUNTER_BUFFERS_NV, MAX_FRAGMENT_ATOMIC_COUNTER_BUFFERS, ...
+
+
+ Modify Section 7.8 Shader Buffer Variables and Shader Storage Blocks, p. 142
+
+ (modify the sentences starting with "The limits for vertex", p. 143)
+
+ ... geometry, task, mesh, fragment...
+ MAX_GEOMETRY_SHADER_STORAGE_BLOCKS, MAX_TASK_SHADER_STORAGE_BLOCKS_NV,
+ MAX_MESH_SHADER_STORAGE_BLOCKS_NV, MAX_FRAGMENT_SHADER_STORAGE_BLOCKS,...
+
+ Modify Section 7.9 Subroutine Uniform Variables, p. 144
+
+ (modify table 7.9, p. 145)
+
+ Interface | Shader Type
+ ====================|===============
+ TASK_SUBROUTINE_NV | TASK_SHADER_NV
+ MESH_SUBROUTINE_NV | MESH_SHADER_NV
+
+ (modify table 7.10, p. 146)
+
+ Interface | Shader Type
+ ============================|===============
+ TASK_SUBROUTINE_UNIFORM_NV | TASK_SHADER_NV
+ MESH_SUBROUTINE_UNIFORM_NV | MESH_SHADER_NV
+
+
+ Modify Section 7.13 Shader, Program, and Program Pipeline Queries, p. 157
+
+ (add to the list of queries for GetProgramiv, p. 157)
+
+ If <pname> is TASK_WORK_GROUP_SIZE_NV, an array of three integers
+ containing the local work group size of the task shader
+ (see chapter 13), as specified by its input layout qualifier(s), is
+ returned.
+ If <pname> is MESH_WORK_GROUP_SIZE_NV, an array of three integers
+ containing the local work group size of the mesh shader
+ (see chapter 13), as specified by its input layout qualifier(s), is
+ returned.
+ If <pname> is MESH_VERTICES_OUT_NV, the maximum number of vertices the
+ mesh shader (see section 13) will output is returned.
+ If <pname> is MESH_PRIMITIVES_OUT_NV, the maximum number of primitives
+ the mesh shader (see section 13) will output is returned.
+ If <pname> is MESH_OUTPUT_TYPE_NV, the mesh shader output type,
+ which must be one of POINTS, LINES or TRIANGLES, is returned.
+
+ (add to the list of errors for GetProgramiv, p. 159)
+
+ An INVALID_OPERATION error is generated if TASK_WORK_-
+ GROUP_SIZE is queried for a program which has not been linked successfully,
+ or which does not contain objects to form a task shader.
+ An INVALID_OPERATION error is generated if MESH_VERTICES_OUT_NV,
+ MESH_PRIMITIVES_OUT_NV, MESH_OUTPUT_TYPE_NV, or MESH_WORK_GROUP_SIZE_NV
+ are queried for a program which has not been linked
+ successfully, or which does not contain objects to form a mesh shader.
+
+
+ Add new language extending the edits to Section 9.2.8 (Attaching Textures
+ to a Framebuffer) from the OVR_multiview extension that describe how
+ various drawing commands are processed for when multiview rendering is
+ enabled:
+
+ When multiview rendering is enabled, the DrawMeshTasks* commands (section
+ 13.6) will not spawn separate task and mesh shader invocations for each
+ view. Instead, the primitives produced by each mesh shader local work
+ group will be processed separately for each view. For per-vertex and
+ per-primitive mesh shader outputs not qualified with "perviewNV", the
+ single value written for each vertex or primitive will be used for the
+ output when processing each view. For mesh shader outputs qualified with
+ "perviewNV", the output is arrayed and the mesh shader is responsible for
+ writing separate values for each view. When processing output primitives
+ for a view numbered <V>, outputs qualified with "perviewNV" will assume
+ the values for array element <V>.
+
+
+ Modify Section 10.3.11 Indirect Commands in Buffer Objects, p. 400
+
+ (after "and to DispatchComputeIndirect (see section 19)" add)
+
+ and to DrawMeshTasksIndirectNV, MultiDrawMeshTasksIndirectNV,
+ MultiDrawMeshTasksIndirectCountNV (see section 13)
+
+ (add following entries to the table 10.7)
+
+ Indirect Command Name | Indirect Buffer target
+ ====================================|========================
+ DrawMeshTasksIndirectNV | DRAW_INDIRECT_BUFFER
+ MultiDrawMeshTasksIndirectNV | DRAW_INDIRECT_BUFFER
+ MultiDrawMeshTasksIndirectCountNV | DRAW_INDIRECT_BUFFER
+
+
+ Modify Section 11.1.3 Shader Execution, p. 437
+
+ (add after the first paragraph in section 11.1.3, p 437)
+
+ If there is an active program object present for the task or
+ mesh shader stages, the executable code for these
+ active programs is used to process incoming work groups (see
+ chapter 13).
+
+ (add to the list of constants, 11.1.3.5 Texture Access, p. 441)
+
+ * MAX_TASK_TEXTURE_IMAGE_UNITS_NV (for task shaders)
+
+ * MAX_MESH_TEXTURE_IMAGE_UNITS_NV (for mesh shaders)
+
+ (add to the list of constants, 11.1.3.6 Atomic Counter Access, p. 443)
+
+ * MAX_TASK_ATOMIC_COUNTERS_NV (for task shaders)
+
+ * MAX_MESH_ATOMIC_COUNTERS_NV (for mesh shaders)
+
+ (add to the list of constants, 11.1.3.7 Image Access, p. 444)
+
+ * MAX_TASK_IMAGE_UNIFORMS_NV (for task shaders)
+
+ * MAX_MESH_IMAGE_UNIFORMS_NV (for mesh shaders)
+
+ (add to the list of constants, 11.1.3.8 Shader Storage Buffer Access,
+ p. 444)
+
+ * MAX_TASK_SHADER_STORAGE_BLOCKS_NV (for task shaders)
+
+ * MAX_MESH_SHADER_STORAGE_BLOCKS_NV (for mesh shaders)
+
+ (modify the sentence of 11.3.10 Shader Outputs, p. 445)
+
+ A vertex and mesh shader can write to ...
+
+
+
+ Insert new chapter before Chapter 13, Fixed-Function Vertex
+ Post-Processing, p. 505
+
+ Chapter 13, Programmable Mesh Processing
+
+ In addition to the programmable vertex processing pipeline described in
+ Chapters 10 and 11 [[compatibility profile only: and the fixed-function
+ vertex processing pipeline in Chapter 12]], applications may use the mesh
+ pipeline to generate primitives for rasterization. The mesh pipeline
+ generates a collection of meshes using the programmable task and mesh
+ shaders. Task and mesh shaders are created as described in section 7.1
+ using a type parameter of TASK_SHADER_NV and MESH_SHADER_NV, respectively.
+ They are attached to and used in program objects as described in section
+ 7.3.
+
+ Mesh and task shader workloads are formed from groups of work items called
+ work groups and processed by the executable code for a mesh or task shader
+ 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 (see section 4.3.8, "Shared Variables", of the OpenGL Shading
+ Language Specification) and issue memory and control barriers to
+ synchronize with other members of the same work group.
+
+ 13.1 Task Shader Variables
+
+ Task shaders can access uniform variables belonging to the current
+ program object. Limits on uniform storage and methods for manipulating
+ uniforms are described in section 7.6.
+
+ There is a limit to the total amount of memory consumed by output
+ variables in a single task shader work group. This limit, expressed in
+ basic machine units, may be queried by calling GetIntegerv with the value
+ MAX_TASK_TOTAL_MEMORY_SIZE_NV.
+
+ 13.2 Task Shader Outputs
+
+ Each task shader work group can define how many mesh work groups
+ should be generated by writing to gl_TaskCountNV. The maximum
+ number can be queried by GetIntergev using MAX_TASK_OUTPUT_COUNT_NV.
+
+ Furthermore the task work group can output data (qualified with "taskNV")
+ that can be accessed by to the generated mesh work groups.
+
+ 13.3 Mesh Shader Variables
+
+ Mesh shaders can access uniform variables belonging to the current
+ program object. Limits on uniform storage and methods for manipulating
+ uniforms are described in section 7.6.
+ There is a limit to the total size of all variables declared as shared
+ as well as output attributes in a single mesh stage. This limit, expressed
+ in units of basic machine units, may be queried as the value of
+ MAX_MESH_TOTAL_MEMORY_SIZE_NV.
+
+ 13.4 Mesh Shader Inputs
+
+ When each mesh shader work group runs, its invocations have access to
+ built-in variables describing the work group and invocation and also the
+ task shader outputs (qualified with "taskNV") written the task shader that
+ generated the work group. When no task shader is active, the mesh shader
+ has no access to task shader outputs.
+
+ 13.5 Mesh Shader Outputs
+
+ When each mesh shader work group completes, it emits an output mesh
+ consisting of
+
+ * a primitive count, written to the built-in output gl_PrimitiveCountNV;
+
+ * a collection of vertex attributes, where each vertex in the mesh has a
+ set of built-in and user-defined per-vertex output variables and blocks;
+
+ * a collection of per-primitive attributes, where each of the
+ gl_PrimitiveCountNV primitives in the mesh has a set of built-in and
+ user-defined per-primitive output variables and blocks; and
+
+ * an array of vertex index values written to the built-in output array
+ gl_PrimitiveIndicesNV, where each output primitive has a set of one,
+ two, or three indices that identify the output vertices in the mesh used
+ to form the primitive.
+
+ This data is used to generate primitives of one of three types. The
+ supported output primitive types are points (POINTS), lines (LINES), and
+ triangles (TRIANGLES). The vertices output by the mesh shader are assembled
+ into points, lines, or triangles based on the output primitive type in the
+ DrawElements manner described in section 10.4, with the
+ gl_PrimitiveIndicesNV array content serving as index values, and the
+ local vertex attribute arrays as vertex arrays.
+
+ The output arrays are sized depending on the compile-time provided
+ values ("max_vertices" and "max_primitives"), which must be below
+ their appropriate maxima that can be queried via GetIntegerv and
+ MAX_MESH_OUTPUT_PRIMITIVES_NV as well as MAX_MESH_OUTPUT_VERTICES_NV.
+
+ The output attributes are allocated at an implementation-dependent
+ granularity that can be queried via MESH_OUTPUT_PER_VERTEX_GRANULARITY_NV
+ and MESH_OUTPUT_PER_PRIMITIVE_GRANULARITY_NV. The total amount of memory
+ consumed for per-vertex and per-primitive output variables must not exceed
+ an implementation-dependent total memory limit that can be queried by
+ calling GetIntegerv with the enum MAX_MESH_TOTAL_MEMORY_SIZE_NV. The
+ memory consumed by the gl_PrimitiveIndicesNV[] array does not count
+ against this limit.
+
+ 13.6 Mesh Tasks Drawing Commands
+
+ One or more work groups is launched by calling
+
+ void DrawMeshTasksNV( uint first, uint count );
+
+ If there is an active program object for the task shader stage,
+ <count> work groups are processed by the active program for the task
+ shader stage. If there is no active program object for the task shader
+ stage, <count> work groups are instead processed by the active
+ program for the mesh shader stage. The active program for both shader
+ stages will be determined in the same manner as the active program for other
+ pipeline stages, as described in section 7.3. While the individual shader
+ invocations within a work group are executed as a unit, work groups are
+ executed completely independently and in unspecified order.
+ The x component of gl_WorkGroupID of the first active stage will be within
+ the range of [<first> , <first + count - 1>]. The y and z component of
+ gl_WorkGroupID within all stages will be set to zero.
+
+ The maximum number of task or mesh shader work groups that
+ may be dispatched at one time may be determined by calling GetIntegerv
+ with <target> set to MAX_DRAW_MESH_TASKS_COUNT_NV.
+
+ The local work size in each dimension is specified at compile time using
+ an input layout qualifier in one or more of the task or mesh shaders
+ attached to the program; see the OpenGL Shading Language Specification for
+ more information. After the program has been linked, the local work group
+ size of the task or mesh shader may be queried by calling GetProgramiv
+ with <pname> set to TASK_WORK_GROUP_SIZE_NV or MESH_WORK_GROUP_SIZE_NV, as
+ described in section 7.13.
+
+ The maximum size of a task or mesh shader local work group may be
+ determined by calling GetIntegeri_v with <target> set to
+ MAX_TASK_WORK_GROUP_SIZE_NV or MAX_MESH_WORK_GROUP_SIZE_NV, 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 dimensions)
+ may be determined by calling GetIntegerv with pname set to
+ MAX_TASK_WORK_GROUP_INVOCATIONS_NV or MAX_MESH_WORK_GROUP_INVOCATIONS_NV.
+
+ Errors
+
+ An INVALID_OPERATION error is generated if there is no active
+ program for the mesh shader stage.
+
+ An INVALID_VALUE error is generated if <count> exceeds
+ MAX_DRAW_MESH_TASKS_COUNT_NV.
+
+
+ If there is an active program on the task shader stage, each task shader
+ work group writes a task count to the built-in task shader output
+ gl_TaskCountNV. If this count is non-zero upon completion of the task
+ shader, then gl_TaskCountNV work groups are generated and processed by the
+ active program for the mesh shader stage. If this count is zero, no work
+ groups are generated. If the count is greater than MAX_TASK_OUTPUT_COUNT_NV
+ the number of mesh shader work groups generated is undefined.
+ The built-in variables available to the generated mesh shader work groups
+ are identical to those that would be generated if DrawMeshTasksNV were
+ called with no task shader active and with a <count> of gl_TaskCountNV.
+
+ The primitives of the mesh are then processed by the pipeline stages
+ described in subsequent chapters in the same manner as primitives produced
+ by the conventional vertex processing pipeline described in previous
+ chapters.
+
+ The command
+
+ void DrawMeshTasksIndirectNV(intptr indirect);
+
+ typedef struct {
+ uint count;
+ uint first;
+ } DrawMeshTasksIndirectCommandNV;
+
+ is equivalent to calling DrawMeshTasksNV with the parameters sourced from a
+ a DrawMeshTasksIndirectCommandNV struct stored in the buffer currently
+ bound to the DRAW_INDIRECT_BUFFER binding at an offset, in basic machine
+ units, specified by <indirect>. If the <count> read from the indirect
+ draw buffer is greater than MAX_DRAW_MESH_TASKS_COUNT_NV, then the results
+ of this command are undefined.
+
+ Errors
+
+ An INVALID_OPERATION error is generated if there is no active program
+ for the mesh shader stage.
+
+ An INVALID_VALUE error is generated if <indirect> is negative or is
+ not a multiple of the size, in basic machine units, of uint.
+
+ An INVALID_OPERATION error is generated if the command would source
+ data beyond the end of the buffer object.
+
+ An INVALID_OPERATION error is generated if zero is bound to the
+ DRAW_INDIRECT_BUFFER binding.
+
+ The command
+
+ void MultiDrawMeshTasksIndirectNV(intptr indirect,
+ sizei drawcount,
+ sizei stride);
+
+ behaves identically to DrawMeshTasksIndirectNV, except that <indirect> is
+ treated as an array of <drawcount> DrawMeshTasksIndirectCommandNV
+ structures. <indirect> contains the offset of the first element of the
+ array within the buffer currently bound to the DRAW_INDIRECT buffer
+ binding. <stride> specifies the distance, in basic machine units, between
+ the elements of the array. If <stride> is zero, the array elements are
+ treated as tightly packed. <stride> must be a multiple of four, otherwise
+ an INVALID_VALUE error is generated.
+
+ <drawcount> must be positive, otherwise an INVALID_VALUE error will be
+ generated.
+
+ Errors
+
+ In addition to errors that would be generated by
+ DrawMeshTasksIndirect:
+
+ An INVALID_VALUE error is generated if <stride> is neither zero nor a
+ multiple of four.
+
+ An INVALID_VALUE error is generated if <stride> is non-zero and less
+ than the size of DrawMeshTasksIndirectCommandNV.
+
+ An INVALID_VALUE error is generated if <drawcount> is not positive.
+
+ The command
+
+ void MultiDrawMeshTasksIndirectCountNV( intptr indirect,
+ intptr drawcount,
+ sizei maxdrawcount,
+ sizei stride);
+
+ behaves similarly to MultiDrawMeshTasksIndirectNV, except that <drawcount>
+ defines an offset (in bytes) into the buffer object bound to the
+ PARAMETER_BUFFER_ARB binding point at which a single <sizei> typed value
+ is stored, which contains the draw count. <maxdrawcount> specifies the
+ maximum number of draws that are expected to be stored in the buffer.
+ If the value stored at <drawcount> into the buffer is greater than
+ <maxdrawcount>, an implementation stop processing draws after
+ <maxdrawcount> parameter sets.
+
+ Errors
+
+ In addition to errors that would be generated by
+ MultiDrawMeshTasksIndirectNV:
+
+ An INVALID_OPERATION error is generated if no buffer is bound to the
+ PARAMETER_BUFFER binding point.
+
+ An INVALID_VALUE error is generated if <drawcount> (the offset of the
+ memory holding the actual draw count) is not a multiple of four.
+
+ An INVALID_OPERATION error is generated if reading a sizei typed value
+ from the buffer bound to the PARAMETER_BUFFER target at the offset
+ specified by drawcount would result in an out-of-bounds access.
+
+
+New Implementation Dependent State
+
+ Add to Table 23.43, "Program Object State"
+
+ +----------------------------------------------------+-----------+-------------------------+---------------+--------------------------------------------------------+---------+
+ | Get Value | Type | Get Command | Initial Value | Description | Sec. |
+ +----------------------------------------------------+-----------+-------------------------+---------------+--------------------------------------------------------+---------+
+ | TASK_WORK_GROUP_SIZE_NV | 3 x Z+ | GetProgramiv | { 0, ... } | Local work size of a linked mesh stage | 7.13 |
+ | MESH_WORK_GROUP_SIZE_NV | 3 x Z+ | GetProgramiv | { 0, ... } | Local work size of a linked task stage | 7.13 |
+ | MESH_VERTICES_OUT_NV | Z+ | GetProgramiv | 0 | max_vertices size of a linked mesh stage | 7.13 |
+ | MESH_PRIMITIVES_OUT_NV | Z+ | GetProgramiv | 0 | max_primitives size of a linked mesh stage | 7.13 |
+ | MESH_OUTPUT_TYPE_NV | Z+ | GetProgramiv | POINTS | Primitive output type of a linked mesh stage | 7.13 |
+ | UNIFORM_BLOCK_REFERENCED_BY_TASK_SHADER_NV | B | GetActiveUniformBlockiv | FALSE | True if uniform block is referenced by the task stage | 7.6.2 |
+ | UNIFORM_BLOCK_REFERENCED_BY_MESH_SHADER_NV | B | GetActiveUniformBlockiv | FALSE | True if uniform block is referenced by the mesh stage | 7.6.2 |
+ | ATOMIC_COUNTER_BUFFER_REFERENCED_BY_TASK_SHADER_NV | B | GetActiveAtomicCounter- | FALSE | AACB has a counter used by task shaders | 7.7 |
+ | | | Bufferiv | | | |
+ | ATOMIC_COUNTER_BUFFER_REFERENCED_BY_MESH_SHADER_NV | B | GetActiveAtomicCounter- | FALSE | AACB has a counter used by mesh shaders | 7.7 |
+ | | | Bufferiv | | | |
+ +----------------------------------------------------+-----------+-------------------------+---------------+--------------------------------------------------------+---------+
+
+ Add to Table 23.53, "Program Object Resource State"
+
+ +----------------------------------------------------+-----------+-------------------------+---------------+--------------------------------------------------------+---------+
+ | Get Value | Type | Get Command | Initial Value | Description | Sec. |
+ +----------------------------------------------------+-----------+-------------------------+---------------+--------------------------------------------------------+---------+
+ | REFERENCED_BY_TASK_SHADER_NV | Z+ | GetProgramResourceiv | - | Active resource used by task shader | 7.3.1 |
+ | REFERENCED_BY_MESH_SHADER_NV | Z+ | GetProgramResourceiv | - | Active resource used by mesh shader | 7.3.1 |
+ +----------------------------------------------------+-----------+-------------------------+---------------+--------------------------------------------------------+---------+
+
+ Add to Table 23.67, "Implementation Dependent Values"
+
+ +------------------------------------------+-----------+---------------+---------------------+-----------------------------------------------------------------------+--------+
+ | Get Value | Type | Get Command | Minimum Value | Description | Sec. |
+ +------------------------------------------+-----------+---------------+---------------------+-----------------------------------------------------------------------+--------+
+ | MAX_DRAW_MESH_TASKS_COUNT_NV | Z+ | GetIntegerv | 2^32 - 1 | Maximum number of work groups that may be drawn by a single | 13.6 |
+ | | | | | draw mesh tasks command | |
+ | MESH_OUTPUT_PER_VERTEX_GRANULARITY_NV | Z+ | GetIntegerv | - | Per-vertex output allocation granularity for mesh shaders | 13.3 |
+ | MESH_OUTPUT_PER_PRIMITIVE_GRANULARITY_NV | Z+ | GetIntegerv | - | Per-primitive output allocation granularity for mesh shaders | 13.3 |
+ +------------------------------------------+-----------+---------------+---------------------+-----------------------------------------------------------------------+--------+
+
+ Insert Table 23.75, "Implementation Dependent Task Shader Limits"
+
+ +-----------------------------------------+-----------+---------------+---------------------+-----------------------------------------------------------------------+----------+
+ | Get Value | Type | Get Command | Minimum Value | Description | Sec. |
+ +-----------------------------------------+-----------+---------------+---------------------+-----------------------------------------------------------------------+----------+
+ | MAX_TASK_WORK_GROUP_SIZE_NV | 3 x Z+ | GetIntegeri_v | 32 (x), 1 (y,z) | Maximum local size of a task work group (per dimension) | 13.6 |
+ | MAX_TASK_WORK_GROUP_INVOCATIONS_NV | Z+ | GetIntegerv | 32 | Maximum total task shader invocations in a single local work group | 13.6 |
+ | MAX_TASK_UNIFORM_BLOCKS_NV | Z+ | GetIntegerv | 12 | Maximum number of uniform blocks per task program | 7.6.2 |
+ | MAX_TASK_TEXTURE_IMAGE_UNITS_NV | Z+ | GetIntegerv | 16 | Maximum number of texture image units accessible by a task program | 11.1.3.5 |
+ | MAX_TASK_ATOMIC_COUNTER_BUFFERS_NV | Z+ | GetIntegerv | 8 | Number of atomic counter buffers accessed by a task program | 7.7 |
+ | MAX_TASK_ATOMIC_COUNTERS_NV | Z+ | GetIntegerv | 8 | Number of atomic counters accessed by a task program | 11.1.3.6 |
+ | MAX_TASK_IMAGE_UNIFORMS_NV | Z+ | GetIntegerv | 8 | Number of image variables in task program | 11.1.3.7 |
+ | MAX_TASK_SHADER_STORAGE_BLOCKS_NV | Z+ | GetIntegerv | 12 | Maximum number of storage buffer blocks per task program | 7.8 |
+ | MAX_TASK_UNIFORM_COMPONENTS_NV | Z+ | GetIntegerv | 512 | Number of components for task shader uniform variables | 7.6 |
+ | MAX_COMBINED_TASK_UNIFORM_COMPONENTS_NV | Z+ | GetIntegerv | * | Number of words for task shader uniform variables in all uniform | 7.6 |
+ | | | | | blocks, including the default | |
+ | MAX_TASK_TOTAL_MEMORY_SIZE_NV | Z+ | GetIntegerv | 16384 | Maximum total storage size of all variables declared as <shared> and | 13.1 |
+ | | | | | <out> in all task shaders linked into a single program object | |
+ | MAX_TASK_OUTPUT_COUNT_NV | Z+ | GetIntegerv | 65535 | Maximum number of child mesh work groups a single task shader | 13.2 |
+ | | | | | work group can emit | |
+ +-----------------------------------------+-----------+---------------+---------------------+-----------------------------------------------------------------------+----------+
+
+ Insert Table 23.76, "Implementation Dependent Mesh Shader Limits",
+ renumber subsequent tables.
+
+ +-----------------------------------------+-----------+---------------+---------------------+-----------------------------------------------------------------------+----------+
+ | Get Value | Type | Get Command | Minimum Value | Description | Sec. |
+ +-----------------------------------------+-----------+---------------+---------------------+-----------------------------------------------------------------------+----------+
+ | MAX_MESH_WORK_GROUP_SIZE_NV | 3 x Z+ | GetIntegeri_v | 32 (x), 1 (y,z) | Maximum local size of a mesh work group (per dimension) | 13.6 |
+ | MAX_MESH_WORK_GROUP_INVOCATIONS_NV | Z+ | GetIntegerv | 32 | Maximum total mesh shader invocations in a single local work group | 13.6 |
+ | MAX_MESH_UNIFORM_BLOCKS_NV | Z+ | GetIntegerv | 12 | Maximum number of uniform blocks per mesh program | 7.6.2 |
+ | MAX_MESH_TEXTURE_IMAGE_UNITS_NV | Z+ | GetIntegerv | 16 | Maximum number of texture image units accessible by a mesh shader | 11.1.3.5 |
+ | MAX_MESH_ATOMIC_COUNTER_BUFFERS_NV | Z+ | GetIntegerv | 8 | Number of atomic counter buffers accessed by a mesh shader | 7.7 |
+ | MAX_MESH_ATOMIC_COUNTERS_NV | Z+ | GetIntegerv | 8 | Number of atomic counters accessed by a mesh shader | 11.1.3.6 |
+ | MAX_MESH_IMAGE_UNIFORMS_NV | Z+ | GetIntegerv | 8 | Number of image variables in mesh shaders | 11.1.3.7 |
+ | MAX_MESH_SHADER_STORAGE_BLOCKS_NV | Z+ | GetIntegerv | 12 | Maximum number of storage buffer blocks per task program | 7.8 |
+ | MAX_MESH_UNIFORM_COMPONENTS_NV | Z+ | GetIntegerv | 512 | Number of components for mesh shader uniform variables | 7.6 |
+ | MAX_COMBINED_MESH_UNIFORM_COMPONENTS_NV | Z+ | GetIntegerv | * | Number of words for mesh shader uniform variables in all uniform | 7.6 |
+ | | | | | blocks, including the default | |
+ | MAX_MESH_TOTAL_MEMORY_SIZE_NV | Z+ | GetIntegerv | 16384 | Maximum total storage size of all variables declared as <shared> and | 13.3 |
+ | | | | | <out> in all mesh shaders linked into a single program object | |
+ | MAX_MESH_OUTPUT_PRIMITIVES_NV | Z+ | GetIntegerv | 256 | Maximum number of primitives a single mesh work group can emit | 13.5 |
+ | MAX_MESH_OUTPUT_VERTICES_NV | Z+ | GetIntegerv | 256 | Maximum number of vertices a single mesh work group can emit | 13.5 |
+ | MAX_MESH_VIEWS_NV | Z+ | GetIntegerv | 1 | Maximum number of multi-view views that can be used in a mesh shader | |
+ +-----------------------------------------+-----------+---------------+---------------------+-----------------------------------------------------------------------+----------+
+
+
+Interactions with ARB_indirect_parameters
+
+ If ARB_indirect_parameters is not supported, remove the
+ MultiDrawMeshTasksIndirectCountNV function.
+
+Interactions with NV_command_list
+
+ Modify the subsection 10.X.1 State Objects
+
+ (add after the first paragraph of the description of the StateCaptureNV
+ command)
+
+ When programs with active mesh or task stages are used, the
+ base primitive mode must be set to GL_POINTS.
+
+ (add to the list of errors)
+
+ INVALID_OPERATION is generated if <basicmode> is not GL_POINTS
+ when the mesh or task shaders are active.
+
+ Modify subsection 10.X.2 Drawing with Commands
+
+ (add a new paragraph before "None of the commands called by")
+
+ When mesh or task shaders are active the DRAW_ARRAYS_COMMAND_NV
+ must be used to draw mesh tasks. The fields of the
+ DrawArraysCommandNV will be interpreted as follows:
+
+ DrawMeshTasksNV(cmd->first, cmd->count);
+
+Interactions with ARB_draw_indirect, EXT_draw_indirect, and
+NV_vertex_buffer_unified_memory
+
+ When the ARB_draw_indirect or EXT_draw_indirect extension is supported in
+ addition to NV_vertex_buffer_unified_memory, applications can enable
+ DRAW_INDIRECT_UNIFIED_NV to specify that indirect draw data are sourced
+ from a pre-programmed memory range. For such implementations, we add a
+ paragraph to spec language for DrawMeshTasksIndirectNV, also inherited by
+ MultiDrawMeshTasksIndirectNV and MultiDrawMeshTasksIndirectCountNV:
+
+ While DRAW_INDIRECT_UNIFIED_NV is enabled, DrawMeshTasksIndirectNV
+ sources its arguments from the address specified by the command
+ BufferAddressRange where <pname> is DRAW_INDIRECT_ADDRESS_NV and
+ <index> is zero, added to the <indirect> parameter. If the draw
+ indirect address range does not belong to a buffer object that is
+ resident at the time of the Draw, undefined results, possibly
+ including program termination, may occur.
+
+ Additionally, the errors specified for DRAW_INDIRECT_BUFFER accesses for
+ DrawMeshTasksIndirectNV are modified as follows:
+
+ An INVALID_OPERATION error is generated if DRAW_INDIRECT_UNIFIED_NV is
+ disabled and zero is bound to the DRAW_INDIRECT_BUFFER binding.
+
+ An INVALID_OPERATION error is generated if DRAW_INDIRECT_UNIFIED_NV is
+ disabled and the command would source data beyond the end of the
+ DRAW_INDIRECT_BUFFER binding.
+
+ An INVALID_OPERATION error is generated if DRAW_INDIRECT_UNIFIED_NV is
+ enabled and the command would source data beyond the end of the
+ DRAW_INDIRECT_ADDRESS_NV buffer address range.
+
+
+Interactions with OVR_multiview
+
+ Modify the new section "9.2.2.2 (Multiview Images)"
+
+ (insert a new entry to the list following
+ "In this mode there are several restrictions:")
+
+ - in mesh shaders only the appropriate per-view outputs are
+ used.
+
+Issues
+
+ (1) Should we use a new command to specify work to be processed by task
+ and mesh shaders?
+
+ RESOLVED: Yes. Using a separate draw call helps to clearly
+ differentiate task and mesh shader processing for the existing vertex
+ processing performed by the standard OpenGL vertex processing pipeline
+ with its vertex, tessellation, and geometry shaders.
+
+ (2) What name should we use for the draw calls that spawn task and mesh
+ shaders?
+
+ RESOLVED: For basic draws, we use the following command:
+
+ void DrawMeshTasksNV(uint first, uint count);
+
+ The first <first> and <count> parameters specifying a range of mesh task
+ numbers to process by the task and/or mesh shaders.
+
+ Since the programming model of mesh and task shaders is very similar to
+ that of compute shaders, we considered using an interface similar to
+ DispatchCompute(), such as:
+
+ void DrawWorkGroupsNV(uint num_groups_x, uint num_groups_y,
+ uint num_groups_z);
+
+ We ultimately decided to not use such a generic name. It might be
+ useful in the future to give compute shaders the ability to spawn
+ "draws" in the future, and it's not clear that the programming model for
+ such a design would look anything like mesh and task shaders.
+
+ The existing graphics draw calls DrawArrays() and DrawElements()
+ directly or indirectly refer to elements of a vertex array. Since the
+ programming model here spawns generic work that ultimately produces a
+ set of (likely connected) output primitives, we use the word "mesh" to
+ refer to the output of this pipeline and "tasks" to refer to the fact
+ that the draw call is spawning generic work groups to produce such these
+ "meshes".
+
+ NOTE: In order to minimize divergence from the programming model for
+ compute shaders, mesh shaders use the same three-dimensional local work
+ group concept used by compute shaders. However, the hardware used for
+ task and mesh shaders is more limited and supports only one-dimensional
+ work groups. We decided to only use one "dimension" in the draw call to
+ keep the API simple and reflect the limitation.
+
+ (3) Should we be able to dispatch a range of work groups that doesn't
+ start at zero?
+
+ RESOLVED: Yes. When porting application code from using regular vertex
+ processing to mesh shader processing, the use of an implicit offset via
+ the <first> parameter should be helpful as it is in standard DrawArrays
+ calls. We think it's likely that applications will store information
+ about tasks to process in a single array with global task numbers. In
+ this case, the draw call with an offset allows applications to specify a
+ range of this array of tasks to process.
+
+ (4) Should we support separable program objects with mesh and task
+ shaders, where one program provides a task shader and a second
+ program provides a mesh shader that interfaces with it?
+
+ RESOLVED: Yes. Supporting separable program objects is not difficult
+ and may be useful in some cases. For example, one might use a single
+ task shader that could be used for common processing of different types
+ of geometry (e.g., evaluating visibililty via a bounding box) while
+ using different mesh shaders to generate different types of primitives.
+
+ (5) Should we have queryable limits on the total amount of output memory
+ consumed by mesh or task shaders?
+
+ RESOLVED: Yes. We have implementation-dependent limits on the total
+ amount of output memory consumed by mesh and task shaders that can be
+ queried using MAX_MESH_TOTAL_MEMORY_SIZE_NV and
+ MAX_TASK_TOTAL_MEMORY_SIZE_NV. For each per-vertex or per-primitive
+ output attribute in a mesh shader, memory is allocated separately for
+ each vertex or primitive allocated by the shader. The total number of
+ vertices or primitives used for this allocation is determined by taking
+ the maximum vertex and primitive counts declared in the mesh shader and
+ padding to implementation-dependent granularities that can be queried
+ using MESH_OUTPUT_PER_VERTEX_GRANULARITY_NV and
+ MESH_OUTPUT_PER_PRIMITIVE_GRANULARITY_NV.
+
+ (6) Should we have any MultiDrawMeshTasksIndirectNV, to draw
+ multiple sets of mesh tasks in one call?
+
+ RESOLVED: Yes, we support "multi-draw" APIs to for consistency with
+ the standard vertex pipeline. When using these APIs, each individual
+ "draw" has its own structure stored in a buffer object. If mesh or task
+ shaders need to determine which draw is being processed, the built-in
+ gl_DrawIDARB can be used for that purpose.
+
+ (7) Do we support transform feedback with mesh shaders?
+
+ RESOLVED: No. In the initial implementation of this extension, the
+ hardware doesn't support it.
+
+ (8) When using multi-view (OVR_multiview), how do we broadcast the
+ primitive to multiple layers or viewports?
+
+ RESOLVED: When the OVR_multiview extension is enabled in a vertex
+ shader, the layout qualifier:
+
+ layout(num_views = 2) in;
+
+ indicates that the vertex shader should be run separately for two views,
+ where the shader can use the built-in input gl_ViewIDOVR to determine
+ which view is being processed. A separate set of primitives is
+ generated for each view, and each is rasterized into a separate
+ framebuffer layer.
+
+ When the "num_views" layout qualifier for the OVR_multiview extension is
+ enabled in a mesh shader, the semantics are slightly different. Instead
+ of running a separate mesh shader invocation for each view, a single
+ invocation is generated to process all views. The view count from the
+ layout qualifier indicates the size of the extra array dimension for
+ "arrayed" per-vertex and per-primitive outputs qualified with
+ "perviewNV". The set of primitives generated by the mesh shader will be
+ broadcast separately to each view. For per-vertex or per-primitive
+ outputs not qualified with "perviewNV", the single value written by the
+ mesh shader for each vertex/primitive will be used for each view. For
+ outputs qualified with "perviewNV", each view will use a separate value
+ from the corresponding "arrayed" output.
+
+ (9) Should we support NV_gpu_program5-style assembly programs for mesh
+ and task shaders?
+
+ RESOLVED: No. We do provide a GLSL extension, also called
+ "GL_NV_mesh_shader".
+
+ Also, please refer to issues in the GLSL extension specification.
+
+Revision History
+
+ Revision 2, September 17, 2018 (pbrown)
+ - Prepare specification for publication.
+
+ Revision 1 (ckubsich)
+ - Internal revisions.
diff --git a/extensions/NV/NV_representative_fragment_test.txt b/extensions/NV/NV_representative_fragment_test.txt
new file mode 100644
index 0000000..7b13a8a
--- /dev/null
+++ b/extensions/NV/NV_representative_fragment_test.txt
@@ -0,0 +1,180 @@
+Name
+
+ NV_representative_fragment_test
+
+Name Strings
+
+ GL_NV_representative_fragment_test
+
+Contacts
+
+ Christoph Kubisch, NVIDIA Corporation (ckubisch 'at' nvidia.com)
+ Kedarnath Thangudu, NVIDIA Corporation (kthangudu 'at' nvidia.com)
+
+Contributors
+
+ Jeff Bolz, NVIDIA Corporation
+ Pat Brown, NVIDIA Corporation
+ Eric Werness, NVIDIA Corporation
+
+Status
+
+ Shipping
+
+Version
+
+ Last Modified Date: September 15, 2018
+ NVIDIA Revision: 2
+
+Number
+
+ OpenGL Extension #528
+
+Dependencies
+
+ This extension is written against the OpenGL 4.6 Specification
+ (Compatibility Profile), dated May 14, 2018.
+
+ OpenGL 4.5 is required.
+
+Overview
+
+ This extension provides a new _representative fragment test_ that allows
+ implementations to reduce the amount of rasterization and fragment
+ processing work performed for each point, line, or triangle primitive. For
+ any primitive that produces one or more fragments that pass all other
+ early fragment tests, the implementation is permitted to choose one or
+ more "representative" fragments for processing and discard all other
+ fragments. For draw calls rendering multiple points, lines, or triangles
+ arranged in lists, strips, or fans, the representative fragment test is
+ performed independently for each of those primitives.
+
+ This extension is useful for applications that use an early render pass
+ to determine the full set of primitives that would be visible in the final
+ scene. In this render pass, such applications would set up a fragment
+ shader that enables early fragment tests and writes to an image or shader
+ storage buffer to record the ID of the primitive that generated the
+ fragment. Without this extension, the shader would record the ID
+ separately for each visible fragment of each primitive. With this
+ extension, fewer stores will be performed, particularly for large
+ primitives.
+
+ The representative fragment test has no effect if early fragment tests are
+ not enabled via the fragment shader. The set of fragments discarded by the
+ representative fragment test is implementation-dependent and may vary from
+ frame to frame. In some cases, the representative fragment test may not
+ discard any fragments for a given primitive.
+
+
+New Procedures and Functions
+
+ None
+
+New Tokens
+
+ Accepted by the <cap> parameter of Enable, Disable, and IsEnabled,
+ and by the <pname> parameter of GetBooleanv, GetIntegerv,
+ GetFloatv, and GetDoublev:
+
+ REPRESENTATIVE_FRAGMENT_TEST_NV 0x937F
+
+Modifications to the OpenGL 4.6 Specification (Compatibility Profile)
+
+ Modify Section 14.9, Early Per-Fragment Tests (p. 578)
+
+ (modify second pararaph of the section, p. 578, to document that there are
+ now four optional early fragment tests)
+
+ Three fragment operations are performed, and a further four are
+ optionally performed on each fragment, ...
+
+ (modify the last paragraph, p. 578, to list the new early fragment test)
+
+ If early per-fragment operations are enabled, these tests are also
+ performed:
+
+ * the stencil test (see section 17.3.3);
+ * the depth buffer test (see section 17.3.4); and
+ * the representative fragment test (see section 17.3.X)
+ * occlusion query sample counting (see section 17.3.5)
+
+
+ Modify Section 14.9.4, The Early Fragment Test Qualifier, p. 582
+
+ (modify the first paragraph of the section, p. 582, to enumerate the new
+ test)
+
+ The stencil test, depth buffer test, representative fragment test, and
+ occlusion query sample counting are performed if and only if early
+ fragment tests are enabled in the active fragment shader (see section
+ 15.2.4). ...
+
+
+ Insert new section before Section 17.3.5, Occlusion Queries (p. 614)
+
+ Section 17.3.X, Representative Fragment Test
+
+ The representative fragment test allows implementations to reduce the
+ amount of rasterization and fragment processing work performed for each
+ point, line, or triangle primitive. For any primitive that produces one or
+ more fragments that pass all prior early fragment tests, the
+ implementation is permitted to choose one or more "representative"
+ fragments for processing and discard all other fragments. For draw calls
+ rendering multiple points, lines, or triangles arranged in lists, strips,
+ or fans, the representative fragment test is performed independently for
+ each of those primitives. The set of fragments discarded by the
+ representative fragment test is implementation-dependent. In some cases,
+ the representative fragment test may not discard any fragments for a given
+ primitive.
+
+ This test is enabled or disabled using Enable or Disable with the target
+ REPRESENTATIVE_FRAGMENT_NV. If early fragment tests (section 15.2.4) are
+ not enabled in the active fragment shader, the representative fragment
+ test has no effect, even if enabled.
+
+
+Additions to the AGL/GLX/WGL Specifications
+
+ None.
+
+New State
+
+ Get Value Type Get Command Initial Value Description Sec Attribute
+ ------------------------------------ ---- ----------- ------------- ------------------------- ------ --------------
+ REPRESENTATIVE_FRAGMENT_TEST_NV B IsEnabled GL_FALSE Representative fragment 17.3.X enable
+ test
+
+New Implementation Dependent State
+
+ None
+
+Issues
+
+ (1) Since the representative fragment test does not have guaranteed
+ behavior, it is sort of a hint. Should we use the existing hint
+ mechanisms for this extension or simply add an enable?
+
+ RESOLVED: Use an enable. Hints are rarely used in OpenGL, and the
+ "FASTEST" vs. "NICEST" vs. "DONT_CARE" doesn't map reasonably to the
+ representative fragment test.
+
+ (2) Should this functionality be exposed as a sub-feature of the depth or
+ stencil tests, as its own separate per-fragment test, or as some piece
+ of state controlling primitive rasterization?
+
+ RESOLVED: Expose as a per-fragment test. This test is largely orthogonal
+ to depth testing, other than it is supposed to run after the depth
+ testing. So coupling it to the depth test doesn't make sense. Coupling
+ the feature to rasterization also doesn't make too much sense, because the
+ rasterization pipeline stage discarding fragments for this test would
+ depend on a later pipeline stages performing other per-fragment tests
+ (such as the depth test).
+
+
+Revision History
+
+ Revision 2, September 15, 2018 (pbrown)
+ - Prepare specification for publication.
+
+ Revision 1 (ckubisch and kthangudu)
+ - Internal Revisions
diff --git a/extensions/NV/NV_scissor_exclusive.txt b/extensions/NV/NV_scissor_exclusive.txt
new file mode 100644
index 0000000..d8cf838
--- /dev/null
+++ b/extensions/NV/NV_scissor_exclusive.txt
@@ -0,0 +1,234 @@
+Name
+
+ NV_scissor_exclusive
+
+Name Strings
+
+ GL_NV_scissor_exclusive
+
+Contact
+
+ Pat Brown, NVIDIA Corporation (pbrown 'at' nvidia.com)
+
+Contributors
+
+ Mark Kilgard, NVIDIA
+
+Status
+
+ Shipping
+
+Version
+
+ Last Modified: September 15, 2018
+ Revision: 1
+
+Number
+
+ OpenGL Extension #529
+
+Dependencies
+
+ This extension is written against the OpenGL 4.5 Specification
+ (Compatibility Profile), dated October 24, 2016.
+
+ OpenGL 4.5 is required.
+
+ This extension is written against the OpenGL Shading Language
+ Specification, version 4.50, dated April 14, 2016.
+
+ This extension trivially interacts with EXT_draw_buffers2,
+ EXT_transform_feedback, NV_transform_feedback, and
+ EXT_direct_state_access.
+
+Overview
+
+ In unextended OpenGL, applications can enable a per-viewport scissor test
+ (SCISSOR_TEST) where fragments are discarded if their (x,y) coordinates
+ lie outside the corresponding scissor rectangle. In this extension, we
+ provide a separate per-viewport exclusive scissor test, where fragments
+ are discarded if their (x,y) coordinates lie *inside* the corresponding
+ exclusive scissor rectangle.
+
+ The regular (inclusive) scissor test and exclusive scissor test are
+ orthogonal; applications can enable either or both tests for each
+ viewport. If both tests are enabled, fragments will be discarded unless
+ their (x,y) coordinates are both inside the regular scissor rectangle and
+ outside the exclusive scissor rectangle.
+
+New Procedures and Functions
+
+ void ScissorExclusiveArrayvNV(uint first, sizei count, const int *v);
+ void ScissorExclusiveNV(int x, int y, sizei width, sizei height);
+
+New Tokens
+
+ Accepted by the <cap> parameter of Enable, Disable, and IsEnabled, by the
+ <target> parameter of Enablei, Disablei, IsEnabledi, EnableIndexedEXT,
+ DisableIndexedEXT, and IsEnabledIndexedEXT, and by the <pname> parameter
+ of GetBooleanv, GetIntegerv, GetInteger64v, GetFloatv, GetDoublev,
+ GetDoubleIndexedv, GetBooleani_v, GetIntegeri_v, GetInteger64i_v,
+ GetFloati_v, GetDoublei_v, GetBooleanIndexedvEXT, GetIntegerIndexedvEXT,
+ and GetFloatIndexedvEXT:
+
+ SCISSOR_TEST_EXCLUSIVE_NV 0x9555
+
+ Accepted by the <pname> parameter of GetBooleanv, GetIntegerv,
+ GetInteger64v, GetFloatv, GetDoublev, GetBooleani_v, GetIntegeri_v,
+ GetInteger64i_v, GetFloati_v, GetDoublei_v, GetDoubleIndexedv,
+ GetBooleanIndexedvEXT, GetIntegerIndexedvEXT, and GetFloatIndexedvEXT:
+
+ SCISSOR_BOX_EXCLUSIVE_NV 0x9556
+
+Modifications to the OpenGL 4.5 Specification (Compatibility Profile)
+
+ Insert a new section after section 14.9.2, Scissor Test (p. 560)
+
+ 14.9.3 Exclusive Scissor Test
+
+ Like the scissor test (section 14.9.2), the exclusive scissor test
+ determines if (x_w, y_w) lies outside the exclusive scissor rectangles
+ defined by four values for each viewport. These values are set with
+
+ void ScissorExclusiveArrayvNV(uint first, sizei count, const int *v);
+ void ScissorExclusiveNV(int x, int y, sizei width, sizei height);
+
+ ScissorExclusiveArrayvNV defines a set of exclusive scissor rectangles that
+ are each applied to the corresponding viewport (see section 13.6.1).
+ <first> specifies the index of the first exclusive scissor rectangle to
+ modify, and <count> specifies the number of scissor rectangles. <v>
+ specifies an array of 4*<count> integers, where each group of four
+ integers specifies the left column, bottom row, width, and height (in that
+ order) of an individual exclusive scissor rectangle.
+
+ ScissorExclusiveNV is equivalent to calling ScissorExclusiveArrayvNV with
+ <first> set to 0, <count> set to the value of MAX_VIEWPORTS, and <v>
+ filled with an array of 4*MAX_VIEWPORTS integer, with each group of four
+ integers set to <x>, <y>, <width>, and <height>, respectively.
+
+ When enabled, the exclusive scissor test passes only if the fragment is
+ outside the selected exclusive scissor rectangle, which is the case if
+ any of the following conditions is true:
+
+ * x_w < left,
+ * x_w >= left + width,
+ * y_w < bottom, or
+ * y_w >= bottom + height.
+
+ Otherwise, the test fails and the fragment is discarded. For points,
+ lines, and polygons, the scissor rectangle for a primitive is selected in
+ the same manner as the viewport (see section 13.6.1). For bitmaps, pixel
+ rectangles and buffer clears (see section 17.4.3), the scissor rectangle
+ numbered zero is used for the scissor test.
+
+ Errors
+
+ An INVALID_VALUE error is generated by ScissorExclusiveArrayvNV if
+ <first>+<count> is greater than the value of MAX_VIEWPORTS.
+
+ An INVALID_VALUE error is generated if width or height is negative.
+
+ The exclusive scissor test is enabled or disabled for all viewports using
+ Enable or Disable with target SCISSOR_TEST_EXCLUSIVE_NV. The test is enabled or
+ disabled for a specific viewport using Enablei or Disablei with the
+ constant SCISSOR_TEST_EXCLUSIVE_NV and the index of the selected viewport.
+ When disabled, it is as if the exclusive scissor test always passes. The
+ value of the scissor test enable for viewport <i> can be queried by
+ calling IsEnabledi with target SCISSOR_TEST_EXCLUSIVE_NV and index <i>.
+ The value of the exclusive scissor test enable for viewport zero may also
+ be queried by calling IsEnabled with the same target, but no index
+ parameter.
+
+ Errors
+
+ An INVALID_VALUE error is generated by Enablei, Disablei and
+ IsEnabledi if target is SCISSOR_TEST_EXCLUSIVE_NV and <index> is
+ greater than or equal to the value of MAX_VIEWPORTS.
+
+ The state required for the exclusive scissor test consists of four integer
+ values per viewport, and a bit indicating whether the test is enabled or
+ disabled for each viewport. In the initial state for all viewports, the
+ exclusive scissor test is disabled and the exclusive scissor rectangle has
+ zero values for all of left, bottom, width, and height.
+
+Interactions with EXT_draw_buffers2 or EXT_transform_feedback or
+NV_transform_feedback or EXT_direct_state_access
+
+ Ignore references to GetBooleanIndexedvEXT or GetIntegerIndexedvEXT if
+ none of EXT_draw_buffers2, EXT_transform_feedback, NV_transform_feedback,
+ or EXT_direct_state_access are supported.
+
+Interactions with EXT_draw_buffers2 or EXT_direct_state_access
+
+ Ignore references to EnableIndexedEXT, DisableIndexedEXT, and
+ IsEnabledIndexedEXT if neither of EXT_draw_buffers2 or
+ EXT_direct_state_access are supported.
+
+Interactions with EXT_direct_state_access
+
+ Ignore references to GetFloatIndexedvEXT and GetDoubleIndexedvEXT if
+ EXT_direct_state_access is not supported.
+
+Additions to the AGL/GLX/WGL Specifications
+
+ None
+
+Errors
+
+ Errors are described in "Errors" sections of the spec language above.
+
+New State
+
+ Get Value Type Get Command Initial Value Description Sec Attribute
+ ------------------------ ---------- ------------ ------------- ---------------------------- ----- ---------
+ SCISSOR_TEST_EXCLUSIVE_NV 16* x B IsEnabledi FALSE Exclusive scissoring enabled 14.9.3 scissor/enable
+ SCISSOR_BOX_EXCLUSIVE_NV 16* x 4 x Z GetIntegeri_v (0,0,0,0) Exclusive scissor rectangles 14.9.3 scissor
+
+New Implementation Dependent State
+
+ None
+
+Issues
+
+ (1) How should we name this extension?
+
+ RESOLVED: NV_scissor_exclusive. It defines scissor rectangles and
+ tests that are "exclusive", where fragments pass only if they are
+ outside the rectangle.
+
+ (2) What should we use for the default values for exclusive scissor
+ rectangles?
+
+ RESOLVED: For inclusive scissors, the default values for an OpenGL
+ context are taken from the size of the drawable first used with the
+ context. While the inclusive scissor test is initially disabled, the
+ default state allows for "normal" unscissored rendering to that drawable
+ if the test is enabled without explicitly programming a scissor
+ rectangle.
+
+ If we used similar state for exclusive scissors, enabling the exclusive
+ scissor test without programming a rectangle would scissor out all
+ rendering to such drawables. Instead, we specify the default rectangles
+ as (0,0,0,0), which would cause the exclusive scissor test to discard
+ nothing if enabled without programming a rectangle. Additionally,
+ this approach makes the default state independent of the drawable first
+ used with the OpenGL context.
+
+ (3) How does the exclusive scissor interact with the functionality
+ of EXT_window_rectangles?
+
+ RESOLVED: The exclusive scissor, as with the inclusive scissor, is orthogonal
+ to the window rectangles testing introduced by EXT_window_rectangles.
+
+ The window rectangle testing applies to ALL viewports whereas the
+ exclusive scissor, as with the inclusive scissor, are selected by the
+ particular viewport index selected for rasterization.
+
+ Additionally window rectangle testing is only support rendering
+ to framebuffer objects (FBOs) whereas the exclusive scissor,
+ as with the conventional inclusive scissor, works on all drawable.
+
+Revision History
+
+ Revision 1 (pbrown)
+ - Internal revisions.
diff --git a/extensions/NV/NV_shader_texture_footprint.txt b/extensions/NV/NV_shader_texture_footprint.txt
new file mode 100644
index 0000000..b6bc1f3
--- /dev/null
+++ b/extensions/NV/NV_shader_texture_footprint.txt
@@ -0,0 +1,323 @@
+Name
+
+ NV_shader_texture_footprint
+
+Name Strings
+
+ GL_NV_shader_texture_footprint
+
+Contact
+
+ Chris Lentini, NVIDIA (clentini 'at' nvidia.com)
+ Pat Brown, NVIDIA (pbrown 'at' nvidia.com)
+
+Contributors
+
+ Jeff Bolz, NVIDIA
+ Daniel Koch, NVIDIA
+
+Status
+
+ Shipping
+
+Version
+
+ Last Modified Date: September 15, 2018
+ NVIDIA Revision: 1
+
+Number
+
+ OpenGL Extension #530
+
+Dependencies
+
+ This extension is written against the OpenGL 4.6 Specification
+ (Compatibility Profile), dated July 30, 2017.
+
+ OpenGL 4.5 is required.
+
+ This extension requires support for the OpenGL Shading Language (GLSL)
+ extension "NV_shader_texture_footprint", which can be found at the Khronos
+ Group Github site here:
+
+ https://github.com/KhronosGroup/GLSL
+
+Overview
+
+ This extension adds OpenGL API support for the OpenGL Shading Language
+ (GLSL) extension "NV_shader_texture_footprint". That extension adds a new
+ set of texture query functions ("textureFootprint*NV") to GLSL. These
+ built-in functions prepare to perform a filtered texture lookup based on
+ coordinates and other parameters passed in by the calling code. However,
+ instead of returning data from the provided texture image, these query
+ functions instead return data identifying the _texture footprint_ for an
+ equivalent texture access. The texture footprint identifies a set of
+ texels that may be accessed in order to return a filtered result for the
+ texture access.
+
+ The footprint itself is a structure that includes integer values that
+ identify a small neighborhood of texels in the texture being accessed and
+ a bitfield that indicates which texels in that neighborhood would be used.
+ Each bit in the returned bitfield identifies whether any texel in a small
+ aligned block of texels would be fetched by the texture lookup. The size
+ of each block is specified by an access _granularity_ provided by the
+ shader. The minimum granularity supported by this extension is 2x2 (for
+ 2D textures) and 2x2x2 (for 3D textures); the maximum granularity is
+ 256x256 (for 2D textures) or 64x32x32 (for 3D textures). Each footprint
+ query returns the footprint from a single texture level. When using
+ minification filters that combine accesses from multiple mipmap levels,
+ shaders must perform separate queries for the two levels accessed ("fine"
+ and "coarse"). The footprint query also returns a flag indicating if the
+ texture lookup would access texels from only one mipmap level or from two
+ neighboring levels.
+
+ This extension should be useful for multi-pass rendering operations that
+ do an initial expensive rendering pass to produce a first image that is
+ then used as a texture for a second pass. If the second pass ends up
+ accessing only portions of the first image (e.g., due to visibility), the
+ work spent rendering the non-accessed portion of the first image was
+ wasted. With this feature, an application can limit this waste using an
+ initial pass over the geometry in the second image that performs a
+ footprint query for each visible pixel to determine the set of pixels that
+ it needs from the first image. This pass would accumulate an aggregate
+ footprint of all visible pixels into a separate "footprint texture" using
+ shader atomics. Then, when rendering the first image, the application can
+ kill all shading work for pixels not in this aggregate footprint.
+
+ The implementation of this extension has a number of limitations. The
+ texture footprint query functions are only supported for two- and
+ three-dimensional textures (TEXTURE_2D, TEXTURE_3D). Texture footprint
+ evaluation only supports the CLAMP_TO_EDGE wrap mode; results are
+ undefined for all other wrap modes. The implementation supports only a
+ limited set of granularity values and does not support separate coverage
+ information for each texel in the original texture.
+
+
+New Procedures and Functions
+
+ None
+
+New Tokens
+
+ None
+
+Additions to Chapter 8 of the OpenGL 4.6 (Compatibility Profile) Specification
+(Textures and Samplers)
+
+ (add a new section immediately after section 8.15, Texture Magnification)
+
+ Section 8.X, Texture Footprint Queries
+
+ The OpenGL Shading Language provides a collection of built-in functions,
+ all beginning with "textureFootprint", that allow shaders to query a
+ _texture footprint_. The texture footprint is a set of texels belonging
+ to a single texture level that would be accessed when performing a
+ filtered texture lookup. The shader code calling the footprint query
+ functions passes in a _granularity_ value, which is used to subdivide a
+ texture level into an array of fixed-size _texel groups_ whose size is
+ given by the granularity. The texture footprint query functions return
+ the footprint using a built-in GLSL data structure that identifies the set
+ of texel groups containing one or more texels that would be accessed in an
+ equivalent texture lookup. Texture footprint queries are only supported
+ for two- and three-dimensional textures (targets TEXTURE_2D and
+ TEXTURE_3D). Additionally, footprint queries require the use of the
+ CLAMP_TO_EDGE sampler wrap mode in all relevant dimensions; the results of
+ the footprint query are undefined if any other wrap mode is used.
+
+ Each texture footprint query built-in function accepts a set of texture
+ coordinates and any additional parameters (e.g., explicit level of detail,
+ level of detail bias, or derivatives) needed to specify a normal texture
+ lookup operation whose footprint should be evaluated. The footprint query
+ functions also accept a <granularity> parameter and a <coarse> flag used
+ to select the level of detail whose footprint is returned. The
+ granularity parameter identifies the size of the texel groups used for the
+ footprint query as described in Table X.1. The <coarse> flag is used to
+ select between the two levels of detail used when minifying using a filter
+ (NEAREST_MIPMAP_LINEAR, LINEAR_MIPMAP_LINEAR) that averages texels from
+ multiple levels of detail. When such minification is performed, a value
+ of "false" requests the footprint in the higher-resolution (fine) level of
+ detail, while "true" requests the footprint in the lower-resolution
+ (coarse) level of detail. When a texture access uses only a single level
+ of detail, its footprint will be returned for queries with <coarse> set to
+ false, while queries with <coarse> set to true will return an empty
+ footprint. Since many texture accesses may use only a single level, the
+ footprint query functions return a boolean value, which will be true if
+ and only if all accessed texels are in a single level of detail.
+
+ Granularity Value | TEXTURE_2D | TEXTURE_3D
+ ------------------+---------------+----------------
+ 0 | unsupported | unsupported
+ 1 | 2x2 | 2x2x2
+ 2 | 4x2 | unsupported
+ 3 | 4x4 | 4x4x2
+ 4 | 8x4 | unsupported
+ 5 | 8x8 | unsupported
+ 6 | 16x8 | unsupported
+ 7 | 16x16 | unsupported
+ 8 | unsupported | unsupported
+ 9 | unsupported | unsupported
+ 10 | unsupported | 16x16x16
+ 11 | 64x64 | 32x16x16
+ 12 | 128x64 | 32x32x16
+ 13 | 128x128 | 32x32x32
+ 14 | 256x128 | 64x32x32
+ 15 | 256x256 | unsupported
+
+ Table X.1: Supported granularities for texture footprint queries, for
+ two-dimensional (TEXTURE_2D) and three-dimensional (TEXTURE_3D)
+ accesses. Granularity values not listed in the table or listed as
+ "unsupported" are not supported by this extension and result in
+ undefined behavior if used.
+
+ In addition to the boolean result, texture footprint queries return
+ footprint data in a structure of the type gl_TextureFootprint2DNV (for
+ two-dimensional textures) or gl_TextureFootprint3DNV (for
+ three-dimensional textures). In either structure, the member <lod>
+ specifies the level-of-detail number used for the footprint. The
+ members <anchor> and <offset> identify a small neighborhood of texel
+ groups in the texture used by the query. The member <mask> specifies 64
+ bits of data indicating which texel groups in the neighborhood are part
+ of the footprint. The member <granularity> returns information on the
+ size of the texel groups in the footprint, which is sometimes larger
+ than the requested granularity, as described below.
+
+ For two-dimensional footprint queries, the neighborhood returned by the
+ query is an 8x8 array of texel groups, where each texel group in
+ neighborhood is identified by a coordinate (x,y), where <x> and <y> are
+ integer values in the range [0,7]. Each texel group corresponds to a
+ set of texels whose (u,v) coordinates satisfy the inequalities:
+
+ u1 <= u <= u2
+ v1 <= v <= v2
+
+ computed using the following logic:
+
+ // The footprint logic returns a mask whose bits are aligned to 8x8
+ // sets of texel groups. This allows shaders to use atomics to
+ // efficiently accumulate footprint results across many invocations,
+ // storing an 8x8 array of bits for each group into one RG32UI texel.
+ // The texel group number in the neighborhood is treated as an offset
+ // relative to the anchor point.
+ uvec2 texel_group = 8 * result.anchor + uvec2(x,y);
+
+ // If the neighborhood crosses the boundaries of an 8x8 set, the bits
+ // of the mask are effectively split across multiple sets (up to
+ // four for 2D). The "offset" parameter returned by the query
+ // identifies which x/y group values in the neighborhood are
+ // assigned to which set. An all-zero offset indicates that the
+ // footprint is fully contained in a single 8x8 set at the anchor.
+ // "Low" x/y values identify texel groups at the beginning of the 8x8
+ // set identified by the anchor, while "high" values correspond to
+ // texel groups at the end of the previous set. The offset
+ // indicates the number of texel groups assigned to the previous set.
+ if (x + result.offset.x >= 8) {
+ texel_group.x -= 8;
+ }
+ if (y + result.offset.y >= 8) {
+ texel_group.y -= 8;
+ }
+
+ // Once we have a group number, u/v texel number ranges are generated by
+ // multiplying by the texel group size.
+ uint u1 = texel_group.x * granularity_x;
+ uint u2 = u1 + granularity_x - 1;
+ uint v1 = texel_group.y * granularity_y;
+ uint v2 = v1 + granularity_y - 1;
+
+ In the equations above, <granularity_x> and <granularity_y> refer to the
+ texel group size as in Table X.1. result.anchor and result.offset
+ specify the <anchor> and <offset> members of the returned structure, and
+ <x> and <y> specify the texel group number in the neighborhood.
+
+ Each bit in the <mask> member of the returned structure corresponds to
+ one of the texel groups in the 8x8 neighborhood. That bit will be set
+ if and only if any of the texels in the texel group is covered by the
+ footprint. The texel group (x,y) is considered to be covered if and
+ only if the following logic computes true for <covered>:
+
+ uint64_t mask = result.mask.x | (result.mask.y << 32);
+ uint32_t bit = y * 8 + x;
+ bool covered = (0 != ((mask >> bit) & 1));
+
+ For three-dimensional footprint queries, the logic is very similar,
+ except that the neighborhood returned by the query is a 4x4x4 array of
+ texel groups. Each texel group in neighborhood is identified by a
+ coordinate (x,y,z), where <x>, <y>, and <z> are integer values in the
+ range [0,3]. Each texel group corresponds to a set of texels whose
+ (u,v,w) coordinates satisfy the inequalities:
+
+ u1 <= u <= u2
+ v1 <= v <= v2
+ w1 <= w <= w2
+
+ computed using the following logic:
+
+ uvec3 texel_group = 4 * result.anchor + uvec3(x,y,z);
+ if (x + result.offset.x >= 4) {
+ texel_group.x -= 4;
+ }
+ if (y + result.offset.y >= 4) {
+ texel_group.y -= 4;
+ }
+ if (z + result.offset.z >= 4) {
+ texel_group.z -= 4;
+ }
+ uint u1 = texel_group.x * granularity_x;
+ uint u2 = u1 + granularity_x - 1;
+ uint v1 = texel_group.y * granularity_y;
+ uint v2 = v1 + granularity_y - 1;
+ uint w1 = texel_group.z * granularity_z;
+ uint w2 = w1 + granularity_z - 1;
+
+ As in the two-dimensional logic, <granularity_x>, <granularity_y>, and
+ <granularity_z> refer to the texel group size as in Table X.1.
+ result.anchor and result.offset specify the <anchor> and <offset>
+ members of the returned structure, and <x>, <y>, and <z> specify the
+ texel group number in the neighborhood.
+
+ Each bit in the <mask> member of the returned structure corresponds to
+ one of the texel groups in the 4x4x4 neighborhood. That bit will be set
+ if and only if any of the texels in the texel group is covered by the
+ footprint. The texel group (x,y,z) is considered to be covered if and
+ only if the following logic computes true for <covered>:
+
+ uint64_t mask = result.mask.x | (result.mask.y << 32);
+ uint32_t bit = z * 16 + y * 4 + x;
+ bool covered = (0 != ((mask >> bit) & 1));
+
+ In most cases, the texel group sizes used by the footprint query will
+ match the value passed to the query, as interpreted according to Table
+ X.1. However, in some cases, the footprint may be too large to be
+ expressed as a collection of 8x8 or 4x4x4 set of texel groups using the
+ requested granularity. In this case, the implementation uses a texel
+ group size that is larger than the requested granularity. If a larger
+ texel group size is used, the implementation will return the texel group
+ size used in the <granularity> member of the footprint structure, which
+ should also be interpreted according to Table X.1. If the requested
+ texel group size is used, the implementation will return zero in
+ <granularity>. The texel group size will only be increased by the
+ implementation if anisotropic filtering is used. If the texture and
+ sampler objects used by the footprint query do not enable anisotropic
+ texture filtering, the footprint query will always use the original
+ requested granularity and return zero in the <granularity> member.
+
+Errors
+
+ None
+
+New State
+
+ None
+
+New Implementation Dependent State
+
+ None
+
+Issues
+
+ None, but please refer to issues in the GLSL extension specification.
+
+Revision History
+
+ Revision 1 (clentini, pbrown)
+ - Internal revisions.
diff --git a/extensions/NV/NV_shading_rate_image.txt b/extensions/NV/NV_shading_rate_image.txt
new file mode 100644
index 0000000..43a28f1
--- /dev/null
+++ b/extensions/NV/NV_shading_rate_image.txt
@@ -0,0 +1,1007 @@
+Name
+
+ NV_shading_rate_image
+
+Name Strings
+
+ GL_NV_shading_rate_image
+
+Contact
+
+ Pat Brown, NVIDIA Corporation (pbrown 'at' nvidia.com)
+
+Contributors
+
+ Daniel Koch, NVIDIA
+ Mark Kilgard, NVIDIA
+ Jeff Bolz, NVIDIA
+ Mathias Schott, NVIDIA
+
+Status
+
+ Shipping
+
+Version
+
+ Last Modified: September 15, 2018
+ Revision: 1
+
+Number
+
+ OpenGL Extension #531
+
+Dependencies
+
+ This extension is written against the OpenGL 4.5 Specification
+ (Compatibility Profile), dated October 24, 2016.
+
+ OpenGL 4.5 is required.
+
+ This extension requires support for the OpenGL Shading Language (GLSL)
+ extension "NV_fragment_shader_barycentric", which can be found at the
+ Khronos Group Github site here:
+
+ https://github.com/KhronosGroup/GLSL
+
+ This extension interacts trivially with ARB_sample_locations and
+ NV_sample_locations.
+
+ This extension interacts with NV_scissor_exclusive.
+
+ This extension interacts with NV_conservative_raster.
+
+ This extension interacts with NV_conservative_raster_underestimation.
+
+ This extension interacts with EXT_raster_multisample.
+
+ NV_framebuffer_mixed_samples is required.
+
+Overview
+
+ By default, OpenGL runs a fragment shader once for each pixel covered by a
+ primitive being rasterized. When using multisampling, the outputs of that
+ fragment shader are broadcast to each covered sample of the fragment's
+ pixel. When using multisampling, applications can also request that the
+ fragment shader be run once per color sample (when using the "sample"
+ qualifier on one or more active fragment shader inputs), or run a fixed
+ number of times per pixel using SAMPLE_SHADING enable and the
+ MinSampleShading frequency value. In all of these approaches, the number
+ of fragment shader invocations per pixel is fixed, based on API state.
+
+ This extension allows applications to bind and enable a shading rate image
+ that can be used to vary the number of fragment shader invocations across
+ the framebuffer. This can be useful for applications like eye tracking
+ for virtual reality, where the portion of the framebuffer that the user is
+ looking at directly can be processed at high frequency, while distant
+ corners of the image can be processed at lower frequency. The shading
+ rate image is an immutable-format two-dimensional or two-dimensional array
+ texture that uses a format of R8UI. Each texel represents a fixed-size
+ rectangle in the framebuffer, covering 16x16 pixels in the initial
+ implementation of this extension. When rasterizing a primitive covering
+ one of these rectangles, the OpenGL implementation reads the texel in the
+ bound shading rate image and looks up the fetched value in a palette of
+ shading rates. The shading rate used can vary from (finest) 16 fragment
+ shader invocations per pixel to (coarsest) one fragment shader invocation
+ for each 4x4 block of pixels.
+
+ When this extension is advertised by an OpenGL implementation, the
+ implementation must also support the GLSL extension
+ "GL_NV_shading_rate_image" (documented separately), which provides new
+ built-in variables that allow fragment shaders to determine the effective
+ shading rate used for each fragment. Additionally, the GLSL extension also
+ provides new layout qualifiers allowing the interlock functionality provided
+ by ARB_fragment_shader_interlock to guarantee mutual exclusion across an
+ entire fragment when the shading rate specifies multiple pixels per fragment
+ shader invocation.
+
+ Note that this extension requires the use of a framebuffer object; the
+ shading rate image and related state are ignored when rendering to the
+ default framebuffer.
+
+New Procedures and Functions
+
+ void BindShadingRateImageNV(uint texture);
+ void ShadingRateImagePaletteNV(uint viewport, uint first, sizei count,
+ const enum *rates);
+ void GetShadingRateImagePaletteNV(uint viewport, uint entry,
+ enum *rate);
+ void ShadingRateImageBarrierNV(boolean synchronize);
+ void ShadingRateImageBarrierNV(enum order);
+ void ShadingRateSampleOrderCustomNV(enum rate, uint samples,
+ const int *locations);
+ void GetShadingRateSampleLocationivNV(enum rate, uint samples,
+ uint index, int *location);
+
+New Tokens
+
+ Accepted by the <cap> parameter of Enable, Disable, and IsEnabled, by the
+ <target> parameter of Enablei, Disablei, IsEnabledi, EnableIndexedEXT,
+ DisableIndexedEXT, and IsEnabledIndexedEXT, and by the <pname> parameter
+ of GetBooleanv, GetIntegerv, GetInteger64v, GetFloatv, GetDoublev,
+ GetDoubleIndexedv, GetBooleani_v, GetIntegeri_v, GetInteger64i_v,
+ GetFloati_v, GetDoublei_v, GetBooleanIndexedvEXT, GetIntegerIndexedvEXT,
+ and GetFloatIndexedvEXT:
+
+ SHADING_RATE_IMAGE_NV 0x9563
+
+ Accepted in the <rates> parameter of ShadingRateImagePaletteNV and the
+ <rate> parameter of ShadingRateSampleOrderCustomNV and
+ GetShadingRateSampleLocationivNV; returned in the <rate> parameter of
+ GetShadingRateImagePaletteNV:
+
+ SHADING_RATE_NO_INVOCATIONS_NV 0x9564
+ SHADING_RATE_1_INVOCATION_PER_PIXEL_NV 0x9565
+ SHADING_RATE_1_INVOCATION_PER_1X2_PIXELS_NV 0x9566
+ SHADING_RATE_1_INVOCATION_PER_2X1_PIXELS_NV 0x9567
+ SHADING_RATE_1_INVOCATION_PER_2X2_PIXELS_NV 0x9568
+ SHADING_RATE_1_INVOCATION_PER_2X4_PIXELS_NV 0x9569
+ SHADING_RATE_1_INVOCATION_PER_4X2_PIXELS_NV 0x956A
+ SHADING_RATE_1_INVOCATION_PER_4X4_PIXELS_NV 0x956B
+ SHADING_RATE_2_INVOCATIONS_PER_PIXEL_NV 0x956C
+ SHADING_RATE_4_INVOCATIONS_PER_PIXEL_NV 0x956D
+ SHADING_RATE_8_INVOCATIONS_PER_PIXEL_NV 0x956E
+ SHADING_RATE_16_INVOCATIONS_PER_PIXEL_NV 0x956F
+
+ Accepted by the <pname> parameter of GetBooleanv, GetDoublev,
+ GetIntegerv, and GetFloatv:
+
+ SHADING_RATE_IMAGE_BINDING_NV 0x955B
+ SHADING_RATE_IMAGE_TEXEL_WIDTH_NV 0x955C
+ SHADING_RATE_IMAGE_TEXEL_HEIGHT_NV 0x955D
+ SHADING_RATE_IMAGE_PALETTE_SIZE_NV 0x955E
+ MAX_COARSE_FRAGMENT_SAMPLES_NV 0x955F
+
+ Accepted by the <order> parameter of ShadingRateSampleOrderNV:
+
+ SHADING_RATE_SAMPLE_ORDER_DEFAULT_NV 0x95AE
+ SHADING_RATE_SAMPLE_ORDER_PIXEL_MAJOR_NV 0x95AF
+ SHADING_RATE_SAMPLE_ORDER_SAMPLE_MAJOR_NV 0x95B0
+
+
+Modifications to the OpenGL 4.5 Specification (Compatibility Profile)
+
+ Modify Section 14.3.1, Multisampling, p. 532
+
+ (add to the end of the section)
+
+ When using a shading rate image (Section 14.4.1), rasterization may
+ produce fragments covering multiple pixels, where each pixel is treated as
+ a sample. If SHADING_RATE_IMAGE_NV is enabled for any viewport,
+ primitives will be processed with multisample rasterization rules,
+ regardless of the MULTISAMPLE enable or the value of SAMPLE_BUFFERS. If
+ the framebuffer has no multisample buffers, each pixel is treated as
+ having a single sample located at the pixel center.
+
+
+ Delete Section 14.3.1.1, Sample Shading, p. 532. The functionality in
+ this section is moved to the new Section 14.4, "Shading Rate Control".
+
+
+ Add new section before Section 14.4, Points, p. 533
+
+ Section 14.4, Shading Rate Control
+
+ By default, each fragment processed by programmable fragment processing
+ (chapter 15) [[compatibility only: or fixed-function fragment processing
+ (chapter 16)]] corresponds to a single pixel with a single (x,y)
+ coordinate. When using multisampling, implementations are permitted to run
+ separate fragment shader invocations for each sample, but often only run a
+ single invocation for all samples of the fragment. We will refer to the
+ density of fragment shader invocations in a particular framebuffer region
+ as the _shading rate_. Applications can use the shading rate to increase
+ the size of fragments to cover multiple pixels and reduce the amount of
+ fragment shader work. Applications can also use the shading rate to
+ explicitly control the minimum number of fragment shader invocations when
+ multisampling.
+
+
+ Section 14.4.1, Shading Rate Image
+
+ Applications can specify the use of a shading rate that varies by (x,y)
+ location using a _shading rate image_. Use of a shading rate image is
+ enabled or disabled for all viewports using Enable or Disable with target
+ SHADING_RATE_IMAGE_NV. Use of a shading rate image is enabled or disabled
+ for a specific viewport using Enablei or Disablei with the constant
+ SHADING_RATE_IMAGE_NV and the index of the selected viewport. The shading
+ rate image may only be used with a framebuffer object. When rendering to
+ the default framebuffer, the shading rate image operations in this section
+ are disabled.
+
+ The shading rate image is a texture that can be bound with the command
+
+ void BindShadingRateImageNV(uint texture);
+
+ This command unbinds the current shading rate image, if any. If <texture>
+ is zero, no new texture is bound. If <texture> is non-zero, it must be
+ the name of an existing immutable-format texture with a target of
+ TEXTURE_2D or TEXTURE_2D_ARRAY with a format of R8UI. If <texture> has
+ multiple mipmap levels, only the base level will be used as the shading
+ rate image.
+
+ Errors
+
+ INVALID_VALUE is generated if <texture> is not zero and is not the
+ name of an existing texture object.
+
+ INVALID_OPERATION is generated if <texture> is not an immutable-format
+ texture, has a format other than R8UI, or has a texture target other
+ than TEXTURE_2D or TEXTURE_2D_ARRAY.
+
+ When rasterizing a primitive covering pixel (x,y) with a shading rate
+ image having a target of TEXTURE_2D, a two-dimensional texel coordinate
+ (u,v) is generated, where:
+
+ u = floor(x / SHADING_RATE_IMAGE_TEXEL_WIDTH_NV)
+ v = floor(y / SHADING_RATE_IMAGE_TEXEL_HEIGHT_NV)
+
+ and where SHADING_RATE_IMAGE_TEXEL_WIDTH_NV and
+ SHADING_RATE_IMAGE_TEXEL_HEIGHT_NV are the width and height of the
+ implementation-dependent footprint of each shading rate image texel in the
+ framebuffer. If the bound shading rate image has a target of
+ TEXTURE_2D_ARRAY, a three-dimensional texture coordinate (u,v,w) is
+ generated, where u and v are computed as above. The coordinate w is set
+ to the layer L of the framebuffer being rendered to if L is less than the
+ number of layers in the shading rate image, or zero otherwise.
+
+ If a texel with coordinates (u,v) or (u,v,w) exists in the bound shading
+ rate image, the value of the 8-bit R component of the texel is used as the
+ shading rate index. If the (u,v) or (u,v,w) coordinate is outside the
+ extent of the shading rate image, or if no shading rate image is bound,
+ zero will be used as the shading rate index.
+
+ A shading rate index is mapped to a _base shading rate_ using a lookup
+ table called the shading rate image palette. There is a separate palette
+ for each viewport. The number of entries in each palette is given by the
+ implementation-dependent constant SHADING_RATE_IMAGE_PALETTE_SIZE_NV. The
+ base shading rate for an (x,y) coordinate with a shading rate index of <i>
+ will be given by palette entry <i>. If the shading rate index is greater
+ than or equal to the palette size, the results of the palette lookup are
+ undefined.
+
+ Shading rate image palettes are updated using the command
+
+ void ShadingRateImagePaletteNV(uint viewport, uint first, sizei count,
+ const enum *rates);
+
+ <viewport> specifies the number of the viewport whose palette should be
+ updated. <rates> is an array of <count> shading rate enums and is used to
+ update entries <first> through <first> + <count> - 1 in the palette. The
+ set of shading rate values accepted in <rates> is given in Table X.1. The
+ default value for all palette entries is
+ SHADING_RATE_1_INVOCATION_PER_PIXEL_NV.
+
+ Shading Rate Size Invocations
+ ------------------------------------------- ----- -----------
+ SHADING_RATE_NO_INVOCATIONS_NV - 0
+ SHADING_RATE_1_INVOCATION_PER_PIXEL_NV 1x1 1
+ SHADING_RATE_1_INVOCATION_PER_1X2_PIXELS_NV 1x2 1
+ SHADING_RATE_1_INVOCATION_PER_2X1_PIXELS_NV 2x1 1
+ SHADING_RATE_1_INVOCATION_PER_2X2_PIXELS_NV 2x2 1
+ SHADING_RATE_1_INVOCATION_PER_2X4_PIXELS_NV 2x4 1
+ SHADING_RATE_1_INVOCATION_PER_4X2_PIXELS_NV 4x2 1
+ SHADING_RATE_1_INVOCATION_PER_4X4_PIXELS_NV 4x4 1
+ SHADING_RATE_2_INVOCATIONS_PER_PIXEL_NV 1x1 2
+ SHADING_RATE_4_INVOCATIONS_PER_PIXEL_NV 1x1 4
+ SHADING_RATE_8_INVOCATIONS_PER_PIXEL_NV 1x1 8
+ SHADING_RATE_16_INVOCATIONS_PER_PIXEL_NV 1x1 16
+
+ Table X.1: Shading rates accepted by ShadingRateImagePaletteNV. An
+ entry of "<W>x<H>" in the "Size" column indicates that the shading
+ rate results in fragments with a width and height (in pixels) of <W>
+ and <H>, respectively. The entry in the "Invocations" column
+ specifies the number of fragment shader invocations that should be
+ generated for each fragment.
+
+ Errors
+
+ INVALID_VALUE is generated if <viewport> is greater than or equal to
+ MAX_VIEWPORTS or if <first> plus <count> is greater than
+ SHADING_RATE_IMAGE_PALETTE_SIZE_NV.
+
+ INVALID_ENUM is generated if any entry in <rates> is not a valid
+ shading rate.
+
+ Individual entries in the shading rate palette can be queried using the
+ command:
+
+ void GetShadingRateImagePaletteNV(uint viewport, uint entry,
+ enum *rate);
+
+ where <viewport> specifies the viewport of the palette to query and
+ <entry> specifies the palette entry number. A single enum from Table X.1
+ is returned in <rate>.
+
+ Errors
+
+ INVALID_VALUE is generated if <viewport> is greater than or equal to
+ MAX_VIEWPORTS or if <entry> is greater than or equal to
+ SHADING_RATE_IMAGE_PALETTE_SIZE_NV.
+
+ If the shading rate image is enabled, a base shading rate will be obtained
+ as described above. If the shading rate image is disabled, the base
+ shading rate will be SHADING_RATE_1_INVOCATION_PER_PIXEL_NV. In either
+ case, the shading rate will be adjusted as described in the following
+ sections.
+
+ The rasterization hardware that reads from the shading rate image may
+ cache texels it reads for maximum performance. If the shading rate image
+ is updated using commands such as TexSubImage2D, image stores in shaders,
+ or by framebuffer writes performed when the shading rate image is bound to
+ a framebuffer object, this cache may retain out-of-date texture data.
+ Calling
+
+ void ShadingRateImageBarrierNV(boolean synchronize);
+
+ with <synchronize> set to TRUE ensures that rendering commands submitted
+ after the barrier don't access old shading rate image data updated
+ directly (TexSubImage2D) or indirectly (rendering, image stores) by
+ commands submitted before the barrier. If <synchronize> is set to FALSE,
+ ShadingRateImageBarrierNV doesn't wait on the completion of commands
+ submitted before the barrier. If an application has ensured that all
+ prior commands updating the shading rate image have completed using sync
+ objects or other mechanism, <synchronize> can be safely set to FALSE.
+ Otherwise, the lack of synchronization may cause subsequent rendering
+ commands to source the shading rate image before prior updates have
+ completed.
+
+
+ Section 14.4.2, Sample Shading
+
+ When the shading rate image is disabled, sample shading can be used to
+ specify a minimum number of fragment shader invocations to generate for
+ each fragment. When the shading rate image is enabled, sample shading can
+ be used to adjust the shading rate to increase the number of fragment
+ shader invocations generated for each primitive. Sample shading is
+ controlled by calling Enable or Disable with target SAMPLE_SHADING. If
+ MULTISAMPLE or SAMPLE_SHADING is disabled, sample shading has no effect.
+
+ When sample shading is active, an integer sample shading factor is derived
+ based on the value provided in the command:
+
+ void MinSampleShading(float value);
+
+ When the shading rate image is disabled, a <value> of 0.0 specifies that
+ the minimum number of fragment shader invocations for the shading rate be
+ executed and a <value> of 1.0 specifies that a fragment shader should be
+ on each shadeable sample with separate values per sample. When the
+ shading rate image is enabled, <value> is used to derive a sample shading
+ rate that can adjust the shading rate. <value> is not clamped to [0.0,
+ 1.0]; values larger than 1.0 can be used to force larger adjustments to
+ the shading rate.
+
+ The sample shading factor is computed from <value> in an
+ implementation-dependent manner but must be greater than or equal to:
+
+ factor = max(ceil(value * max_shaded_samples), 1)
+
+ In this computation, <max_shaded_samples> is the maximum number of
+ fragment shader invocations per fragment, and is equal to:
+
+ - the number of color samples, if the framebuffer has color attachments;
+
+ - the number of depth/stencil samples, if the framebuffer has
+ depth/stencil attachments but no color attachments; or
+
+ - the value of FRAMEBUFFER_DEFAULT_SAMPLES if the framebuffer has no
+ attachments.
+
+ If the framebuffer has non-multisample attachments, the maximum number of
+ shaded samples per pixel is always one.
+
+
+ Section 14.4.3, Shading Rate Adjustment
+
+ Once a base shading rate has been established, it is adjusted to produce a
+ final shading rate.
+
+ First, if the base shading rate specifies multiple pixels for a fragment,
+ the shading rate is adjusted in an implementation-dependent manner to
+ limit the total number of coverage samples for the "coarse" fragment.
+ After adjustment, the maximum number of samples will not exceed the
+ implementation-dependent maximum MAX_COARSE_FRAGMENT_SAMPLES_NV. However,
+ implementations are permitted to clamp to a lower number of coverage
+ samples if required. Table X.2 describes the clamping performed in the
+ initial implementation of this extension.
+
+ Coverage Samples per Pixel
+ Base rate 2 4 8 16
+ --------- ----- ----- ----- -----
+ 1x2 - - - 1x1
+ 2x1 - - 1x1 1x1
+ 2x2 - - 1x2 1x1
+ 2x4 - 2x2 1x2 1x1
+ 4x2 2x2 2x2 1x2 1x1
+ 4x4 2x4 2x2 1x2 1x1
+
+ Table X.2, Coarse shading rate adjustment for total coverage sample
+ count for the initial implementation of this extension, where
+ MAX_COARSE_FRAGMENT_SAMPLES_NV is 16. The entries in the "2", "4", "8",
+ and "16" columns indicate the fragment size for the adjusted shading
+ rate.
+
+ If sample shading is enabled and the sample shading factor is greater than
+ one, the base shading rate is further adjusted to result in more shader
+ invocations per pixel. Table X.3 describes how the shading rate is
+ adjusted in the initial implementation of this extension.
+
+ Sample Shading Factor
+ Base rate 2 4 8 16
+ ---------- --------- ------- -------- --------
+ 1x1 / 1 1x1 / 2 1x1 / 4 1x1 / 8 1x1 / 16
+ 1x2 / 1 1x1 / 1 1x1 / 2 1x1 / 4 1x1 / 8
+ 2x1 / 1 1x1 / 1 1x1 / 2 1x1 / 4 1x1 / 8
+ 2x2 / 1 1x2 / 1 1x1 / 1 1x1 / 2 1x1 / 4
+ 2x4 / 1 2x2 / 1 1x2 / 1 1x1 / 1 1x1 / 2
+ 4x2 / 1 2x2 / 1 2x1 / 1 1x1 / 1 1x1 / 2
+ 4x4 / 1 2x4 / 1 2x2 / 1 1x2 / 1 1x1 / 1
+ 1x1 / 2 1x1 / 4 1x1 / 8 1x1 / 16 1x1 / 16
+ 1x1 / 4 1x1 / 8 1x1 / 16 1x1 / 16 1x1 / 16
+ 1x1 / 8 1x1 / 16 1x1 / 16 1x1 / 16 1x1 / 16
+ 1x1 / 16 1x1 / 16 1x1 / 16 1x1 / 16 1x1 / 16
+
+ Table X.3, Shading rate adjustment based on the sample shading factor in
+ the initial implementation of this extension. All rates in this table
+ are of the form "<W>x<H> / <I>", indicating a fragment size of <W>x<H>
+ pixels with <I> invocations per fragment.
+
+ If RASTER_MULTISAMPLE_EXT is enabled and the shading rate indicates
+ multiple fragment shader invocations per pixel, implementations are
+ permitted to adjust the shading rate to reduce the number of invocations
+ per pixel. In this case, implementations are not required to support more
+ than one invocations per pixel.
+
+ If the active fragment shader uses any inputs that are qualified with
+ "sample" (unique values per sample), including the built-ins "gl_SampleID"
+ and "gl_SamplePosition", the shader code is written to expect a separate
+ shader invocation for each shaded sample. For such fragment shaders, the
+ shading rate is set to the maximum number of shader invocations per pixel
+ (SHADING_RATE_16_INVOCATIONS_PER_PIXEL_NV). This adjustment effectively
+ disables the shading rate image.
+
+ Finally, if the shading rate indicates multiple fragment shader
+ invocations per sample, the total number of invocations per fragment in
+ the shading rate is clamped to the maximum number of shaded samples per
+ pixel described in section 14.4.2.
+
+
+ Section 14.4.4, Shading Rate Application
+
+ If the palette indicates a shading rate of SHADING_RATE_NO_INVOCATIONS_NV,
+ for pixel (x,y), no fragments will be generated for that pixel.
+
+ When the final shading rate for pixel (x,y) is results in fragments with a
+ width and height of <W> and <H>, where either <W> or <H> is greater than
+ one, a single fragment will be produced for that pixel that also includes
+ all other pixels covered by the same primitive whose coordinates (x',y')
+ satisfy:
+
+ floor(x / W) == floor(x' / W), and
+ floor(y / H) == floor(y' / H).
+
+ This combined fragment is considered to have multiple coverage samples;
+ the total number of samples in this fragment is given by
+
+ samples = A * B * S
+
+ where <A> and <B> are the width and height of the combined fragment, in
+ pixels, and <S> is the number of coverage samples per pixel in the draw
+ framebuffer. The set of coverage samples in the fragment is the union of
+ the per-pixel coverage samples in each of the fragment's pixels. The
+ location and order of coverage samples within each pixel in the combined
+ fragment are the same as the location and order used for single-pixel
+ fragments. Each coverage sample in the set of pixels belonging to the
+ combined fragment is assigned a unique sample number in the range
+ [0,<S>-1]. When rendering to a framebuffer object, the order of coverage
+ samples can be specified for each combination of fragment size and
+ coverage sample count. When using the default framebuffer, the coverage
+ samples are ordered in an implementation-dependent manner. The command
+
+ void ShadingRateSampleOrderNV(enum order);
+
+ sets the coverage sample order for all valid combinations of shading rate
+ and per-pixel sample coverage count. If <order> is
+ COARSE_SAMPLE_ORDER_DEFAULT_NV, coverage samples are ordered in an
+ implementation-dependent default order. If <order> is
+ COARSE_SAMPLE_ORDER_PIXEL_MAJOR_NV, coverage samples in the combined
+ fragment will be ordered sequentially, sorted first by pixel coordinate
+ (in row-major order) and then by per-pixel coverage sample number. If
+ <order> is COARSE_SAMPLE_ORDER_SAMPLE_MAJOR_NV, coverage samples in the
+ combined fragment will be ordered sequentially, sorted first by per-pixel
+ coverage sample number and then by pixel coordinate (in row-major order).
+
+ When processing a fragment using an ordering specified by
+ COARSE_SAMPLE_ORDER_PIXEL_MAJOR_NV sample <cs> in the combined fragment
+ will be assigned to coverage sample <ps> of pixel (px,py) specified by:
+
+ px = fx + (floor(cs / fsc) % fw)
+ py = fy + floor(cs / (fsc * fw))
+ ps = cs % fsc
+
+ where the lower-leftmost pixel in the fragment has coordinates (fx,fy),
+ the fragment width and height are <fw> and <fh>, respectively, and there
+ are <fsc> coverage samples per pixel. When processing a fragment with an
+ ordering specified by COARSE_SAMPLE_ORDER_SAMPLE_MAJOR_NV, sample <cs> in
+ the combined fragment will be assigned using:
+
+ px = fx + (cs % fw)
+ py = fy + (floor(cs / fw) % fh)
+ ps = floor(cs / (fw * fh))
+
+ Additionally, the command
+
+ void ShadingRateSampleOrderCustomNV(enum rate, uint samples,
+ const int *locations);
+
+ specifies the order of coverage samples for fragments using a shading rate
+ of <rate> with <samples> coverage samples per pixel. <rate> must be one
+ of the shading rates specified in Table X.1 and must specify a shading
+ rate with more than one pixel per fragment. <locations> specifies an
+ array of N (x,y,s) tuples, where N is the product the fragment width
+ indicated by <rate>, the fragment height indicated by <rate>, and
+ <samples>. For each (x,y,s) tuple specified in <locations>, <x> must be
+ in the range [0,fw-1], y must be in the range [0,fh-1], and s must be in
+ the range [0,fsc-1]. No two tuples in <locations> may have the same
+ values.
+
+ When using a sample order specified by ShadingRateSampleOrderCustomNV,
+ sample <cs> in the combined fragment will be assigned using:
+
+ px = fx + locations[3 * cs + 0]
+ py = fy + locations[3 * cs + 1]
+ ps = locations[3 * cs + 2]
+
+ where all terms in these equations are defined as in the equations
+ specified for ShadingRateSampleOrderNV and are consistent with a shading
+ rate of <rate> and a per-pixel sample count of <samples>.
+
+ Errors
+
+ * INVALID_ENUM is generated if <rate> is not one of the enums in Table
+ X.1.
+
+ * INVALID_OPERATION is generated if <rate> does not specify a
+ shading rate palette entry that specifies fragments with more than
+ one pixel.
+
+ * INVALID_VALUE is generated if <sampleCount> is not 1, 2, 4, or 8.
+
+ * INVALID_OPERATION is generated if the product of the fragment width
+ indicated by <rate>, the fragment height indicated by <rate>, and
+ samples is greater than MAX_COARSE_FRAGMENT_SAMPLES_NV.
+
+ * INVALID_VALUE is generated if any (x,y,s) tuple in <locations> has
+ negative values of <x>, <y>, or <s>, has an <x> value greater than or
+ equal to the width of fragments using <rate>, has a <y> value greater
+ than or equal to the height of fragments using <rate>, or has an <s>
+ value greater than or equal to <sampleCount>.
+
+ * INVALID_OPERATION is generated if any pair of (x,y,s) tuples in
+ <locations> have identical values.
+
+ In the initial state, the order of coverage samples in combined fragments
+ is implementation-dependent, but will be identical to the order obtained
+ by passing COARSE_SAMPLE_ORDER_DEFAULT_NV to ShadingRateSampleOrderNV.
+
+ The command
+
+ void GetShadingRateSampleLocationivNV(enum rate, uint samples,
+ uint index, int *location);
+
+ can be used to determine the specific pixel and sample number for each
+ numbered sample in a single- or multi-pixel fragment when the final
+ shading rate is <rate> and uses <samples> coverage samples per pixel.
+ <index> specifies a sample number in the fragment. Three integers are
+ returned in <location>, and are interpreted in the same manner as each
+ (x,y,s) tuples passed to ShadingRateSampleOrderCustomNV. The command
+ GetMultisamplefv can be used to determine the location of the identified
+ sample <s> within a combined fragment pixel identified by (x,y).
+
+ Errors
+
+ INVALID_OPERATION is returned if <rate> is
+ SHADING_RATE_NO_INVOCATIONS_NV.
+
+ INVALID_VALUE is returned if <index> is greater than or equal to the
+ number of coverage samples in the draw framebuffer in a combined pixel
+ for a shading rate given by <rate>.
+
+ When the final shading rate for pixel (x,y) specifies single-pixel
+ fragments, a single fragment with S samples numbered in the range
+ [0,<S>-1] will be generated when (x,y) is covered.
+
+ If the final shading rate for the fragment containing pixel (x,y) produces
+ fragments covering multiple pixels, a single fragment shader invocation
+ will be generated for the combined fragment. When using fragments with
+ multiple pixels per fragment, fragment shader outputs (e.g., color values
+ and gl_FragDepth) will be broadcast to all covered pixels/samples of the
+ fragment. If a "discard" is used in a fragment shader, none of the
+ pixels/samples of the fragment will be updated.
+
+ If the final shading rate for pixel (x,y) indicates <N> fragment shader
+ invocations per fragment, <N> separate fragment shader invocations will be
+ generated for the single-pixel fragment. Each coverage sample in the
+ fragment is assigned to one of the <N> fragment shader invocations in an
+ implementation-dependent manner.
+
+ If sample shading is enabled and the final shading rate results in
+ multiple fragment shader invocations per pixel, each fragment shader
+ invocation for a pixel will have a separate set of interpolated input
+ values. If sample shading is disabled, interpolated fragment shader
+ inputs not qualified with "centroid" may have the same value for each
+ invocation.
+
+
+ Modify Section 14.6.X, Conservative Rasterization from the
+ NV_conservative_raster extension specification
+
+ (add to the end of the section)
+
+ When the shading rate results in fragments covering more than one pixel,
+ coverage evaluation for conservative rasterization will be performed
+ independently for each pixel. In a such a case, a pixel considered not to
+ be covered by a conservatively rasterized primitive will still be
+ considered uncovered even if a neighboring pixel in the same fragment is
+ covered.
+
+
+ Modify Section 14.9.2, Scissor Test
+
+ (add to the end of the section)
+
+ When the shading rate results in fragments covering more than one pixel,
+ the scissor tests are performed separately for each pixel in the fragment.
+ If a pixel covered by a fragment fails either the scissor or exclusive
+ scissor test, that pixel is treated as though it was not covered by the
+ primitive. If all pixels covered by a fragment are either not covered by
+ the primitive being rasterized or fail either scissor test, the fragment
+ is discarded.
+
+
+ Modify Section 14.9.3, Multisample Fragment Operations (p. 562)
+
+ (modify the end of the first paragraph to indicate that sample mask
+ operations are performed when using the shading rate image, which can
+ produce coarse fragments where each pixel is considered a "sample")
+
+ ... This step is skipped if MULTISAMPLE is disabled or if the value of
+ SAMPLE_BUFFERS is not one, unless SHADING_RATE_IMAGE_NV is enabled for one
+ or more viewports.
+
+ (add to the end of the section)
+
+ When the shading rate results in fragments covering more than one pixel,
+ each fragment will a composite coverage mask that includes separate
+ coverage bits for each sample in each pixel covered by the fragment. This
+ composite coverage mask will be used by the GLSL built-in input variable
+ gl_SampleMaskIn[] and updated according to the built-in output variable
+ gl_SampleMask[]. Each bit number in this composite mask maps to a
+ specific pixel and sample number within that pixel.
+
+ When building the composite coverage mask for a fragment, rasterization
+ logic evaluates separate per-pixel coverage masks and then modifies each
+ per-pixel mask as described in this section. After that, it assembles the
+ composite mask by applying the mapping of composite mask bits to
+ pixels/samples, which can be queried using GetShadingRateSampleLocationfvNV.
+ When using the output sample mask gl_SampleMask[] to determine which
+ samples should be updated by subsequent per-fragment operations, a set of
+ separate per-pixel output masks is extracted by reversing the mapping used
+ to generate the composite sample mask.
+
+
+ Modify Section 15.1, Fragment Shader Variables (p. 566)
+
+ (modify fourth paragraph, p. 567, specifying how "centroid" works for
+ multi-pixel fragments)
+
+ When interpolating input variables, the default screen-space location at
+ which these variables are sampled is defined in previous rasterization
+ sections. The default location may be overriden by interpolation
+ qualifiers. When interpolating variables declared using "centroid in",
+ the variable is sampled at a location inside the area of the fragment that
+ is covered by the primitive generating the fragment. ...
+
+
+ Modify Section 15.2.2, Shader Inputs (p. 566), as edited by
+ NV_conservative_raster_underestimation
+
+ (add to new paragraph on gl_FragFullyCoveredNV)
+
+ When CONSERVATIVE_RASTERIZATION_NV or CONSERVATIVE_RASTERIZATION2_NV is
+ enabled, the built-in read-only variable gl_FragFullyCoveredNV is set to
+ true if the fragment is fully covered by the generating primitive, and
+ false otherwise. When the shading rate results in fragments covering more
+ than one pixel, gl_FragFullyCoveredNV will be true if and only if all
+ pixels covered by the fragment are fully covered by the primitive being
+ rasterized.
+
+
+ Modify Section 17.3, Per-Fragment Operations (p. 587)
+
+ (insert a new paragraph after the first paragraph of the section)
+
+ If the fragment covers multiple pixels, the operations described in the
+ section are performed independently for each pixel covered by the
+ fragment. The set of samples covered by each pixel is determined by
+ extracting the portion of the fragment's composite coverage that applies
+ to that pixel, as described in section 14.9.3.
+
+
+Dependencies on ARB_sample_locations and NV_sample_locations
+
+ If ARB_sample_locations or NV_sample_locations is supported, applications
+ can enable programmable sample locations instead of the default sample
+ locations, and also configure sample locations that may vary from pixel to
+ pixel.
+
+ When using "coarse" shading rates covering multiple pixels, the coarse
+ fragment is considered to include the samples of all the pixels it
+ contains. Each sample of each pixel in the coarse fragment is mapped to
+ exactly one sample in the coarse fragment. The location of each sample in
+ the coarse fragment is determined by mapping the sample to a pixel (px,py)
+ and a sample <s> within the identified pixel. The exact location of that
+ identified sample is the same as it would be for one-pixel fragments. If
+ programmable sample locations are enabled, those locations will be used.
+ If the sample location pixel grid is enabled, those locations will depend
+ on the (x,y) coordinate of the containing pixel.
+
+Dependencies on NV_scissor_exclusive
+
+ If NV_scissor_exclusive is not supported, remove references to the
+ exclusive scissor test in section 14.9.2.
+
+Dependencies on NV_sample_mask_override_coverage
+
+ If NV_sample_mask_override_coverage is supported, applications are able to
+ use the sample mask to enable coverage for samples not covered by the
+ primitive being rasterized. When this extension is used in conjunction
+ with a shading rate where fragments cover multiple pixels, it's possible
+ for the sample mask override to enable coverage for pixels that would
+ normally be discarded. For example, this can enable coverage in pixels
+ that are not covered by the primitive being rasterized or that fail the
+ scissor test.
+
+Dependencies on NV_conservative_raster
+
+ If NV_conservative_raster is supported, conservative rasterization
+ evaluates coverage per pixel, even when using a shading rate that
+ specifies multiple pixels per fragment.
+
+ If NV_conservative_raster is not supported, remove edits to the "Section
+ 14.6.X" section from that extension.
+
+Dependencies on NV_conservative_raster_underestimation
+
+ If NV_conservative_raster_underestimation is supported, and conservative
+ rasterization is enabled with a shading rate that specifies multiple
+ pixels per fragment, gl_FragFullyCoveredNV will be true if and only if all
+ pixels covered by the fragment are fully covered by the primitive being
+ rasterized.
+
+ If NV_conservative_raster_underestimation is not supported, remove edits
+ to Section 15.2.2 related to gl_FragFullyCoveredNV.
+
+Dependencies on EXT_raster_multisample
+
+ If EXT_raster_multisample is not supported, remove the language allowing
+ implementations to reduce the number of fragment shader invocations
+ per pixel if RASTER_MULTISAMPLE_EXT is enabled.
+
+
+Additions to the AGL/GLX/WGL Specifications
+
+ None
+
+Errors
+
+ See the "Errors" sections for individual commands above.
+
+New State
+
+ Get Value Get Command Type Initial Value Description Sec. Attribute
+ --------- --------------- ---- ------------- ----------- ---- ---------
+ SHADING_RATE_IMAGE_NV IsEnabledi 16+ x FALSE Use shading rate image to 14.4.1 enable
+ B determine shading rate for
+ a given viewport
+ SHADING_RATE_IMAGE_ GetIntegerv Z 0 Texture object bound for 14.4.1 none
+ BINDING_NV use as a shading rate image
+ <none> GetShadingRate- 16+ x SHADING_RATE_1_- Shading rate palette 14.4.1 none
+ ImagePaletteNV 16+ x INVOCATION_PER_- entries
+ Z12 PIXEL_NV
+ <none> GetShadingRate- many n/a Locations of individual 14.4.3 none
+ SampleLocation- 3xZ+ samples in "coarse"
+ fragments
+
+New Implementation Dependent State
+
+ Minimum
+ Get Value Type Get Command Value Description Sec.
+ --------- ----- --------------- ------- ------------------------ ------
+ SHADING_RATE_IMAGE_ Z+ GetIntegerv 1 Width (in pixels) covered by 14.4.1
+ TEXEL_WIDTH_NV each shading rate image texel
+ SHADING_RATE_IMAGE_ Z+ GetIntegerv 1 Height (in pixels) covered by 14.4.1
+ TEXEL_HEIGHT_NV each shading rate image texel
+ SHADING_RATE_IMAGE_ Z+ GetIntegerv 16 Number of entries in each 14.4.1
+ PALETTE_SIZE_NV viewport's shading rate
+ palette
+ MAX_COARSE_FRAGMENT_ Z+ GetIntegerv 1 Maximum number of samples in 14.4.3
+ PALETTE_SIZE_NV "coarse" fragments
+
+Issues
+
+ (1) How should we name this extension?
+
+ RESOLVED: We are calling this extension NV_shading_rate_image. We use
+ the term "shading rate" to indicate the variable number of fragment
+ shader invocations that will be spawned for a particular neighborhood of
+ covered pixels. The extension can support shading rates running one
+ invocation for multiple pixels and/or multiple invocations for a single
+ pixel. We use "image" in the extension name because we allow
+ applications to control the shading rate using an image, where each
+ pixel specifies a shading rate for a portion of the framebuffer.
+
+ We considered a name like "NV_variable_rate_shading", but decided that
+ name didn't sufficiently distinguish between this extension (where
+ shading rate varies across the framebuffer at once) from an extension
+ where an API is provided to change the shading rate for the entire
+ framebuffer. For example, the MinSampleShadingARB() API in
+ ARB_sample_shading allows an application to run one thread per pixel
+ (0.0) for some draw calls and one thread per sample (1.0) for others.
+
+ (2) Should this extension support only off-screen (FBO) rendering or can
+ it also support on-screen rendering?
+
+ RESOLVED: This extension only supports rendering to a framebuffer
+ object; the feature is disabled when rendering to the default
+ framebuffer. In some window system environments, the default
+ framebuffer may be a subset of a larger framebuffer allocation
+ corresponding the full screen. Because the initial hardware
+ implementation of this extension always uses (x,y) coordinates relative
+ to the framebuffer allocation to determine the shading rate, the shading
+ rate would depend on the location of a window on the screen and change
+ as the window moves. While some window systems may have separate
+ default framebuffer allocations for each window, we've chosen to
+ disallow use of the shading rate image with the default framebuffer
+ globally instead of adding a "Can I use the shading rate image with a
+ default framebuffer?" query.
+
+ (3) How does this feature work with per-sample shading?
+
+ RESOLVED: When using per-sample shading, an application is expecting a
+ fragment shader to run with a separate invocation per sample. The
+ shading rate image might allow for a "coarsening" that would break such
+ shaders. We've chosen to override the shading rate (effectively
+ disabling the shading rate image) when per-sample shading is used.
+
+ (4) Should BindShadingRateImageNV take any arguments to bind a subset of
+ a complex texture (e.g., a specific layer of an array texture or a
+ non-base mipmap level)?
+
+ RESOLVED: No. Applications can use texture views to create texture
+ that refer to the desired subset of a more complex texture, if required.
+
+ (5) Does a shading rate image need to be bound in order to use the shading
+ rate feature?
+
+ RESOLVED: No. The behavior where there is no texture bound when
+ SHADING_RATE_IMAGE_NV is enabled is explicitly defined to behave as if a
+ lookup was performed and returned zero. If an application wants to use
+ a constant rate other than SHADING_RATE_1_INVOCATION_PER_PIXEL_NV, it
+ can enable SHADING_RATE_IMAGE_NV, ensure no image is bound, and define
+ the entries for index zero in the relevant palette(s) to contain the
+ desired shading rate. This technique can be used to emulate 16x
+ multisampling on implementations that don't support it by binding larger
+ 4x multisample textures to the framebuffer and then setting a shading
+ rate of SHADING_RATE_1_INVOCATION_PER_2X2_PIXELS_NV.
+
+ (6) How is the FRAGMENT_SHADER_INVOCATIONS_ARB query (from
+ ARB_pipeline_statistics_query) handled with fragments covering
+ multiple pixels?
+
+ RESOLVED: The fragment shader invocation for each multi-pixel fragment
+ is counted exactly once.
+
+ (7) How do we handle the combination of variable-rate shading (including
+ multiple invocations per pixel) and target-independent rasterization
+ (i.e., RASTER_MULTISAMPLE_EXT)?
+
+ RESOLVED: In EXT_raster_multisample, the specification allows
+ implementations to run a single fragment shader invocation for each
+ pixel, even if sample shading would normally call for multiple
+ invocations per pixel:
+
+ If RASTER_MULTISAMPLE_EXT is enabled, the number of unique samples to
+ process is implementation-dependent and need not be more than one.
+
+ The shading rates in this extension calling for multiple fragment shader
+ invocations per pixel behave similarly to sample shading, so we extend
+ the allowance to this extension as well. If the shading rate in a
+ region of the framebuffer calls for multiple fragment shader invocations
+ per pixel, implementations are permitted to modify the shading rate and
+ need not support more than one invocation per pixel.
+
+ (8) Both the shading rate image and the framebuffer attachments can be
+ layered or non-layered. Do they have to match?
+
+ RESOLVED: No. When using a shading rate image with a target of
+ TEXTURE_2D with a layered framebuffer, all layers in the framebuffer
+ will use the same two-dimensional shading rate image. When using a
+ shading rate image with a target of TEXTURE_2D_ARRAY with a non-layered
+ framebuffer, layer zero of the shading rate image will be used, except
+ perhaps in the (undefined behavior) case where a shader writes a
+ non-zero value to gl_Layer.
+
+ (9) When using shading rates that specify "coarse" fragments covering
+ multiple pixels, we will generate a combined coverage mask that
+ combines the coverage masks of all pixels covered by the fragment. By
+ default, these masks are combined in an implementation-dependent
+ order. Should we provide a mechanism allowing applications to query
+ or specify an exact order?
+
+ RESOLVED: Yes, this feature is useful for cases where most of the
+ fragment shader can be evaluated once for an entire coarse fragment, but
+ where some per-pixel computations are also required. For example, a
+ per-pixel alpha test may want to kill all the samples for some pixels in
+ a coarse fragment. This sort of test can be implemented using an output
+ sample mask, but such a shader would need to know which bit in the mask
+ corresponds to each sample in the coarse fragment. The command
+ ShadingRateSampleOrderNV allows applications to specify simple orderings
+ for all combinations, while ShadingRateSampleOrderCustomNV allows for
+ completely customized orders for each combination.
+
+ (10) How do centroid-sampled variables work with fragments larger than one
+ pixel?
+
+ RESOLVED: For single-pixel fragments, attributes declared with
+ "centroid" are sampled at an implementation-dependent location in the
+ intersection of the area of the primitive being rasterized and the area
+ of the pixel that corresponds to the fragment. With multi-pixel
+ fragments, we follow a similar pattern, using the intersection of the
+ primitive and the *set* of pixels corresponding to the fragment.
+
+ One important thing to keep in mind when using such "coarse" shading
+ rates is that fragment attributes are sampled at the center of the
+ fragment by default, regardless of the set of pixels/samples covered by
+ the fragment. For fragments with a size of 4x4 pixels, this center
+ location will be more than two pixels (1.5 * sqrt(2)) away from the
+ center of the pixels at the corners of the fragment. When rendering a
+ primitive that covers only a small part of a coarse fragment,
+ interpolating a color outside the primitive can produce overly bright or
+ dark color values if the color values have a large gradient. To deal
+ with this, an application can use centroid sampling on attributes where
+ "extrapolation" artifacts can lead to overly bright or dark pixels.
+ Note that this same problem also exists for multisampling with
+ single-pixel fragments, but is less severe because it only affects
+ certain samples of a pixel and such bright/dark samples may be averaged
+ with other samples that don't have a similar problem.
+
+ (11) How does this feature interact with multisampling?
+
+ RESOLVED: The shading rate image can produce "coarse" fragments larger
+ than one pixel, which we want to behave a lot like regular multisample.
+ One can consider each coarse fragment to be a lot like a "pixel", where
+ the individual pixels covered by the fragment are treated as "samples".
+
+ When the shading rate is enabled, we override several rules related to
+ multisampling:
+
+ (a) Multisample rasterization rules apply, even if we don't have
+ multisample buffers or if MULTISAMPLE is disabled.
+
+ (b) Coverage for the pixels comprising a coarse fragment is combined
+ into a single aggregate coverage mask that can be read using the
+ fragment shader input "gl_SampleMaskIn[]".
+
+ (c) Coverage for pixels comprising a coarse fragment can be modified using
+ the fragment shader output "gl_SampleMask[]", which is also
+ interpreted as an aggregate coverage mask.
+
+ Note that (a) means that point and line primitives may be rasterized
+ differently depending on whether the shading rate image is enabled or
+ disabled.
+
+ Also, please refer to issues in the GLSL extension specification.
+
+Revision History
+
+ Revision 1 (pbrown)
+ - Internal revisions.
diff --git a/extensions/glext.php b/extensions/glext.php
index 12a22e4..7ed507b 100644
--- a/extensions/glext.php
+++ b/extensions/glext.php
@@ -987,4 +987,18 @@
</li>
<li value=524><a href="extensions/NV/NV_memory_attachment.txt">GL_NV_memory_attachment</a>
</li>
+<li value=525><a href="extensions/NV/NV_compute_shader_derivatives.txt">GL_NV_compute_shader_derivatives</a>
+</li>
+<li value=526><a href="extensions/NV/NV_fragment_shader_barycentric.txt">GL_NV_fragment_shader_barycentric</a>
+</li>
+<li value=527><a href="extensions/NV/NV_mesh_shader.txt">GL_NV_mesh_shader</a>
+</li>
+<li value=528><a href="extensions/NV/NV_representative_fragment_test.txt">GL_NV_representative_fragment_test</a>
+</li>
+<li value=529><a href="extensions/NV/NV_scissor_exclusive.txt">GL_NV_scissor_exclusive</a>
+</li>
+<li value=530><a href="extensions/NV/NV_shader_texture_footprint.txt">GL_NV_shader_texture_footprint</a>
+</li>
+<li value=531><a href="extensions/NV/NV_shading_rate_image.txt">GL_NV_shading_rate_image</a>
+</li>
</ol>
diff --git a/extensions/registry.py b/extensions/registry.py
index 076be30..f3963cd 100755
--- a/extensions/registry.py
+++ b/extensions/registry.py
@@ -3107,6 +3107,12 @@
'supporters' : { 'NVIDIA' },
'url' : 'extensions/NV/NV_compute_program5.txt',
},
+ 'GL_NV_compute_shader_derivatives' : {
+ 'number' : 525,
+ 'flags' : { 'public' },
+ 'supporters' : { 'NVIDIA' },
+ 'url' : 'extensions/NV/NV_compute_shader_derivatives.txt',
+ },
'GL_NV_conditional_render' : {
'number' : 346,
'esnumber' : 198,
@@ -3300,6 +3306,12 @@
'supporters' : { 'NVIDIA' },
'url' : 'extensions/NV/NV_fragment_program_option.txt',
},
+ 'GL_NV_fragment_shader_barycentric' : {
+ 'number' : 526,
+ 'flags' : { 'public' },
+ 'supporters' : { 'NVIDIA' },
+ 'url' : 'extensions/NV/NV_fragment_shader_barycentric.txt',
+ },
'GL_NV_fragment_shader_interlock' : {
'number' : 468,
'esnumber' : 230,
@@ -3417,6 +3429,12 @@
'supporters' : { 'NVIDIA' },
'url' : 'extensions/NV/NV_memory_attachment.txt',
},
+ 'GL_NV_mesh_shader' : {
+ 'number' : 527,
+ 'flags' : { 'public' },
+ 'supporters' : { 'NVIDIA' },
+ 'url' : 'extensions/NV/NV_mesh_shader.txt',
+ },
'GL_NV_multisample_coverage' : {
'number' : 393,
'flags' : { 'public' },
@@ -3555,6 +3573,12 @@
'supporters' : { 'NVIDIA' },
'url' : 'extensions/NV/NV_register_combiners2.txt',
},
+ 'GL_NV_representative_fragment_test' : {
+ 'number' : 528,
+ 'flags' : { 'public' },
+ 'supporters' : { 'NVIDIA' },
+ 'url' : 'extensions/NV/NV_representative_fragment_test.txt',
+ },
'GL_NV_robustness_video_memory_purge' : {
'number' : 484,
'flags' : { 'public' },
@@ -3577,6 +3601,12 @@
'flags' : { 'public' },
'url' : 'extensions/NV/NV_sample_mask_override_coverage.txt',
},
+ 'GL_NV_scissor_exclusive' : {
+ 'number' : 529,
+ 'flags' : { 'public' },
+ 'supporters' : { 'NVIDIA' },
+ 'url' : 'extensions/NV/NV_scissor_exclusive.txt',
+ },
'GL_NV_shader_atomic_counters' : {
'number' : 423,
'flags' : { 'public' },
@@ -3629,6 +3659,12 @@
'supporters' : { 'NVIDIA' },
'url' : 'extensions/NV/NV_shader_storage_buffer_object.txt',
},
+ 'GL_NV_shader_texture_footprint' : {
+ 'number' : 530,
+ 'flags' : { 'public' },
+ 'supporters' : { 'NVIDIA' },
+ 'url' : 'extensions/NV/NV_shader_texture_footprint.txt',
+ },
'GL_NV_shader_thread_group' : {
'number' : 447,
'flags' : { 'public' },
@@ -3639,6 +3675,12 @@
'flags' : { 'public' },
'url' : 'extensions/NV/NV_shader_thread_shuffle.txt',
},
+ 'GL_NV_shading_rate_image' : {
+ 'number' : 531,
+ 'flags' : { 'public' },
+ 'supporters' : { 'NVIDIA' },
+ 'url' : 'extensions/NV/NV_shading_rate_image.txt',
+ },
'GL_NV_shadow_samplers_array' : {
'esnumber' : 146,
'flags' : { 'public' },
diff --git a/xml/gl.xml b/xml/gl.xml
index 3628bb2..f341c37 100755
--- a/xml/gl.xml
+++ b/xml/gl.xml
@@ -2546,6 +2546,8 @@
<enum name="GL_TESS_EVALUATION_SHADER_BIT_EXT"/>
<enum name="GL_TESS_EVALUATION_SHADER_BIT_OES"/>
<enum name="GL_COMPUTE_SHADER_BIT"/>
+ <enum name="GL_MESH_SHADER_BIT_NV"/>
+ <enum name="GL_TASK_SHADER_BIT_NV"/>
<enum name="GL_ALL_SHADER_BITS"/>
<enum name="GL_ALL_SHADER_BITS_EXT"/>
</group>
@@ -3700,6 +3702,8 @@
<enum value="0x00000010" name="GL_TESS_EVALUATION_SHADER_BIT_EXT"/>
<enum value="0x00000010" name="GL_TESS_EVALUATION_SHADER_BIT_OES"/>
<enum value="0x00000020" name="GL_COMPUTE_SHADER_BIT"/>
+ <enum value="0x00000040" name="GL_MESH_SHADER_BIT_NV"/>
+ <enum value="0x00000080" name="GL_TASK_SHADER_BIT_NV"/>
<enum value="0xFFFFFFFF" name="GL_ALL_SHADER_BITS"/>
<enum value="0xFFFFFFFF" name="GL_ALL_SHADER_BITS_EXT"/>
</enums>
@@ -8814,7 +8818,22 @@
<enum value="0x8E5F" name="GL_MAX_PROGRAM_TEXTURE_GATHER_OFFSET"/>
<enum value="0x8E5F" name="GL_MAX_PROGRAM_TEXTURE_GATHER_OFFSET_ARB"/>
<enum value="0x8E5F" name="GL_MAX_PROGRAM_TEXTURE_GATHER_OFFSET_NV"/>
- <unused start="0x8E60" end="0x8E6F" vendor="NV"/>
+ <enum value="0x8E60" name="GL_MAX_MESH_UNIFORM_BLOCKS_NV"/>
+ <enum value="0x8E61" name="GL_MAX_MESH_TEXTURE_IMAGE_UNITS_NV"/>
+ <enum value="0x8E62" name="GL_MAX_MESH_IMAGE_UNIFORMS_NV"/>
+ <enum value="0x8E63" name="GL_MAX_MESH_UNIFORM_COMPONENTS_NV"/>
+ <enum value="0x8E64" name="GL_MAX_MESH_ATOMIC_COUNTER_BUFFERS_NV"/>
+ <enum value="0x8E65" name="GL_MAX_MESH_ATOMIC_COUNTERS_NV"/>
+ <enum value="0x8E66" name="GL_MAX_MESH_SHADER_STORAGE_BLOCKS_NV"/>
+ <enum value="0x8E67" name="GL_MAX_COMBINED_MESH_UNIFORM_COMPONENTS_NV"/>
+ <enum value="0x8E68" name="GL_MAX_TASK_UNIFORM_BLOCKS_NV"/>
+ <enum value="0x8E69" name="GL_MAX_TASK_TEXTURE_IMAGE_UNITS_NV"/>
+ <enum value="0x8E6A" name="GL_MAX_TASK_IMAGE_UNIFORMS_NV"/>
+ <enum value="0x8E6B" name="GL_MAX_TASK_UNIFORM_COMPONENTS_NV"/>
+ <enum value="0x8E6C" name="GL_MAX_TASK_ATOMIC_COUNTER_BUFFERS_NV"/>
+ <enum value="0x8E6D" name="GL_MAX_TASK_ATOMIC_COUNTERS_NV"/>
+ <enum value="0x8E6E" name="GL_MAX_TASK_SHADER_STORAGE_BLOCKS_NV"/>
+ <enum value="0x8E6F" name="GL_MAX_COMBINED_TASK_UNIFORM_COMPONENTS_NV"/>
<enum value="0x8E70" name="GL_MAX_TRANSFORM_FEEDBACK_BUFFERS"/>
<enum value="0x8E71" name="GL_MAX_VERTEX_STREAMS"/>
<enum value="0x8E72" name="GL_PATCH_VERTICES"/>
@@ -9832,7 +9851,7 @@
<enum value="0x92DC" name="GL_MAX_ATOMIC_COUNTER_BUFFER_BINDINGS"/>
<enum value="0x92DD" name="GL_FRAGMENT_COVERAGE_TO_COLOR_NV"/>
<enum value="0x92DE" name="GL_FRAGMENT_COVERAGE_COLOR_NV"/>
- <unused start="0x92DF" end="0x92DF" vendor="NV"/>
+ <enum value="0x92DF" name="GL_MESH_OUTPUT_PER_VERTEX_GRANULARITY_NV"/>
<enum value="0x92E0" name="GL_DEBUG_OUTPUT"/>
<enum value="0x92E0" name="GL_DEBUG_OUTPUT_KHR"/>
<enum value="0x92E1" name="GL_UNIFORM"/>
@@ -9995,7 +10014,7 @@
<enum value="0x937C" name="GL_VIEWPORT_POSITION_W_SCALE_NV"/>
<enum value="0x937D" name="GL_VIEWPORT_POSITION_W_SCALE_X_COEFF_NV"/>
<enum value="0x937E" name="GL_VIEWPORT_POSITION_W_SCALE_Y_COEFF_NV"/>
- <unused start="0x937F" vendor="NV"/>
+ <enum value="0x937F" name="GL_REPRESENTATIVE_FRAGMENT_TEST_NV"/>
</enums>
<enums namespace="GL" start="0x9380" end="0x939F" vendor="ARB">
@@ -10134,11 +10153,21 @@
<enums namespace="GL" start="0x9530" end="0x962F" vendor="NV" comment="Khronos bug 12977">
<enum value="0x9530" name="GL_LAYOUT_DEPTH_READ_ONLY_STENCIL_ATTACHMENT_EXT"/>
<enum value="0x9531" name="GL_LAYOUT_DEPTH_ATTACHMENT_STENCIL_READ_ONLY_EXT"/>
- <unused start="0x9532" end="0x953F" vendor="NV"/>
+ <unused start="0x9532" end="0x9535" vendor="NV"/>
+ <enum value="0x9536" name="GL_MAX_MESH_TOTAL_MEMORY_SIZE_NV"/>
+ <enum value="0x9537" name="GL_MAX_TASK_TOTAL_MEMORY_SIZE_NV"/>
+ <enum value="0x9538" name="GL_MAX_MESH_OUTPUT_VERTICES_NV"/>
+ <enum value="0x9539" name="GL_MAX_MESH_OUTPUT_PRIMITIVES_NV"/>
+ <enum value="0x953A" name="GL_MAX_TASK_OUTPUT_COUNT_NV"/>
+ <enum value="0x953B" name="GL_MAX_MESH_WORK_GROUP_SIZE_NV"/>
+ <enum value="0x953C" name="GL_MAX_TASK_WORK_GROUP_SIZE_NV"/>
+ <enum value="0x953D" name="GL_MAX_DRAW_MESH_TASKS_COUNT_NV"/>
+ <enum value="0x953E" name="GL_MESH_WORK_GROUP_SIZE_NV"/>
+ <enum value="0x953F" name="GL_TASK_WORK_GROUP_SIZE_NV"/>
<enum value="0x9540" name="GL_QUERY_RESOURCE_TYPE_VIDMEM_ALLOC_NV"/>
<unused start="0x9541" vendor="NV"/>
<enum value="0x9542" name="GL_QUERY_RESOURCE_MEMTYPE_VIDMEM_NV"/>
- <unused start="0x9543" vendor="NV"/>
+ <enum value="0x9543" name="GL_MESH_OUTPUT_PER_PRIMITIVE_GRANULARITY_NV"/>
<enum value="0x9544" name="GL_QUERY_RESOURCE_SYS_RESERVED_NV"/>
<enum value="0x9545" name="GL_QUERY_RESOURCE_TEXTURE_NV"/>
<enum value="0x9546" name="GL_QUERY_RESOURCE_RENDERBUFFER_NV"/>
@@ -10156,9 +10185,39 @@
<enum value="0x9552" name="GL_SPIR_V_BINARY_ARB" alias="GL_SPIR_V_BINARY"/>
<enum value="0x9553" name="GL_SPIR_V_EXTENSIONS"/>
<enum value="0x9554" name="GL_NUM_SPIR_V_EXTENSIONS"/>
- <unused start="0x9555" end="0x9557" vendor="NV"/>
+ <enum value="0x9555" name="GL_SCISSOR_TEST_EXCLUSIVE_NV"/>
+ <enum value="0x9556" name="GL_SCISSOR_BOX_EXCLUSIVE_NV"/>
+ <enum value="0x9557" name="GL_MAX_MESH_VIEWS_NV"/>
<enum value="0x9558" name="GL_RENDER_GPU_MASK_NV"/>
- <unused start="0x9559" end="0x957F" vendor="NV"/>
+ <enum value="0x9559" name="GL_MESH_SHADER_NV"/>
+ <enum value="0x955A" name="GL_TASK_SHADER_NV"/>
+ <enum value="0x955B" name="GL_SHADING_RATE_IMAGE_BINDING_NV"/>
+ <enum value="0x955C" name="GL_SHADING_RATE_IMAGE_TEXEL_WIDTH_NV"/>
+ <enum value="0x955D" name="GL_SHADING_RATE_IMAGE_TEXEL_HEIGHT_NV"/>
+ <enum value="0x955E" name="GL_SHADING_RATE_IMAGE_PALETTE_SIZE_NV"/>
+ <enum value="0x955F" name="GL_MAX_COARSE_FRAGMENT_SAMPLES_NV"/>
+ <unused start="0x9560" end="0x9562" vendor="NV"/>
+ <enum value="0x9563" name="GL_SHADING_RATE_IMAGE_NV"/>
+ <enum value="0x9564" name="GL_SHADING_RATE_NO_INVOCATIONS_NV"/>
+ <enum value="0x9565" name="GL_SHADING_RATE_1_INVOCATION_PER_PIXEL_NV"/>
+ <enum value="0x9566" name="GL_SHADING_RATE_1_INVOCATION_PER_1X2_PIXELS_NV"/>
+ <enum value="0x9567" name="GL_SHADING_RATE_1_INVOCATION_PER_2X1_PIXELS_NV"/>
+ <enum value="0x9568" name="GL_SHADING_RATE_1_INVOCATION_PER_2X2_PIXELS_NV"/>
+ <enum value="0x9569" name="GL_SHADING_RATE_1_INVOCATION_PER_2X4_PIXELS_NV"/>
+ <enum value="0x956A" name="GL_SHADING_RATE_1_INVOCATION_PER_4X2_PIXELS_NV"/>
+ <enum value="0x956B" name="GL_SHADING_RATE_1_INVOCATION_PER_4X4_PIXELS_NV"/>
+ <enum value="0x956C" name="GL_SHADING_RATE_2_INVOCATIONS_PER_PIXEL_NV"/>
+ <enum value="0x956D" name="GL_SHADING_RATE_4_INVOCATIONS_PER_PIXEL_NV"/>
+ <enum value="0x956E" name="GL_SHADING_RATE_8_INVOCATIONS_PER_PIXEL_NV"/>
+ <enum value="0x956F" name="GL_SHADING_RATE_16_INVOCATIONS_PER_PIXEL_NV"/>
+ <unused start="0x9570" end="0x9578" vendor="NV"/>
+ <enum value="0x9579" name="GL_MESH_VERTICES_OUT_NV"/>
+ <enum value="0x957A" name="GL_MESH_PRIMITIVES_OUT_NV"/>
+ <enum value="0x957B" name="GL_MESH_OUTPUT_TYPE_NV"/>
+ <enum value="0x957C" name="GL_MESH_SUBROUTINE_NV"/>
+ <enum value="0x957D" name="GL_TASK_SUBROUTINE_NV"/>
+ <enum value="0x957E" name="GL_MESH_SUBROUTINE_UNIFORM_NV"/>
+ <enum value="0x957F" name="GL_TASK_SUBROUTINE_UNIFORM_NV"/>
<enum value="0x9580" name="GL_TEXTURE_TILING_EXT"/>
<enum value="0x9581" name="GL_DEDICATED_MEMORY_OBJECT_EXT"/>
<enum value="0x9582" name="GL_NUM_TILING_TYPES_EXT"/>
@@ -10187,7 +10246,14 @@
<enum value="0x9599" name="GL_DEVICE_LUID_EXT"/>
<enum value="0x959A" name="GL_DEVICE_NODE_MASK_EXT"/>
<enum value="0x959B" name="GL_PROTECTED_MEMORY_OBJECT_EXT"/>
- <unused start="0x959C" end="0x95A3" vendor="NV"/>
+ <enum value="0x959C" name="GL_UNIFORM_BLOCK_REFERENCED_BY_MESH_SHADER_NV"/>
+ <enum value="0x959D" name="GL_UNIFORM_BLOCK_REFERENCED_BY_TASK_SHADER_NV"/>
+ <enum value="0x959E" name="GL_ATOMIC_COUNTER_BUFFER_REFERENCED_BY_MESH_SHADER_NV"/>
+ <enum value="0x959F" name="GL_ATOMIC_COUNTER_BUFFER_REFERENCED_BY_TASK_SHADER_NV"/>
+ <enum value="0x95A0" name="GL_REFERENCED_BY_MESH_SHADER_NV"/>
+ <enum value="0x95A1" name="GL_REFERENCED_BY_TASK_SHADER_NV"/>
+ <enum value="0x95A2" name="GL_MAX_MESH_WORK_GROUP_INVOCATIONS_NV"/>
+ <enum value="0x95A3" name="GL_MAX_TASK_WORK_GROUP_INVOCATIONS_NV"/>
<enum value="0x95A4" name="GL_ATTACHED_MEMORY_OBJECT_NV"/>
<enum value="0x95A5" name="GL_ATTACHED_MEMORY_OFFSET_NV"/>
<enum value="0x95A6" name="GL_MEMORY_ATTACHABLE_ALIGNMENT_NV"/>
@@ -10198,7 +10264,10 @@
<enum value="0x95AB" name="GL_DETACHED_BUFFERS_NV"/>
<enum value="0x95AC" name="GL_MAX_DETACHED_TEXTURES_NV"/>
<enum value="0x95AD" name="GL_MAX_DETACHED_BUFFERS_NV"/>
- <unused start="0x95AE" end="0x962F" vendor="NV"/>
+ <enum value="0x95AE" name="GL_SHADING_RATE_SAMPLE_ORDER_DEFAULT_NV"/>
+ <enum value="0x95AF" name="GL_SHADING_RATE_SAMPLE_ORDER_PIXEL_MAJOR_NV"/>
+ <enum value="0x95B0" name="GL_SHADING_RATE_SAMPLE_ORDER_SAMPLE_MAJOR_NV"/>
+ <unused start="0x9581" end="0x962F" vendor="NV"/>
</enums>
<enums namespace="GL" start="0x9630" end="0x963F" vendor="Oculus" comment="Email from Cass Everitt">
@@ -10811,6 +10880,10 @@
<param len="count">const <ptype>GLuint</ptype> *<name>samplers</name></param>
</command>
<command>
+ <proto>void <name>glBindShadingRateImageNV</name></proto>
+ <param><ptype>GLuint</ptype> <name>texture</name></param>
+ </command>
+ <command>
<proto><ptype>GLuint</ptype> <name>glBindTexGenParameterEXT</name></proto>
<param group="TextureUnit"><ptype>GLenum</ptype> <name>unit</name></param>
<param group="TextureCoordName"><ptype>GLenum</ptype> <name>coord</name></param>
@@ -14487,6 +14560,15 @@
<param><ptype>GLsizei</ptype> <name>width</name></param>
</command>
<command>
+ <proto>void <name>glDrawMeshTasksNV</name></proto>
+ <param><ptype>GLuint</ptype> <name>first</name></param>
+ <param><ptype>GLuint</ptype> <name>count</name></param>
+ </command>
+ <command>
+ <proto>void <name>glDrawMeshTasksIndirectNV</name></proto>
+ <param><ptype>GLintptr</ptype> <name>indirect</name></param>
+ </command>
+ <command>
<proto>void <name>glDrawPixels</name></proto>
<param><ptype>GLsizei</ptype> <name>width</name></param>
<param><ptype>GLsizei</ptype> <name>height</name></param>
@@ -18272,6 +18354,19 @@
<glx type="single" opcode="198"/>
</command>
<command>
+ <proto>void <name>glGetShadingRateImagePaletteNV</name></proto>
+ <param><ptype>GLuint</ptype> <name>viewport</name></param>
+ <param><ptype>GLuint</ptype> <name>entry</name></param>
+ <param len="1"><ptype>GLenum</ptype> *<name>rate</name></param>
+ </command>
+ <command>
+ <proto>void <name>glGetShadingRateSampleLocationivNV</name></proto>
+ <param><ptype>GLenum</ptype> <name>rate</name></param>
+ <param><ptype>GLuint</ptype> <name>samples</name></param>
+ <param><ptype>GLuint</ptype> <name>index</name></param>
+ <param len="3"><ptype>GLint</ptype> *<name>location</name></param>
+ </command>
+ <command>
<proto>void <name>glGetSharpenTexFuncSGIS</name></proto>
<param group="TextureTarget"><ptype>GLenum</ptype> <name>target</name></param>
<param len="COMPSIZE(target)"><ptype>GLfloat</ptype> *<name>points</name></param>
@@ -21155,6 +21250,19 @@
<alias name="glMultiDrawElementsIndirect"/>
</command>
<command>
+ <proto>void <name>glMultiDrawMeshTasksIndirectNV</name></proto>
+ <param><ptype>GLintptr</ptype> <name>indirect</name></param>
+ <param><ptype>GLsizei</ptype> <name>drawcount</name></param>
+ <param><ptype>GLsizei</ptype> <name>stride</name></param>
+ </command>
+ <command>
+ <proto>void <name>glMultiDrawMeshTasksIndirectCountNV</name></proto>
+ <param><ptype>GLintptr</ptype> <name>indirect</name></param>
+ <param><ptype>GLintptr</ptype> <name>drawcount</name></param>
+ <param><ptype>GLsizei</ptype> <name>maxdrawcount</name></param>
+ <param><ptype>GLsizei</ptype> <name>stride</name></param>
+ </command>
+ <command>
<proto>void <name>glMultiDrawRangeElementArrayAPPLE</name></proto>
<param group="PrimitiveType"><ptype>GLenum</ptype> <name>mode</name></param>
<param><ptype>GLuint</ptype> <name>start</name></param>
@@ -25879,6 +25987,19 @@
<alias name="glScissorArrayv"/>
</command>
<command>
+ <proto>void <name>glScissorExclusiveArrayvNV</name></proto>
+ <param><ptype>GLuint</ptype> <name>first</name></param>
+ <param><ptype>GLsizei</ptype> <name>count</name></param>
+ <param len="COMPSIZE(count)">const <ptype>GLint</ptype> *<name>v</name></param>
+ </command>
+ <command>
+ <proto>void <name>glScissorExclusiveNV</name></proto>
+ <param group="WinCoord"><ptype>GLint</ptype> <name>x</name></param>
+ <param group="WinCoord"><ptype>GLint</ptype> <name>y</name></param>
+ <param><ptype>GLsizei</ptype> <name>width</name></param>
+ <param><ptype>GLsizei</ptype> <name>height</name></param>
+ </command>
+ <command>
<proto>void <name>glScissorIndexed</name></proto>
<param><ptype>GLuint</ptype> <name>index</name></param>
<param><ptype>GLint</ptype> <name>left</name></param>
@@ -26314,6 +26435,27 @@
<param><ptype>GLuint</ptype> <name>storageBlockBinding</name></param>
</command>
<command>
+ <proto>void <name>glShadingRateImageBarrierNV</name></proto>
+ <param><ptype>GLboolean</ptype> <name>synchronize</name></param>
+ </command>
+ <command>
+ <proto>void <name>glShadingRateImagePaletteNV</name></proto>
+ <param><ptype>GLuint</ptype> <name>viewport</name></param>
+ <param><ptype>GLuint</ptype> <name>first</name></param>
+ <param><ptype>GLsizei</ptype> <name>count</name></param>
+ <param len="count">const <ptype>GLenum</ptype> *<name>rates</name></param>
+ </command>
+ <command>
+ <proto>void <name>glShadingRateSampleOrderNV</name></proto>
+ <param><ptype>GLenum</ptype> <name>order</name></param>
+ </command>
+ <command>
+ <proto>void <name>glShadingRateSampleOrderCustomNV</name></proto>
+ <param><ptype>GLenum</ptype> <name>rate</name></param>
+ <param><ptype>GLuint</ptype> <name>samples</name></param>
+ <param len="COMPSIZE(rate,samples)">const <ptype>GLint</ptype> *<name>locations</name></param>
+ </command>
+ <command>
<proto>void <name>glSharpenTexFuncSGIS</name></proto>
<param group="TextureTarget"><ptype>GLenum</ptype> <name>target</name></param>
<param><ptype>GLsizei</ptype> <name>n</name></param>
@@ -46297,6 +46439,7 @@
<enum name="GL_COMPUTE_PROGRAM_PARAMETER_BUFFER_NV"/>
</require>
</extension>
+ <extension name="GL_NV_compute_shader_derivatives" supported="gl" />
<extension name="GL_NV_conditional_render" supported="gl|glcore|gles2">
<require>
<enum name="GL_QUERY_WAIT_NV"/>
@@ -46615,6 +46758,7 @@
</extension>
<extension name="GL_NV_fragment_program4" supported="gl"/>
<extension name="GL_NV_fragment_program_option" supported="gl"/>
+ <extension name="GL_NV_fragment_shader_barycentric" supported="gl" />
<extension name="GL_NV_fragment_shader_interlock" supported="gl|glcore|gles2"/>
<extension name="GL_NV_framebuffer_blit" supported="gles2">
<require>
@@ -46921,6 +47065,62 @@
<command name="glNamedBufferAttachMemoryNV"/>
</require>
</extension>
+ <extension name="GL_NV_mesh_shader" supported="gl">
+ <require>
+ <enum name="GL_MESH_SHADER_NV"/>
+ <enum name="GL_TASK_SHADER_NV"/>
+ <enum name="GL_MAX_MESH_UNIFORM_BLOCKS_NV"/>
+ <enum name="GL_MAX_MESH_TEXTURE_IMAGE_UNITS_NV"/>
+ <enum name="GL_MAX_MESH_IMAGE_UNIFORMS_NV"/>
+ <enum name="GL_MAX_MESH_UNIFORM_COMPONENTS_NV"/>
+ <enum name="GL_MAX_MESH_ATOMIC_COUNTER_BUFFERS_NV"/>
+ <enum name="GL_MAX_MESH_ATOMIC_COUNTERS_NV"/>
+ <enum name="GL_MAX_MESH_SHADER_STORAGE_BLOCKS_NV"/>
+ <enum name="GL_MAX_COMBINED_MESH_UNIFORM_COMPONENTS_NV"/>
+ <enum name="GL_MAX_TASK_UNIFORM_BLOCKS_NV"/>
+ <enum name="GL_MAX_TASK_TEXTURE_IMAGE_UNITS_NV"/>
+ <enum name="GL_MAX_TASK_IMAGE_UNIFORMS_NV"/>
+ <enum name="GL_MAX_TASK_UNIFORM_COMPONENTS_NV"/>
+ <enum name="GL_MAX_TASK_ATOMIC_COUNTER_BUFFERS_NV"/>
+ <enum name="GL_MAX_TASK_ATOMIC_COUNTERS_NV"/>
+ <enum name="GL_MAX_TASK_SHADER_STORAGE_BLOCKS_NV"/>
+ <enum name="GL_MAX_COMBINED_TASK_UNIFORM_COMPONENTS_NV"/>
+ <enum name="GL_MAX_MESH_WORK_GROUP_INVOCATIONS_NV"/>
+ <enum name="GL_MAX_TASK_WORK_GROUP_INVOCATIONS_NV"/>
+ <enum name="GL_MAX_MESH_TOTAL_MEMORY_SIZE_NV"/>
+ <enum name="GL_MAX_TASK_TOTAL_MEMORY_SIZE_NV"/>
+ <enum name="GL_MAX_MESH_OUTPUT_VERTICES_NV"/>
+ <enum name="GL_MAX_MESH_OUTPUT_PRIMITIVES_NV"/>
+ <enum name="GL_MAX_TASK_OUTPUT_COUNT_NV"/>
+ <enum name="GL_MAX_DRAW_MESH_TASKS_COUNT_NV"/>
+ <enum name="GL_MAX_MESH_VIEWS_NV"/>
+ <enum name="GL_MESH_OUTPUT_PER_VERTEX_GRANULARITY_NV"/>
+ <enum name="GL_MESH_OUTPUT_PER_PRIMITIVE_GRANULARITY_NV"/>
+ <enum name="GL_MAX_MESH_WORK_GROUP_SIZE_NV"/>
+ <enum name="GL_MAX_TASK_WORK_GROUP_SIZE_NV"/>
+ <enum name="GL_MESH_WORK_GROUP_SIZE_NV"/>
+ <enum name="GL_TASK_WORK_GROUP_SIZE_NV"/>
+ <enum name="GL_MESH_VERTICES_OUT_NV"/>
+ <enum name="GL_MESH_PRIMITIVES_OUT_NV"/>
+ <enum name="GL_MESH_OUTPUT_TYPE_NV"/>
+ <enum name="GL_UNIFORM_BLOCK_REFERENCED_BY_MESH_SHADER_NV"/>
+ <enum name="GL_UNIFORM_BLOCK_REFERENCED_BY_TASK_SHADER_NV"/>
+ <enum name="GL_ATOMIC_COUNTER_BUFFER_REFERENCED_BY_MESH_SHADER_NV"/>
+ <enum name="GL_ATOMIC_COUNTER_BUFFER_REFERENCED_BY_TASK_SHADER_NV"/>
+ <enum name="GL_REFERENCED_BY_MESH_SHADER_NV"/>
+ <enum name="GL_REFERENCED_BY_TASK_SHADER_NV"/>
+ <enum name="GL_MESH_SUBROUTINE_NV"/>
+ <enum name="GL_TASK_SUBROUTINE_NV"/>
+ <enum name="GL_MESH_SUBROUTINE_UNIFORM_NV"/>
+ <enum name="GL_TASK_SUBROUTINE_UNIFORM_NV"/>
+ <enum name="GL_MESH_SHADER_BIT_NV"/>
+ <enum name="GL_TASK_SHADER_BIT_NV"/>
+ <command name="glDrawMeshTasksNV"/>
+ <command name="glDrawMeshTasksIndirectNV"/>
+ <command name="glMultiDrawMeshTasksIndirectNV"/>
+ <command name="glMultiDrawMeshTasksIndirectCountNV"/>
+ </require>
+ </extension>
<extension name="GL_NV_multisample_coverage" supported="gl">
<require>
<enum name="GL_SAMPLES_ARB"/>
@@ -47418,6 +47618,11 @@
<command name="glGetCombinerStageParameterfvNV"/>
</require>
</extension>
+ <extension name="GL_NV_representative_fragment_test" supported="gl">
+ <require>
+ <enum name="GL_REPRESENTATIVE_FRAGMENT_TEST_NV"/>
+ </require>
+ </extension>
<extension name="GL_NV_robustness_video_memory_purge" supported="gl">
<require>
<enum name="GL_PURGED_CONTEXT_RESET_NV"/>
@@ -47453,6 +47658,14 @@
</require>
</extension>
<extension name="GL_NV_sample_mask_override_coverage" supported="gl|glcore|gles2"/>
+ <extension name="GL_NV_scissor_exclusive" supported="gl">
+ <require>
+ <enum name="GL_SCISSOR_TEST_EXCLUSIVE_NV"/>
+ <enum name="GL_SCISSOR_BOX_EXCLUSIVE_NV"/>
+ <command name="glScissorExclusiveNV"/>
+ <command name="glScissorExclusiveArrayvNV"/>
+ </require>
+ </extension>
<extension name="GL_NV_shader_atomic_counters" supported="gl|glcore"/>
<extension name="GL_NV_shader_atomic_float" supported="gl|glcore"/>
<extension name="GL_NV_shader_atomic_float64" supported="gl|glcore"/>
@@ -47488,6 +47701,7 @@
</extension>
<extension name="GL_NV_shader_noperspective_interpolation" supported="gles2"/>
<extension name="GL_NV_shader_storage_buffer_object" supported="gl"/>
+ <extension name="GL_NV_shader_texture_footprint" supported="gl"/>
<extension name="GL_NV_shader_thread_group" supported="gl|glcore">
<require>
<enum name="GL_WARP_SIZE_NV"/>
@@ -47496,6 +47710,39 @@
</require>
</extension>
<extension name="GL_NV_shader_thread_shuffle" supported="gl|glcore"/>
+ <extension name="GL_NV_shading_rate_image" supported="gl">
+ <require>
+ <enum name="GL_SHADING_RATE_IMAGE_NV"/>
+ <enum name="GL_SHADING_RATE_NO_INVOCATIONS_NV"/>
+ <enum name="GL_SHADING_RATE_1_INVOCATION_PER_PIXEL_NV"/>
+ <enum name="GL_SHADING_RATE_1_INVOCATION_PER_1X2_PIXELS_NV"/>
+ <enum name="GL_SHADING_RATE_1_INVOCATION_PER_2X1_PIXELS_NV"/>
+ <enum name="GL_SHADING_RATE_1_INVOCATION_PER_2X2_PIXELS_NV"/>
+ <enum name="GL_SHADING_RATE_1_INVOCATION_PER_2X4_PIXELS_NV"/>
+ <enum name="GL_SHADING_RATE_1_INVOCATION_PER_4X2_PIXELS_NV"/>
+ <enum name="GL_SHADING_RATE_1_INVOCATION_PER_4X4_PIXELS_NV"/>
+ <enum name="GL_SHADING_RATE_2_INVOCATIONS_PER_PIXEL_NV"/>
+ <enum name="GL_SHADING_RATE_4_INVOCATIONS_PER_PIXEL_NV"/>
+ <enum name="GL_SHADING_RATE_8_INVOCATIONS_PER_PIXEL_NV"/>
+ <enum name="GL_SHADING_RATE_16_INVOCATIONS_PER_PIXEL_NV"/>
+ <enum name="GL_SHADING_RATE_IMAGE_BINDING_NV"/>
+ <enum name="GL_SHADING_RATE_IMAGE_TEXEL_WIDTH_NV"/>
+ <enum name="GL_SHADING_RATE_IMAGE_TEXEL_HEIGHT_NV"/>
+ <enum name="GL_SHADING_RATE_IMAGE_PALETTE_SIZE_NV"/>
+ <enum name="GL_MAX_COARSE_FRAGMENT_SAMPLES_NV"/>
+ <enum name="GL_SHADING_RATE_SAMPLE_ORDER_DEFAULT_NV"/>
+ <enum name="GL_SHADING_RATE_SAMPLE_ORDER_PIXEL_MAJOR_NV"/>
+ <enum name="GL_SHADING_RATE_SAMPLE_ORDER_SAMPLE_MAJOR_NV"/>
+ <command name="glBindShadingRateImageNV"/>
+ <command name="glGetShadingRateImagePaletteNV"/>
+ <command name="glGetShadingRateSampleLocationivNV"/>
+ <command name="glShadingRateImageBarrierNV"/>
+ <command name="glShadingRateImageBarrierNV"/>
+ <command name="glShadingRateImagePaletteNV"/>
+ <command name="glShadingRateSampleOrderNV"/>
+ <command name="glShadingRateSampleOrderCustomNV"/>
+ </require>
+ </extension>
<extension name="GL_NV_shadow_samplers_array" supported="gles2">
<require>
<enum name="GL_SAMPLER_2D_ARRAY_SHADOW_NV"/>
