NV_gpu_shader5
Name
NV_gpu_shader5
Name Strings
GL_NV_gpu_shader5
Contact
Pat Brown, NVIDIA Corporation (pbrown 'at' nvidia.com)
Contributors
Barthold Lichtenbelt, NVIDIA
Chris Dodd, NVIDIA
Eric Werness, NVIDIA
Greg Roth, NVIDIA
Jeff Bolz, NVIDIA
Piers Daniell, NVIDIA
Daniel Rakos, AMD
Mathias Heyer, NVIDIA
Status
Shipping.
Version
Last Modified Date: 03/07/2017
NVIDIA Revision: 11
Number
OpenGL Extension #389
OpenGL ES Extension #260
Dependencies
This extension is written against the OpenGL 3.2 (Compatibility Profile)
Specification.
This extension is written against version 1.50 (revision 09) of the OpenGL
Shading Language Specification.
If implemented in OpenGL, OpenGL 3.2 and GLSL 1.50 are required.
If implemented in OpenGL, ARB_gpu_shader5 is required.
This extension interacts with ARB_gpu_shader5.
This extension interacts with ARB_gpu_shader_fp64.
This extension interacts with ARB_tessellation_shader.
This extension interacts with NV_shader_buffer_load.
This extension interacts with EXT_direct_state_access.
This extension interacts with EXT_vertex_attrib_64bit and
NV_vertex_attrib_integer_64bit.
This extension interacts with OpenGL ES 3.1 (dated October 29th 2014).
This extension interacts with OpenGL ES Shading Language 3.1 (revision 3).
If implemented in OpenGL ES, OpenGL ES 3.1 and GLSL ES 3.10 are required.
If implemented in OpenGL ES, OES/EXT_gpu_shader5 and EXT_shader_implicit-
_conversions are required.
This extension interacts with OES/EXT_tessellation_shader
This extension interacts with OES/EXT_geometry_shader
Overview
This extension provides a set of new features to the OpenGL Shading
Language and related APIs to support capabilities of new GPUs. Shaders
using the new functionality provided by this extension should enable this
functionality via the construct
#extension GL_NV_gpu_shader5 : require (or enable)
This extension was developed concurrently with the ARB_gpu_shader5
extension, and provides a superset of the features provided there. The
features common to both extensions are documented in the ARB_gpu_shader5
specification; this document describes only the addition language features
not available via ARB_gpu_shader5. A shader that enables this extension
via an #extension directive also implicitly enables the common
capabilities provided by ARB_gpu_shader5.
In addition to the capabilities of ARB_gpu_shader5, this extension
provides a variety of new features for all shader types, including:
* support for a full set of 8-, 16-, 32-, and 64-bit scalar and vector
data types, including uniform API, uniform buffer object, and shader
input and output support;
* the ability to aggregate samplers into arrays, index these arrays with
arbitrary expressions, and not require that non-constant indices be
uniform across all shader invocations;
* new built-in functions to pack and unpack 64-bit integer types into a
two-component 32-bit integer vector;
* new built-in functions to pack and unpack 32-bit unsigned integer
types into a two-component 16-bit floating-point vector;
* new built-in functions to convert double-precision floating-point
values to or from their 64-bit integer bit encodings;
* new built-in functions to compute the composite of a set of boolean
conditions a group of shader threads;
* vector relational functions supporting comparisons of vectors of 8-,
16-, and 64-bit integer types or 16-bit floating-point types; and
* extending texel offset support to allow loading texel offsets from
regular integer operands computed at run-time, except for lookups with
gradients (textureGrad*).
This extension also provides additional support for processing patch
primitives (introduced by ARB_tessellation_shader).
ARB_tessellation_shader requires the use of a tessellation evaluation
shader when processing patches, which means that patches will never
survive past the tessellation pipeline stage. This extension lifts that
restriction, and allows patches to proceed further in the pipeline and be
used
* as input to a geometry shader, using a new "patches" layout qualifier;
* as input to transform feedback;
* by fixed-function rasterization stages, in which case the patches are
drawn as independent points.
Additionally, it allows geometry shaders to read per-patch attributes
written by a tessellation control shader using input variables declared
with "patch in".
New Procedures and Functions
void Uniform1i64NV(int location, int64EXT x);
void Uniform2i64NV(int location, int64EXT x, int64EXT y);
void Uniform3i64NV(int location, int64EXT x, int64EXT y, int64EXT z);
void Uniform4i64NV(int location, int64EXT x, int64EXT y, int64EXT z,
int64EXT w);
void Uniform1i64vNV(int location, sizei count, const int64EXT *value);
void Uniform2i64vNV(int location, sizei count, const int64EXT *value);
void Uniform3i64vNV(int location, sizei count, const int64EXT *value);
void Uniform4i64vNV(int location, sizei count, const int64EXT *value);
void Uniform1ui64NV(int location, uint64EXT x);
void Uniform2ui64NV(int location, uint64EXT x, uint64EXT y);
void Uniform3ui64NV(int location, uint64EXT x, uint64EXT y, uint64EXT z);
void Uniform4ui64NV(int location, uint64EXT x, uint64EXT y, uint64EXT z,
uint64EXT w);
void Uniform1ui64vNV(int location, sizei count, const uint64EXT *value);
void Uniform2ui64vNV(int location, sizei count, const uint64EXT *value);
void Uniform3ui64vNV(int location, sizei count, const uint64EXT *value);
void Uniform4ui64vNV(int location, sizei count, const uint64EXT *value);
void GetUniformi64vNV(uint program, int location, int64EXT *params);
(The following function is also provided by NV_shader_buffer_load.)
void GetUniformui64vNV(uint program, int location, uint64EXT *params);
(All of the following ProgramUniform* functions are supported if and only
if implemented in OpenGL ES or EXT_direct_state_access is supported.)
void ProgramUniform1i64NV(uint program, int location, int64EXT x);
void ProgramUniform2i64NV(uint program, int location, int64EXT x,
int64EXT y);
void ProgramUniform3i64NV(uint program, int location, int64EXT x,
int64EXT y, int64EXT z);
void ProgramUniform4i64NV(uint program, int location, int64EXT x,
int64EXT y, int64EXT z, int64EXT w);
void ProgramUniform1i64vNV(uint program, int location, sizei count,
const int64EXT *value);
void ProgramUniform2i64vNV(uint program, int location, sizei count,
const int64EXT *value);
void ProgramUniform3i64vNV(uint program, int location, sizei count,
const int64EXT *value);
void ProgramUniform4i64vNV(uint program, int location, sizei count,
const int64EXT *value);
void ProgramUniform1ui64NV(uint program, int location, uint64EXT x);
void ProgramUniform2ui64NV(uint program, int location, uint64EXT x,
uint64EXT y);
void ProgramUniform3ui64NV(uint program, int location, uint64EXT x,
uint64EXT y, uint64EXT z);
void ProgramUniform4ui64NV(uint program, int location, uint64EXT x,
uint64EXT y, uint64EXT z, uint64EXT w);
void ProgramUniform1ui64vNV(uint program, int location, sizei count,
const uint64EXT *value);
void ProgramUniform2ui64vNV(uint program, int location, sizei count,
const uint64EXT *value);
void ProgramUniform3ui64vNV(uint program, int location, sizei count,
const uint64EXT *value);
void ProgramUniform4ui64vNV(uint program, int location, sizei count,
const uint64EXT *value);
New Tokens
Returned by the <type> parameter of GetActiveAttrib, GetActiveUniform, and
GetTransformFeedbackVarying:
INT64_NV 0x140E
UNSIGNED_INT64_NV 0x140F
INT8_NV 0x8FE0
INT8_VEC2_NV 0x8FE1
INT8_VEC3_NV 0x8FE2
INT8_VEC4_NV 0x8FE3
INT16_NV 0x8FE4
INT16_VEC2_NV 0x8FE5
INT16_VEC3_NV 0x8FE6
INT16_VEC4_NV 0x8FE7
INT64_VEC2_NV 0x8FE9
INT64_VEC3_NV 0x8FEA
INT64_VEC4_NV 0x8FEB
UNSIGNED_INT8_NV 0x8FEC
UNSIGNED_INT8_VEC2_NV 0x8FED
UNSIGNED_INT8_VEC3_NV 0x8FEE
UNSIGNED_INT8_VEC4_NV 0x8FEF
UNSIGNED_INT16_NV 0x8FF0
UNSIGNED_INT16_VEC2_NV 0x8FF1
UNSIGNED_INT16_VEC3_NV 0x8FF2
UNSIGNED_INT16_VEC4_NV 0x8FF3
UNSIGNED_INT64_VEC2_NV 0x8FF5
UNSIGNED_INT64_VEC3_NV 0x8FF6
UNSIGNED_INT64_VEC4_NV 0x8FF7
FLOAT16_NV 0x8FF8
FLOAT16_VEC2_NV 0x8FF9
FLOAT16_VEC3_NV 0x8FFA
FLOAT16_VEC4_NV 0x8FFB
(If ARB_tessellation_shader is supported, the following enum is accepted
by a new primitive.)
Accepted by the <primitiveMode> parameter of BeginTransformFeedback:
PATCHES
Additions to Chapter 2 of the OpenGL 3.2 (Compatibility Profile) Specification (OpenGL Operation)
Modify Section 2.6.1, Begin and End, p. 22
(Extend language describing PATCHES introduced by ARB_tessellation_shader.
It particular, add the following to the end of the description of the
primitive type.)
If a patch primitive is drawn, each patch is drawn separately as a
collection of points, which each patch vertex definining a separate point.
Extra vertices from an incomplete patch are never drawn.
Modify Section 2.14.3, Vertex Attributes, p. 86
(modify the second paragraph, p. 87) ... exceeds MAX_VERTEX_ATTRIBS. For
the purposes of this comparison, attribute variables of the type i64vec3,
u64vec3, i64vec4, and u64vec4 count as consuming twice as many attributes
as equivalent single-precision types.
(extend the list of types in the first paragraph, p. 88)
... UNSIGNED_INT_VEC3, UNSIGNED_INT_VEC4, INT8_NV, INT8_VEC2_NV,
INT8_VEC3_NV, INT8_VEC4_NV, INT16_NV, INT16_VEC2_NV, INT16_VEC3_NV,
INT16_VEC4_NV, INT64_NV, INT64_VEC2_NV, INT64_VEC3_NV, INT64_VEC4_NV,
UNSIGNED_INT8_NV, UNSIGNED_INT8_VEC2_NV, UNSIGNED_INT8_VEC3_NV,
UNSIGNED_INT8_VEC4_NV, UNSIGNED_INT16_NV, UNSIGNED_INT16_VEC2_NV,
UNSIGNED_INT16_VEC3_NV, UNSIGNED_INT16_VEC4_NV, UNSIGNED_INT64_NV,
UNSIGNED_INT64_VEC2_NV, UNSIGNED_INT64_VEC3_NV, UNSIGNED_INT64_VEC4_NV,
FLOAT16_NV, FLOAT16_VEC2_NV, FLOAT16_VEC3_NV, or FLOAT16_VEC4_NV.
Modify Section 2.14.4, Uniform Variables, p. 89
(modify third paragraph, p. 90) ... uniform variable storage for a vertex
shader. A scalar or vector uniform with with 64-bit integer components
will consume no more than 2<n> components, where <n> is 1 for scalars, and
the component count for vectors. A link error is generated ...
(add to Table 2.13, p. 96)
Type Name Token Keyword
-------------------- ----------------
INT8_NV int8_t
INT8_VEC2_NV i8vec2
INT8_VEC3_NV i8vec3
INT8_VEC4_NV i8vec4
INT16_NV int16_t
INT16_VEC2_NV i16vec2
INT16_VEC3_NV i16vec3
INT16_VEC4_NV i16vec4
INT64_NV int64_t
INT64_VEC2_NV i64vec2
INT64_VEC3_NV i64vec3
INT64_VEC4_NV i64vec4
UNSIGNED_INT8_NV uint8_t
UNSIGNED_INT8_VEC2_NV u8vec2
UNSIGNED_INT8_VEC3_NV u8vec3
UNSIGNED_INT8_VEC4_NV u8vec4
UNSIGNED_INT16_NV uint16_t
UNSIGNED_INT16_VEC2_NV u16vec2
UNSIGNED_INT16_VEC3_NV u16vec3
UNSIGNED_INT16_VEC4_NV u16vec4
UNSIGNED_INT64_NV uint64_t
UNSIGNED_INT64_VEC2_NV u64vec2
UNSIGNED_INT64_VEC3_NV u64vec3
UNSIGNED_INT64_VEC4_NV u64vec4
FLOAT16_NV float16_t
FLOAT16_VEC2_NV f16vec2
FLOAT16_VEC3_NV f16vec3
FLOAT16_VEC4_NV f16vec4
(modify list of commands at the bottom of p. 99)
void Uniform{1,2,3,4}{i64,ui64}NV(int location, T value);
void Uniform{1,2,3,4}{i64,ui64}vNV(int location, T value);
(insert after fourth paragraph, p. 100) The Uniform*i64{v}NV and
Uniform*ui64{v}NV commands will load <count> sets of one to four 64-bit
signed or unsigned integer values into a uniform location defined as a
64-bit signed or unsigned integer scalar or vector types.
(modify "Uniform Buffer Object Storage", p. 102, adding two bullets after
the last "Members of type", and modifying the subsequent bullet)
* Members of type int8_t, int16_t, and int64_t are extracted from a
buffer object by reading a single byte, short, or int64-typed value at
the specified offset.
* Members of type uint8_t, uint16_t, and uint64_t are extracted from a
buffer object by reading a single ubyte, ushort, or uint64-typed value
at the specified offset.
* Members of type float16_t are extracted from a buffer object by reading
a single half-typed value at the specified offset.
* Vectors with N elements with basic data types of bool, int, uint,
float, double, int8_t, int16_t, int64_t, uint8_t, uint16_t, uint64_t,
or float16_t are extracted as N values in consecutive memory locations
beginning at the specified offset, with components stored in order with
the first (X) component at the lowest offset. The GL data type used for
component extraction is derived according to the rules for scalar
members above.
Modify Section 2.14.6, Varying Variables, p. 106
(modify third paragraph, p. 107) ... For the purposes of counting input
and output components consumed by a shader, variables declared as vectors,
matrices, and arrays will all consume multiple components. Each component
of variables declared as 64-bit integer scalars or vectors, will be
counted as consuming two components.
(add after the bulleted list, p. 108) For the purposes of counting the
total number of components to capture, each component of outputs declared
as 64-bit integer scalars or vectors will be counted as consuming two
components.
Modify Section 2.15.1, Geometry Shader Input Primitives, p. 118
(add new qualifier at the end of the section, p. 120)
Patches (patches)
Geometry shaders that operate on patches are valid for the PATCHES
primitive type. The number of vertices available to each program
invocation is equal to the vertex count of the variable-size patch, with
vertices presented to the geometry shader in the order specified in the
patch.
Modify Section 2.15.4, Geometry Shader Execution Environment, p. 121
(add to the end of "Geometry Shader Inputs", p. 123)
Geometry shaders also support built-in and user-defined per-primitive
inputs. The following built-in inputs, not replicated per-vertex and not
contained in gl_in[], are supported:
* The variable gl_PatchVerticesIn is filled with the number of the
vertices in the input primitive.
* The variables gl_TessLevelOuter[] and gl_TessLevelInner[] are arrays
holding outer and inner tessellation levels of an input patch. If a
tessellation control shader is active, the tessellation levels will be
taken from the corresponding outputs of the tessellation control
shader. Otherwise, the default levels provided as patch parameters
are used. Tessellation level values loaded in these variables will be
prior to the clamping and rounding operations performed by the
primitive generator as described in Section 2.X.2 of
ARB_tessellation_shader. For triangular tessellation,
gl_TessLevelOuter[3] and gl_TessLevelInner[1] will be undefined. For
isoline tessellation, gl_TessLevelOuter[2], gl_TessLevelOuter[3], and
both values in gl_TessLevelInner[] are undefined.
Additionally, a geometry shader with an input primitive type of "patches"
may declare per-patch input variables using the qualifier "patch in".
Unlike per-vertex inputs, per-patch inputs do not correspond to any
specific vertex in the input primitive, and are not indexed by vertex
number. Per-patch inputs declared as arrays have multiple values for the
input patch; similarly declared per-vertex inputs would indicate a single
value for each vertex in the output patch. User-defined per-patch input
variables are filled with corresponding per-patch output values written by
the tessellation control shader. If no tessellation control shader is
active, all such variables are undefined.
Per-patch input variables and the built-in inputs "gl_PatchVerticesIn",
"gl_TessLevelOuter[]", and "gl_TessLevelInner[]" are supported only for
geometry shaders with an input primitive type of "patches". A program
will fail to link if any such variable is used in a geometry shader with a
input primitive type other than "patches".
Modify Section 2.19, Transform Feedback, p. 130
(add to Table 2.14, p. 131)
Transform Feedback
primitiveMode allowed render primitive modes
---------------------- ---------------------------------
PATCHES PATCHES
(modify first paragraph, p. 131) ... <primitiveMode> is one of TRIANGLES,
LINES, POINTS, or PATCHES and specifies the type of primitives that will
be recorded into the buffer objects bound for transform feedback (see
below). ...
(modify last paragraph, p. 131 and first paragraph, p. 132, adding patch
support, and dealing with capture of 8- and 16-bit components)
When an individual point, line, triangle, or patch primitive reaches the
transform feedback stage ... When capturing line, triangle, and patch
primitives, all attributes ... For multi-component varying variables or
varying array elements, the individual components are written in order.
For variables with 8- or 16-bit fixed- or floating-point components,
individual components will be converted to and stored as equivalent values
of type "int", "uint", or "float". The value for any attribute specified
...
(modify next-to-last paragraph, p. 132) ... is not incremented. If
transform feedback receives a primitive that fits in the remaining space
after such an overflow occurs, that primitive may or may not be recorded.
Primitives that fail to fit in the remaining space are never recorded.
Additions to Chapter 3 of the OpenGL 3.2 (Compatibility Profile) Specification (Rasterization)
None.
Additions to Chapter 4 of the OpenGL 3.2 (Compatibility Profile) Specification (Per-Fragment Operations and the Frame Buffer)
None.
Additions to Chapter 5 of the OpenGL 3.2 (Compatibility Profile) Specification (Special Functions)
None.
Additions to Chapter 6 of the OpenGL 3.2 (Compatibility Profile) Specification (State and State Requests)
Modify Section 6.1.15, Shader and Program Queries, p. 332
(add to the first list of commands, p. 337)
void GetUniformi64vNV(uint program, int location, int64EXT *params);
void GetUniformui64vNV(uint program, int location, uint64EXT *params);
Additions to Appendix A of the OpenGL 3.2 (Compatibility Profile) Specification (Invariance)
None.
Additions to the AGL/GLX/WGL Specifications
None.
Modifications to The OpenGL Shading Language Specification, Version 1.50 (Revision 09)
Including the following line in a shader can be used to control the
language features described in this extension:
#extension GL_NV_gpu_shader5 : <behavior>
where <behavior> is as specified in section 3.3.
New preprocessor #defines are added to the OpenGL Shading Language:
#define GL_NV_gpu_shader5 1
If the features of this extension are enabled by an #extension directive,
shading language features documented in the ARB_gpu_shader5 extension will
also be provided.
Modify Section 3.6, Keywords, p. 15
(add the following to the list of reserved keywords)
int8_t i8vec2 i8vec3 i8vec4
int16_t i16vec2 i16vec3 i16vec4
int32_t i32vec2 i32vec3 i32vec4
int64_t i64vec2 i64vec3 i64vec4
uint8_t u8vec2 u8vec3 u8vec4
uint16_t u16vec2 u16vec3 u16vec4
uint32_t u32vec2 u32vec3 u32vec4
uint64_t u64vec2 u64vec3 u64vec4
float16_t f16vec2 f16vec3 f16vec4
float32_t f32vec2 f32vec3 f32vec4
float64_t f64vec2 f64vec3 f64vec4
(note: the "float64_t" and "f64vec*" types are available if and only if
ARB_gpu_shader_fp64 is also supported)
Modify Section 4.1, Basic Types, p. 18
(add to the basic "Transparent Types" table, p. 18)
Types Meaning
-------- ----------------------------------------------------------
int8_t an 8-bit signed integer
i8vec2 a two-component signed integer vector (8-bit components)
i8vec3 a three-component signed integer vector (8-bit components)
i8vec4 a four-component signed integer vector (8-bit components)
int16_t a 16-bit signed integer
i16vec2 a two-component signed integer vector (16-bit components)
i16vec3 a three-component signed integer vector (16-bit components)
i16vec4 a four-component signed integer vector (16-bit components)
int32_t a 32-bit signed integer
i32vec2 a two-component signed integer vector (32-bit components)
i32vec3 a three-component signed integer vector (32-bit components)
i32vec4 a four-component signed integer vector (32-bit components)
int64_t a 64-bit signed integer
i64vec2 a two-component signed integer vector (64-bit components)
i64vec3 a three-component signed integer vector (64-bit components)
i64vec4 a four-component signed integer vector (64-bit components)
uint8_t a 8-bit unsigned integer
u8vec2 a two-component unsigned integer vector (8-bit components)
u8vec3 a three-component unsigned integer vector (8-bit components)
u8vec4 a four-component unsigned integer vector (8-bit components)
uint16_t a 16-bit unsigned integer
u16vec2 a two-component unsigned integer vector (16-bit components)
u16vec3 a three-component unsigned integer vector (16-bit components)
u16vec4 a four-component unsigned integer vector (16-bit components)
uint32_t a 32-bit unsigned integer
u32vec2 a two-component unsigned integer vector (32-bit components)
u32vec3 a three-component unsigned integer vector (32-bit components)
u32vec4 a four-component unsigned integer vector (32-bit components)
uint64_t a 64-bit unsigned integer
u64vec2 a two-component unsigned integer vector (64-bit components)
u64vec3 a three-component unsigned integer vector (64-bit components)
u64vec4 a four-component unsigned integer vector (64-bit components)
float16_t a single 16-bit floating-point value
f16vec2 a two-component floating-point vector (16-bit components)
f16vec3 a three-component floating-point vector (16-bit components)
f16vec4 a four-component floating-point vector (16-bit components)
float32_t a single 32-bit floating-point value
f32vec2 a two-component floating-point vector (32-bit components)
f32vec3 a three-component floating-point vector (32-bit components)
f32vec4 a four-component floating-point vector (32-bit components)
float64_t a single 64-bit floating-point value
f64vec2 a two-component floating-point vector (64-bit components)
f64vec3 a three-component floating-point vector (64-bit components)
f64vec4 a four-component floating-point vector (64-bit components)
Modify Section 4.1.3, Integers, p. 20
(add after the first paragraph of the section, p. 20)
Variables with the types "int8_t", "int16_t", and "int64_t" represent
signed integer values with exactly 8, 16, or 64 bits, respectively.
Variables with the type "uint8_t", "uint16_t", and "uint64_t" represent
unsigned integer values with exactly 8, 16, or 64 bits, respectively.
Variables with the type "int32_t" and "uint32_t" represent signed and
unsigned integer values with 32 bits, and are equivalent to "int" and
"uint" types, respectively.
(modify the grammar, p. 21, adding "L" and "UL" suffixes)
integer-suffix: one of
u U l L ul UL
(modify next-to-last paragraph, p. 21) ... When the suffix "u" or "U" is
present, the literal has type <uint>. When the suffix "l" or "L" is
present, the literal has type <int64_t>. When the suffix "ul" or "UL" is
present, the literal has type <uint64_t>. Otherwise, the type is
<int>. ...
Modify Section 4.1.4, Floats, p. 22
(insert after second paragraph, p. 22)
Variables of type "float16_t" represent floating-point using exactly 16
bits and are stored using the 16-bit floating-point representation
described in the OpenGL Specification. Variables of type "float32_t"
and "float64_t" represent floating-point with 32 or 64 bits, and are
equivalent to "float" and "double" types, respectively.
Modify Section 4.1.7, Samplers, p. 23
(modify 1st paragraph of the section, deleting the restriction requiring
constant indexing of sampler arrays) ... Samplers may aggregated into
arrays within a shader (using square brackets [ ]) and can be indexed with
general integer expressions. The results of accessing a sampler array
with an out-of-bounds index are undefined. ...
(remove the additional restriction added by ARB_gpu_shader5 making a
similar edit requiring uniform indexing across shader invocations for
defined results. NV_gpu_shader5 has no such limitation.)
Modify Section 4.1.10, Implicit Conversions, p. 27
(modify table of implicit conversions)
Can be implicitly
Type of expression converted to
-------------------- -----------------------------------------
int uint, int64_t, uint64_t, float, double(*)
ivec2 uvec2, i64vec2, u64vec2, vec2, dvec2(*)
ivec3 uvec3, i64vec3, u64vec3, vec3, dvec3(*)
ivec4 uvec4, i64vec4, u64vec4, vec4, dvec4(*)
int8_t int16_t int, int64_t, uint, uint64_t, float, double(*)
i8vec2 i16vec2 ivec2, i64vec2, uvec2, u64vec2, vec2, dvec2(*)
i8vec3 i16vec3 ivec3, i64vec3, uvec3, u64vec3, vec3, dvec3(*)
i8vec4 i16vec4 ivec4, i64vec4, uvec4, u64vec4, vec4, dvec4(*)
int64_t uint64_t, double(*)
i64vec2 u64vec2, dvec2(*)
i64vec3 u64vec3, dvec3(*)
i64vec4 u64vec4, dvec4(*)
uint uint64_t, float, double(*)
uvec2 u64vec2, vec2, dvec2(*)
uvec3 u64vec3, vec3, dvec3(*)
uvec4 u64vec4, vec4, dvec4(*)
uint8_t uint16_t uint, uint64_t, float, double(*)
u8vec2 u16vec2 uvec2, u64vec2, vec2, dvec2(*)
u8vec3 i16vec3 uvec3, u64vec3, vec3, dvec3(*)
u8vec4 i16vec4 uvec4, u64vec4, vec4, dvec4(*)
uint64_t double(*)
u64vec2 dvec2(*)
u64vec3 dvec3(*)
u64vec4 dvec4(*)
float double(*)
vec2 dvec2(*)
vec3 dvec3(*)
vec4 dvec4(*)
float16_t float, double(*)
f16vec2 vec2, dvec2(*)
f16vec3 vec3, dvec3(*)
f16vec4 vec4, dvec4(*)
(*) if ARB_gpu_shader_fp64 is supported
(Note: Expressions of type "int32_t", "uint32_t", "float32_t", and
"float64_t" are treated as identical to those of type "int", "uint",
"float", and "double", respectively. Implicit conversions to and from
these explicitly-sized types are allowed whenever conversions involving
the equivalent base type are allowed.)
(modify second paragraph of the section) No implicit conversions are
provided to convert from unsigned to signed integer types, from
floating-point to integer types, from higher-precision to lower-precision
types, from 8-bit to 16-bit types, or between matrix types. There are no
implicit array or structure conversions.
(add before the final paragraph of the section, p. 27)
(insert before the final paragraph of the section) When performing
implicit conversion for binary operators, there may be multiple data types
to which the two operands can be converted. For example, when adding an
int8_t value to a uint16_t value, both values can be implicitly converted
to uint, uint64_t, float, and double. In such cases, a floating-point
type is chosen if either operand has a floating-point type. Otherwise, an
unsigned integer type is chosen if either operand has an unsigned integer
type. Otherwise, a signed integer type is chosen. If operands can be
converted to both 32- and 64-bit versions of the chosen base data type,
the 32-bit version is used.
Modify Section 4.3.4, Inputs, p. 31
(modify third paragraph of section, p. 31, allowing explicitly-sized
types) ... Vertex shader inputs variables can only be signed and unsigned
integers, floats, doubles, explicitly-sized integers and floating-point
values, vectors of any of these types, and matrices. ...
(modify edits done in ARB_tessellation_shader adding support for "patch
in", allowing for geometry shaders as well) Additionally, tessellation
evaluation and geometry shaders support per-patch input variables declared
with the "patch in" qualifier. Per-patch input ...
(modify third paragraph, p. 32) ... Fragment inputs can only be signed and
unsigned integers, floats, doubles, explicitly-sized integers and
floating-point values, vectors of any of these types, matrices, or arrays
or structures of these. Fragment inputs declared as signed or unsigned
integers, doubles, 64-bit floating-point values, including vectors,
matrices, or arrays derived from those types, must be qualified as "flat".
Modify Section 4.3.6, Outputs, p. 33
(modify third paragraph of the section, p. 33) ... They can only be signed
and unsigned integers, floats, doubles, explicitly-sized integers and
floating-point values, vectors of any of these types, matrices, or arrays
or structures of these.
(modify last paragraph, p. 33) ... Fragment outputs can only be signed
and unsigned integers, floats, explicitly-sized integers and
floating-point values with 32 or fewer bits, vectors of any of these
types, or arrays of these. Doubles, 64-bit integers or floating-point
values, vectors or arrays of those types, matrices, and structures cannot
be output. ...
Modify Section 4.3.8.1, Input Layout Qualifiers, p. 37
(add to the list of qualifiers for geometry shaders, p. 37)
layout-qualifier-id:
...
triangles_adjacency
patches
(modify the "size of input arrays" table, p. 38)
Layout Size of Input Arrays
------------ --------------------
patches gl_MaxPatchVertices
(add paragraph below that table, p. 38)
When using the input primitive type "patches", the geometry shader is used
to process a set of patches with vertex counts that may vary from patch to
patch. For the purposes of input array sizing, patches are treated as
having a vertex count fixed at the implementation-dependent maximum patch
size, gl_MaxPatchVertices. If a shader reads an input corresponding to a
vertex not found in the patch being processed, the values read are
undefined.
Modify Section 5.4.1, Conversion and Scalar Constructors, p. 49
(add after first list of constructor examples)
Similar constructors are provided to convert to and from explicitly-sized
scalar data types, as well:
float(uint8_t) // converts an 8-bit uint value to a float
int64_t(double) // converts a double value to a 64-bit int
float64_t(int16_t) // converts a 16-bit int value to a 64-bit float
uint16_t(bool) // converts a Boolean value to a 16-bit uint
(replace final two paragraphs, p. 49, and the first paragraph, p. 50,
using more general language)
When constructors are used to convert any floating-point type to any
integer type, the fractional part of the floating-point value is dropped.
It is undefined to convert a negative floating point value to an unsigned
integer type.
When a constructor is used to convert any integer or floating-point type
to bool, 0 and 0.0 are converted to false, and non-zero values are
converted to true. When a constructor is used to convert a bool to any
integer or floating-point type, false is converted to 0 or 0.0, and true
is converted to 1 or 1.0.
Constructors converting between signed and unsigned integers with the same
bit count always preserve the bit pattern of the input. This will change
the value of the argument if its most significant bit is set, converting a
negative signed integer to a large unsigned integer, or vice versa.
Modify Section 5.9, Expressions, p. 57
(modify bulleted list as follows, adding support for expressions with
64-bit integer types)
Expressions in the shading language are built from the following:
* Constants of type bool, int, int64_t, uint, uint64_t, float, all vector
types, and all matrix types.
...
* The arithmetic binary operators add (+), subtract (-), multiply (*), and
divide (/) operate on 32-bit integer, 64-bit integer, and floating-point
scalars, vectors, and matrices. If the fundamental types of the
operands do not match, the conversions from Section 4.1.10 "Implicit
Conversions" are applied to produce matching types. ...
* The operator modulus (%) operate on 32- and 64-bit integer scalars or
vectors. If the fundamental types of the operands do not match, the
conversions from Section 4.1.10 "Implicit Conversions" are applied to
produce matching types. ...
* The arithmetic unary operators negate (-), post- and pre-increment and
decrement (-- and ++) operate on 32-bit integer, 64-bit integer, and
floating-point values (including vectors and matrices). ...
* The relational operators greater than (>), less than (<), and less than
or equal (<=) operate only on scalar 32-bit integer, 64-bit integer, and
floating-point expressions. The result is scalar Boolean. The
fundamental type of the two operands must match, either as specified, or
after one of the implicit type conversions specified in Section 4.1.10.
...
* The equality operators equal (==), and not equal (!=) operate only on
scalar 32-bit integer, 64-bit integer, and floating-point expressions.
The result is scalar Boolean. The fundamental type of the two operands
must match, either as specified, or after one of the implicit type
conversions specified in Section 4.1.10. ...
Modify Section 6.1, Function Definitions, p. 63
(ARB_gpu_shader5 adds a set of rules for defining whether implicit
conversions for one matching function definition are better or worse than
those for another. These comparisons are done argument by argument.
Extend the edits made by ARB_gpu_shader5 to add several new rules for
comparing implicit conversions for a single argument, corresponding to the
new data types introduced by this extension.)
To determine whether the conversion for a single argument in one match is
better than that for another match, the following rules are applied, in
order:
1. An exact match is better than a match involving any implicit
conversion.
2. A match involving a conversion from a signed integer, unsigned
integer, or floating-point type to a similar type having a larger
number of bits is better a match not involving another conversion.
The set of conversions qualifying under this rule are:
source types destination types
----------------- -----------------
int8_t, int16_t int, int64_t
int int64_t
uint8_t, uint16_t uint, uint64_t
uint uint64_t
float16_t float
float double
3. A match involving one conversion in rule 2 is better than a match
involving another conversion in rule 2 if:
(a) both conversions start with the same type and the first
conversion is to a type with a smaller number of bits (e.g.,
converting from int16_t to int is preferred to converting
int16_t to int64_t), or
(b) both conversions end with the same type and the first
conversion is from a type with a larger number of bits (e.g.,
converting an "out" parameter from int16_t to int is preferred
to convering from int8_t to int).
4. A match involving an implicit conversion from any integer type to
float is better than a match involving an implicit conversion from
any integer type to double.
Modify Section 7.1, Vertex and Geometry Shader Special Variables, p. 69
(NOTE: These edits are written against the re-organized section in the
ARB_tessellation_shader specification.)
(add to the list of built-ins inputs for geometry shaders) In the geometry
language, built-in input and output variables are intrinsically declared
as:
in int gl_PatchVerticesIn;
patch in float gl_TessLevelOuter[4];
patch in float gl_TessLevelInner[2];
...
The input variable gl_PatchVerticesIn behaves as in the identically-named
tessellation control and evaluation shader inputs.
The input variables gl_TessLevelOuter[] and gl_TessLevelInner[] behave as
in the identically-named tessellation evaluation shader inputs.
Modify Chapter 8, Built-in Functions, p. 81
(add to description of generic types, last paragraph of p. 69) ... Where
the input arguments (and corresponding output) can be int64_t, i64vec2,
i64vec3, or i64vec4, <genI64Type> is used as the argument. Where the
input arguments (and corresponding output) can be uint64_t, u64vec2,
u64vec3, or u64vec4, <genU64Type> is used as the argument.
Modify Section 8.3, Common Functions, p. 84
(add support for 64-bit integer packing and unpacking functions)
Syntax:
int64_t packInt2x32(ivec2 v);
uint64_t packUint2x32(uvec2 v);
ivec2 unpackInt2x32(int64_t v);
uvec2 unpackUint2x32(uint64_t v);
The functions packInt2x32() and packUint2x32() return a signed or unsigned
64-bit integer obtained by packing the components of a two-component
signed or unsigned integer vector, respectively. The first vector
component specifies the 32 least significant bits; the second component
specifies the 32 most significant bits.
The functions unpackInt2x32() and unpackUint2x32() return a signed or
unsigned integer vector built from a 64-bit signed or unsigned integer
scalar, respectively. The first component of the vector contains the 32
least significant bits of the input; the second component consists the 32
most significant bits.
(add support for 16-bit floating-point packing and unpacking functions)
Syntax:
uint packFloat2x16(f16vec2 v);
f16vec2 unpackFloat2x16(uint v);
The function packFloat2x16() returns an unsigned integer obtained by
interpreting the components of a two-component 16-bit floating-point
vector as integers according to OpenGL Specification, and then packing the
two 16-bit integers into a 32-bit unsigned integer. The first vector
component specifies the 16 least significant bits of the result; the
second component specifies the 16 most significant bits.
The function unpackFloat2x16() returns a two-component vector with 16-bit
floating-point components obtained by unpacking a 32-bit unsigned integer
into a pair of 16-bit values, and interpreting those values as 16-bit
floating-point numbers according to the OpenGL Specification. The first
component of the vector is obtained from the 16 least significant bits of
the input; the second component is obtained from the 16 most significant
bits.
(add functions to get/set the bit encoding for floating-point values)
64-bit floating-point data types in the OpenGL shading language are
specified to be encoded according to the IEEE specification for
double-precision floating-point values. The functions below allow shaders
to convert double-precision floating-point values to and from 64-bit
signed or unsigned integers representing their encoding.
To obtain signed or unsigned integer values holding the encoding of a
floating-point value, use:
genI64Type doubleBitsToInt64(genDType value);
genU64Type doubleBitsToUint64(genDType value);
Conversions are done on a component-by-component basis.
To obtain a floating-point value corresponding to a signed or unsigned
integer encoding, use:
genDType int64BitsToDouble(genI64Type value);
genDType uint64BitsToDouble(genU64Type value);
(add functions to evaluate predicates over groups of threads)
Syntax:
bool anyThreadNV(bool value);
bool allThreadsNV(bool value);
bool allThreadsEqualNV(bool value);
Implementations of the OpenGL Shading Language may, but are not required,
to run multiple shader threads for a single stage as a SIMD thread group,
where individual execution threads are assigned to thread groups in an
undefined, implementation-dependent order. Algorithms may benefit from
being able to evaluate a composite of boolean values over all active
threads in the thread group.
The function anyThreadNV() returns true if and only if <value> is true for
at least one active thread in the group. The function allThreadsNV()
returns true if and only if <value> is true for all active threads in the
group. The function allThreadsEqualNV() returns true if <value> is the
same for all active threads in the group; the result of
allThreadsEqualNV() will be true if and only if anyThreadNV() and
allThreadsNV() would return the same value.
Since these functions depends on the values of <value> in an undefined
group of threads, the value returned by these functions is largely
undefined. However, anyThreadNV() is guaranteed to return true if <value>
is true, and allThreadsNV() is guaranteed to return false if <value> is
false.
Since implementations are generally not required to combine threads into
groups, simply returning <value> for anyThreadNV() and allThreadsNV() and
returning true for allThreadsEqualNV() is a legal implementation of these
functions.
Modify Section 8.6, Vector Relational Functions, p. 90
(modify the first paragraph, p. 90, adding support for relational
functions operating on explicitly-sized types)
Relational and equality operators (<, <=, >, >=, ==, !=) are defined (or
reserved) to operate on scalars and produce scalar Boolean results. For
vector results, use the following built-in functions. In the definitions
below, the following terms are used as placeholders for all vector types
for a given fundamental data type:
placeholder fundamental types
----------- ------------------------------------------------
bvec bvec2, bvec3, bvec4
ivec ivec2, ivec3, ivec4, i8vec2, i8vec3, i8vec4,
i16vec2, i16vec3, i16vec4, i64vec2, i64vec3, i64vec4
uvec uvec2, uvec3, uvec4, u8vec2, u8vec3, u8vec4,
u16vec2, u16vec3, u16vec4, u64vec2, u64vec3, u64vec4
vec vec2, vec3, vec4, dvec2(*), dvec3(*), dvec4(*),
f16vec2, f16vec3, f16vec4
(*) only if ARB_gpu_shader_fp64 is supported
In all cases, the sizes of the input and return vectors for any
particular call must match.
Modify Section 8.7, Texture Lookup Functions, p. 91
(modify text for textureOffset() functions, p. 94, allowing non-constant
offsets)
Do a texture lookup as in texture but with offset added to the (u,v,w)
texel coordinates before looking up each texel. The value <offset> need
not be constant; however, a limited range of offset values are supported.
If any component of <offset> is less than MIN_PROGRAM_TEXEL_OFFSET_EXT or
greater than MAX_PROGRAM_TEXEL_OFFSET_EXT, the offset applied to the
texture coordinates is undefined. Note that offset does not apply to the
layer coordinate for texture arrays. This is explained in detail in
section 3.9.9 of the OpenGL Specification (Version 3.2, Compatibility
Profile), where offset is (delta_u, delta_v, delta_w). Note that texel
offsets are also not supported for cube maps.
(Note: This lifting of the constant offset restriction also applies to
texelFetchOffset, p. 95, textureProjOffset, p. 95, textureLodOffset,
p. 96, textureProjLodOffset, p. 96.)
(modify the description of the textureGradOffset() functions, p. 97,
preserving the restriction on constant offsets)
Do a texture lookup with both explicit gradient and offset, as described
in textureGrad and textureOffset. For these functions, the offset value
must be a constant expression. A limited range of offset values are
supported; the minimum and maximum offset values are
implementation-dependent and given by MIN_PROGRAM_TEXEL_OFFSET and
MAX_PROGRAM_TEXEL_OFFSET, respectively.
(modify the description of the textureProjGradOffset() functions,
p. 98, preserving the restriction on constant offsets)
Do a texture lookup projectively and with explicit gradient as described
in textureProjGrad, as well as with offset, as described in textureOffset.
For these functions, the offset value must be a constant expression. A
limited range of offset values are supported; the minimum and maximum
offset values are implementation-dependent and given by
MIN_PROGRAM_TEXEL_OFFSET and MAX_PROGRAM_TEXEL_OFFSET, respectively.
(modify the description of the textureGatherOffsets() functions,
added in ARB_gpu_shader5, to remove the restriction on constant offsets)
The textureGatherOffsets() functions operate identically ...
selecting the texel T_i0_j0 of that footprint. The specified values in
<offsets> need not be constant. A limited range of ...
Modify Section 9, Shading Language Grammar, p. 92
!!! TBD !!!
GLX Protocol
TBD
Interactions with OpenGL ES 3.1
If implemented in OpenGL ES, NV_gpu_shader5 acts as a superset
of functionality provided by OES_gpu_shader5.
A shader that enables this extension
via an #extension directive also implicitly enables the common
capabilities provided by OES_gpu_shader5.
Replace references to ARB_gpu_shader5 with OES_gpu_shader5 and
EXT_shader_implicit_conversions (as appropriate).
Replace references to ARB_geometry_shader with OES/EXT_geometry_shader.
Replace references to ARB_tessellation_shader with OES/EXT_tessellation_shader.
Replace references to int64EXT and uint64EXT with int64 and uint64,
respectively.
The specification should be edited as follows to include new
ProgramUniform* functions.
(modify the ProgramUniform* language)
The following commands:
....
void ProgramUniform{1,2,3,4}{i64,ui64}NV
(uint program int location, T value);
void ProgramUniform{1,2,3,4}{i64,ui64}vNV
(uint program, int location, const T *value);
operate identically to the corresponding command where "Program" is
deleted from the name (and extension suffixes are dropped or updated
appropriately) except, rather than updating the currently active program
object, these "Program" commands update the program object named by the
<program> parameter. ...
Changes to Section 2.6.1 "Begin and End" don't apply.
Disregard introduction of 64bit -integer or -floating point vertex
attribute types.
Interactions with OpenGL ES Shading Language 3.10, revision 3
If implemented in GLSL ES, NV_gpu_shader5 acts as a superset
of functionality provided by OES_gpu_shader5 and
EXT_shader_implicit_conversions.
A shader that enables this extension via an #extension directive
also implicitly enables the common capabilities provided by
OES_gpu_shader5 and EXT_shader_implicit_conversions.
Replace references to ARB_tessellation_shader with OES/EXT_tessellation_shader.
Implicit conversion between GLSL ES types are introduced by
EXT_shader_implicit_conversions instead of ARB_gpu_shader5.
Disregard the notion of 'double' types as vertex shader inputs.
Section 4.1.7.2 "Images"
Remove the third sentence restricts
access to arrays of images to constant integral expression.
This essentially leaves it to the 'dynamically uniform integral
expressions' default as OES_gpu_shader5 introduced.
Modify Section 4.3.9 "Interface Blocks", as modified OES_gpu_shader5
NV_gpu_shader5 also lifts OES_gpu_shader5 restrictions with
regard to indexing into arrays of uniforms blocks and shader
storage blocks.
Change sentence
"All indices used to index a shader storage block array must be
constant integral expressions. A uniform block array can only
be indexed with a dynamically uniform integral expression,
otherwise results are undefined." into
"Arbitrary indices may be used to index a uniform block array;
integral constant expressions are not required. If the index
used to access an array of uniform blocks is out-of-bounds,
the results of the access are undefined."
Indexing into arrays of shader storage blocks defaults to
'dynamically uniform integral expressions'.
Changes to Section 4.3.9, p.48 "Interface Blocks"
Replace the sentence
"All indices used to index a shader storage block array must be
constant integral expressions. A uniform block array can only
be indexed with a dynamically uniform integral expression,
otherwise results are undefined."
with
"Arbitrary indices may be used to index a uniform block array;
integral constant expressions are not required. If the index
used to access an array of uniform blocks is out-of-bounds, the
results of the access are undefined."
4.4.1.1 "Compute Shader Inputs" change
"layout-qualifier-id:
local_size_x = integer-constant
local_size_y = integer-constant
local_size_z = integer-constant" into
"layout-qualifier-id:
local_size_x = integer-constant-expression
local_size_y = integer-constant-expression
local_size_z = integer-constant-expression"
Section 4.4.1.gs "Geometry Shader Inputs" change
"<layout-qualifier-id>
...
invocations = integer-constant" into
"<layout-qualifier-id>
...
invocations = integer-constant-expression"
Section 4.4.2 "Output Layout Qualifiers" change
"layout-qualifier-id:
location = integer-constant" into
"layout-qualifier-id:
location = integer-constant-expression"
Section 4.4.2.ts "Tessellation Control Outputs" change
"layout-qualifier-id
vertices = integer-constant" into
"layout-qualifier-id:
vertices = integer-constant-expression"
Section 4.4.3 "Uniform Variable Layout Qualifiers" change
"layout-qualifier-id:
location = integer-constant" into
"layout-qualifier-id:
location = integer-constant-expression"
Section 4.4.4 "Uniform and Shader Storage Block Layout Qualifiers" change
"layout-qualifier-id:
...
binding = integer-constant" into
"layout-qualifier-id:
...
binding = integer-constant-expression"
Section 4.4.5 "Opaque Uniform Layout Qualifiers" change
"layout-qualifier-id:
binding = integer-constant" into
"layout-qualifier-id:
binding = integer-constant-expression"
Change sentence
"A link-time error will result if two shaders in a program
specify different integer-constant bindings for the same
opaque-uniform name." into
"A link-time error will result if two shaders in a program
specify different bindings for the same opaque-uniform
name."
Section 4.4.6 "Atomic Counter Layout Qualifiers" change
"layout-qualifier-id:
binding = integer-constant
offset = integer-constant" into
"layout-qualifier-id:
binding = integer-constant-expression
offset = integer-constant-expression"
Section 4.4.7 "Format Layout Qualifiers" change
"layout-qualifier-id:
...
binding = integer-constant" into
"layout-qualifier-id:
...
binding = integer-constant-expression"
Section 4.7.3 "Precision Qualifiers"
After "Literal constants do not have precision qualifiers." add
"Neither do explicitly sized types such as int8_t, uint32_t,
float16_t etc."
Dependencies on OES_gpu_shader5
In addition to allowing arbitrary indexing arrays of samplers, this
extension also lifts OES_gpu_shader5 restrictions for indexing
arrays of images and shader storage blocks. Additionally, it allows
usage of 'integer-constant-expressions' for layout qualifiers that
formerly took 'integer-constant'.
In Section 'Overview': change the bullet point
"* the ability to aggregate samplers into arrays...."
to
"* the ability to index into arrays of samplers, uniforms and shader
storage blocks with arbitrary expressions, and not require that
non-constant indices be uniform across all shader invocations."
"* the ability to index into arrays of images using dynamically
uniform integers."
"* the ability to use 'integer-constant-expressions' in place of
'integer-constant' for layout qualifiers."
Dependencies on OES/EXT_tessellation_shader and OpenGL ES 3.2
If implemented in OpenGL ES 3.1 or earlier and
OES/EXT_tessellation_shader is not supported, language introduced by
this extension describing processing patches in geometry shaders,
transform feedback, and rasterization should be removed.
If implemented in OpenGL ES 3.2 or implemented in
OpenGL ES 3.1 and OES/EXT_tessellation_shader is supported:
It is legal to send patches past the tessellation stage -- the
following language from OES/EXT_tessellation_shader is removed:
Patch primitives are not supported by pipeline stages below the
tessellation evaluation shader.
It is legal to use a tessellation control shader without a tessellation
evaluation shader.
Remove from the bullet list describing reasons for link failure below the
LinkProgram command on p. 70 (as modified by OES/EXT_tessellation_shader):
* the program is not separable and contains no object to form a
tessellation evaluation shader; or
Modify section 11.1.2.1, "Output Variables" on p. 262 (as modified
by the OES/EXT_geometry_shader extension):
Into the paragraph starting with
"Each program object can specify a set of output variables from one
shader to be recorded in transform feedback mode..."
Insert after the tesselation evaluation shader bullet point:
* tesselation control shader
Modify section 11.1.3.11, "Validation" to replace the bullet point
starting with "One but not both of the tessellation..." on p. 271
* the tessellation evaluation but not tessellation control stage
has an active program with corresponding executable shader.
Modify section 11.1ts, "Tessellation"
Replace
"Tessellation is considered active if and only if the active
program object or program pipeline object includes both a
tessellation control shader and a tessellation evaluation shader."
with
"Tessellation is considered active if and only if the active
program object or program pipeline object includes a tessellation
control shader."
Replace
"An INVALID_OPERATION error is generated by any command that
transfers vertices to the GL if the current program state has one
but not both of a tessellation control shader and tessellation
evaluation shader."
with
"An INVALID_OPERATION error is generated by any command that
transfers vertices to the GL if the current program state has a
tessellation evaluation shader but not a tessellation control
shader."
Modify section 12.1.2 "Transform Feedback Primitive Capture"
Replace the second paragraph of the section on p. 274 (as modified
by OES/EXT_tessellation_shader):
The data captured in transform feedback mode depends on the active
programs on each of the shader stages. If a program is active for the
geometry shader stage, transform feedback captures the vertices of each
primitive emitted by the geometry shader. Otherwise, if a program is
active for the tessellation evaluation shader stage, transform feedback
captures each primitive produced by the tessellation primitive generator,
whose vertices are processed by the tessellation evaluation shader.
Otherwise, if a program is active for the tessellation control shader stage,
transform feedback captures each output patch of that stage.
Otherwise, transform feedback captures each primitive processed by the
vertex shader.
Modify the second paragraph following ResumeTransformFeedback on p. 277
(as modified by OES/EXT_tessellation_shader):
When transform feedback is active and not paused ... If a tessellation
or geometry shader is active, the type of primitive emitted
by that shader is used instead of the <mode> parameter passed to drawing
commands for the purposes of this error check. If tessellation
and geometry shaders are both active, the output primitive
type of the geometry shader will be used for the purposes of this error.
Any primitive type may be used while transform feedback is paused.
Modify section 13.3, "Points"
After
"The point size is determined by the last active stage before the
rasterizer:"
Add a new bullet point to the list, between the
tessellation evaluation shader and the vertex shader:
* the tessellation control shader, if active and no tessellation
evaluation shader is active;
Dependencies on OES/EXT_geometry_shader
If implemented in GLSL ES and OES/EXT_geometry_shader is not supported,
disregard all changes to geometry shader related functionality.
Dependencies on ARB_gpu_shader5
This extension also incorporates all the changes to the OpenGL Shading
Language made by ARB_gpu_shader5; enabling this extension by a #extension
directive in shader code also enables all features of ARB_gpu_shader5 as
though the shader code has also declared
#extension GL_ARB_gpu_shader5 : enable
The converse is not true; implementations supporting both extensions
should not provide the shading language features in this extension if
shader code #extension directives enable only ARB_gpu_shader5.
This specification and ARB_gpu_shader5 both lift the restriction in GLSL
1.50 requiring that indexing in arrays of samplers must be done with
constant expressions. However, ARB_gpu_shader5 specifies that results are
undefined if the indices would diverge if multiple shader invocations are
run in lockstep. This extension does not impose the non-divergent
indexing requirement.
Dependencies on ARB_gpu_shader_fp64
This extension and ARB_gpu_shader_fp64 both provide support for shading
language variables with 64-bit components. If both extensions are
supported, the various edits describing this new support should be
combined.
If ARB_gpu_shader_fp64 is not supported, the following edits should be
removed:
* language adding the data types "float64_t", "f64vec2", "f64vec3", and
"f64vec4";
* language allowing implicit conversions of various types to double,
dvec2, dvec3, or dvec4; and
* the built-in functions doubleBitsToInt64(), doubleBitsToUint64(),
int64BitsToDouble(), and uint64BitsToDouble().
Dependencies on ARB_tessellation_shader
If ARB_tessellation_shader is not supported, language introduced by this
extension describing processing patches in geometry shaders, transform
feedback, and rasterization should be removed.
If this extension and ARB_tessellation_shader are supported, it is legal
to send patches past the tessellation stage -- the following language from
ARB_tessellation_shader is removed:
Patch primitives are not supported by pipeline stages below the
tessellation evaluation shader. If there is no active program object or
the active program object does not contain a tessellation evaluation
shader, the error INVALID_OPERATION is generated by Begin (or vertex
array commands that implicitly call Begin) if the primitive mode is
PATCHES.
Dependencies on NV_shader_buffer_load
If NV_shader_buffer_load is supported, that specification should be edited
as follows, to allow pointers to dereference the new data types added by
this extension.
Modify "Section 2.20.X, Shader Memory Access" from NV_shader_buffer_load.
(add rules for loads of variables having the new data types from this
extension to the list of bullets following "When a shader dereferences a
pointer variable")
- Data of type "int8_t," "int16_t", "int32_t", and "int64_t" are read
from or written to memory as a single 8-, 16-, 32-, or 64-bit signed
integer value at the specified GPU address.
- Data of type "uint8_t," "uint16_t", "uint32_t", and "uint64_t" are read
from or written to memory as a single 8-, 16-, 32-, or 64-bit unsigned
integer value at the specified GPU address.
- Data of type "float16_t", "float32_t", and "float64_t" are read from or
written to memory as a single 16-, 32-, or 64-bit floating-point value
at the specified GPU address.
Dependencies on EXT_direct_state_access
If EXT_direct_state_access is supported, that specification should be
edited as follows to include new ProgramUniform* functions.
(modify the ProgramUniform* language)
The following commands:
....
void ProgramUniform{1,2,3,4}{i64,ui64}NV
(uint program int location, T value);
void ProgramUniform{1,2,3,4}{i64,ui64}vNV
(uint program, int location, const T *value);
operate identically to the corresponding command where "Program" is
deleted from the name (and extension suffixes are dropped or updated
appropriately) except, rather than updating the currently active program
object, these "Program" commands update the program object named by the
<program> parameter. ...
Dependencies on EXT_vertex_attrib_64bit and NV_vertex_attrib_integer_64bit
The EXT_vertex_attrib_64bit extension provides the ability to specify
64-bit floating-point vertex attributes in a GLSL vertex shader and the
specify the values of these attributes via the OpenGL API. To
successfully compile vertex shaders with fp64 input variables, is
necessary to include
#extension GL_EXT_vertex_attrib_64bit : enable
in the shader text.
However, this extension is considered to enable 64-bit
floating-point and integer inputs. Provided EXT_vertex_attrib_64bit
and NV_vertex_attrib_integer_64bit are supported, including the
following code in a vertex shader
#extension GL_NV_gpu_shader5 : enable
will enable 64-bit floating-point or integer input variables whose
values would be specified using the OpenGL API mechanisms found in
the EXT_vertex_attrib_64bit and NV_vertex_attrib_integer_64bit
extensions.
Errors
None.
New State
None.
New Implementation Dependent State
None.
Issues
(1) What implicit conversions are supported by this extension on top of
those provided by related extensions?
RESOLVED: ARB_gpu_shader5 and ARB_gpu_shader_fp64 provide new implicit
conversions from "int" to "uint", and from "int", "uint", and "float" to
"double".
This extension provides integer types of multiple sizes and supports
implicit conversions from small integer types to 32- or 64-bit integer
types of the same signedness, as well as float and double. It also
provides floating-point types of multiple sizes and supports implicit
conversions from smaller to larger types. Additionally, it supports
conversion from 64-bit integer types to double.
(2) How do these implicit conversions impact binary operators?
RESOLVED: For binary operators, we prefer converting to a common type
that is as close as possible in size and type to the original
expression.
(3) How do these implicit conversions impact function overloading rules?
RESOLVED: We extend the preference rules in ARB_gpu_shader5 to account
for the new data types, adding rules to:
* favor new "promotions" in integer/floating point types (previously,
the only promotion was float-to-double)
* for promotions, favor conversion to the type closer in size (e.g.,
prefer converting from int16_t to int over converting to int64_t)
(4) What should be done to distinguish between 32- and 64-bit integer
constants?
RESOLVED: We will use "L" and "UL" to identify signed and unsigned
64-bit integer constants; the use of "L" matches a similar ("long")
suffix in the C programming language. C leaves the size of integer
types implementation-dependent, and many implementations require an "LL"
suffix to declare 64-bit integer constants. With our size definitions,
"L" will be considered sufficient to make an integer constant 64-bit.
(5) Should provide support for vertex attributes with 64-bit components,
and if so, how should the support be provided in the OpenGL API?
RESOLVED: Yes, this seems like useful functionality, particularly for
applications wanting to provide double-precision or 64-bit integer data
to shaders performing computations on such types. We provide
VertexAttribL* entry points for 64-bit components in the separate
EXT_vertex_attrib_64bit and NV_vertex_attrib_64bit extensions, which
should be supported on all implementations supporting this extension.
(6) Should we allow vertex attributes with 8- or 16-bit components in the
shading language, and if so, how does it interact with the OpenGL API?
RESOLVED: Yes, but we will use existing APIs to specify such
attributes, which already typically allow 8- and 16-bit components on
the API side. Vertex attribute components (other than 64-bit ones)
specified by the API will be converted from the type specified in the
vertex attribute commands to the component type of the attribute. For
floating-point values, that may involve 16-to-32 bit conversion or vice
versa. For integer types, that may involve dropping all but the least
significant bits of attribute components.
(7) Should we support uniforms with double or 64-bit attribute types, and
if so, how? Should we support uniforms with <32-bit components, and
if so, how?
RESOLVED: We will support uniforms of all component types, either in a
buffer object (via OpenGL 3.1 or ARB_uniform_buffer_object) or in
storage associated with the program.
When uniforms are stored in buffer object, they are stored using their
native data types according to the pre-existing packing and layout
rules. Those rules were already written to be able to accommodate both
the larger and smaller new data types.
Uniforms stored in program objects are loaded with Uniform* APIs. There
are no pre-existing uniform APIs accepting doubles or other "long"
types, so there was no clear need to add an extra "L" to the name to
distinguish from other APIs like we do with VertexAttribL* APIs.
Uniforms with 8- and 16- bit components are loaded with the "larger"
Uniform*{i,ui,f} APIs; it didn't seem worth it to add numerous entry
points to the APIs to handle all those new types.
(8) How do the uniform loading commands introduced by this extension
interact similar commands added by NV_shader_buffer_load?
RESOLVED: NV_shader_buffer_load provided the command Uniformui64NV to
load pointer uniforms with a single 64-bit unsigned integer. This
extension provides vectors of 64-bit unsigned integers, so we needed
Uniform{2,3,4}ui64NV commands. We chose to provide a Uniform1ui64NV
command, which will be functionally equivalent to Uniformui64NV.
(9) How will transform feedback work for capturing variables with double
or 64-bit components? Should we support transform feedback on
variables with components with fewer than 32 bits?
RESOLVED: Transform feedback will support variables with any component
size. Components with fewer than 32-bits are converted to their
equivalent 32-bit types.
For doubles and variables with 64-bit components, each component
captured will count as 64-bit values and occupy two components for the
purpose of component counting rules. This could be a problem for the
SEPARATE_ATTRIBS mode, since the minimum component limit is four, which
would not be sufficient to capture a dvec3 or dvec4. However,
implementations supporting this extension should also be able to support
ARB_transform_feedback3, which extends INTERLEAVED_ATTRIBS mode to
capture vertex attribute values interleaved into multiple buffers. That
functionality effectively obsoletes the SEPARATE_ATTRIBS mode, since it
is a functional superset.
We considered support for capturing 8- and 16-bit values directly, which
had a number of problems. First, full byte addressing might impose both
alignment issues (e.g., capturing a uint8_t followed by a float might
misalign the float) and additional hardware implementation burdens. One
other option would be to pack multiple values into a 32-bit integer
(e.g., f16vec2 would be packed with .x in the LSBs and .y in the MSBs).
This could work, even with word addressing, but would require padding
for odd sizes (e.g., f16vec2 padded to two words, with the second word
holding only .z). It would also have endianness issues; packed values
would look like arrays of the corresponding smaller type on
little-endian systems, but not on big-endian ones.
(10) What precision will be used for computation, storage, and inter-stage
transfer of 8- and 16-bit component data types?
RESOLVED: The components may be considered to occupy a full 32 bits for
the purposes of input/output component count limits. 8- and 16-bit
values should, however, be passed at that precision.
(11) Is the new support for non-constant texel offsets completely
orthogonal?
RESOLVED: No. Non-constant offsets are not supported for the existing
functions textureGradOffset() and textureProjGradOffset().
(12) Should we provide functions like intBitsToFloat() that operate on
16-bit floating-point values?
RESOLVED: Not in this extension. Such conversions can be performed
using the following code:
uint16_t float16BitsToUint16(float16_t v)
{
return uint16_t(packFloat2x16(f16vec2(v, 0));
}
float16_t uint16BitsToFloat16(uint16_t v)
{
return unpackFloat2x16(uint(v)).x;
}
(13) Should we provide distinct sized types for 32-bit integers and
floats, and 64-bit floats? Should we provide those types as aliases
for existing unsized types? Or should we provide no such types at
all?
RESOLVED: We will provide sized versions of these types, which are
defined as completely equivalent to unsized types according to the
following table:
unsized type sized types
------------- ---------------
int int32_t
uint uint32_t
float float32_t
double float64_t
Vector types with sized and unsized components have equivalent
relationships.
Note that the nominally "unsized" data types in the GLSL 1.30 spec are
actually sized. The specification explicitly defines signed and unsized
integers (int, uint) to be 32-bit values. It also defines
floating-point values to "match the IEEE single precision floating-point
definition for precision and dynamic range", which are also 32-bit
values.
This type equivalence has minor implications on function overloading:
* You can't declare separate versions of a function with an "int"
argument in one version and an "int32_t" argument in another.
* Because there is no implicit conversion between equivalent types, we
will get an exact match if an argument is declared with one type
(e.g., "int") in the caller and a textually different but equivalent
type ("int32_t") in the function.
Note that the type equivalence also applies to API data type queries.
For example, the type INT will be returned for a variable declared as
"int32_t".
(14) What are functions like anyThreadNV() and allThreadsNV() good for?
NRESOLVED: If an implementation performs SIMD thread execution,
divergent branching may result in reduced performance if the "if" and
"else" blocks of an "if" statement are executed sequentially. For
example, an algorithm may have both a "fast path" that performs a
computation quickly for a subset of all cases and a "fast path" that
performs a computation quickly but correctly. When performing SIMD
execution, code like the following:
if (condition) {
result = do_fast_path(...);
} else {
result = do_slow_path(...);
}
may end up executing *both* the fast and slow paths for a SIMD thread
group if <condition> diverges, and may execute more slowly than simply
executing the slow path unconditionally. These functions allow code
like:
if (allThreadsNV(condition)) {
result = do_fast_path(...);
} else {
result = do_slow_path(...);
}
that executes the fast path if and only if it can be used for *all*
threads in the group. For thread groups where <condition> diverges,
this algorithm would unconditionally run the slow path, but would never
run both in sequence.
There may be other cases where "voting" across shader invocations may be
useful. Note that we provide no control over how shader invocations may
be packed within a SIMD thread group, unlike various "compute" APIs
(CUDA, OpenCL).
(15) Can the 64-bit uniform APIs be used to load values for uniforms of
type "bool", "bvec2", "bvec3", or "bvec4"?
RESOLVED: No. OpenGL 2.0 and beyond did allow "bool" variable to be
set with Uniform*i* and Uniform*f APIs, and OpenGL 3.0 extended that
support to Uniform*ui* for orthogonality. But it seems pointless to
extended this capability forward to 64-bit Uniform APIs as well.
(19) The ARB_tessellation_shader extension adds support for patch
primitives that might survive to the transform feedback stage. How
are such primitives captured?
RESOLVED: If patch primitives survive to the transform feedback stage,
they are recorded on a patch-by-patch basis. Incomplete patches are not
recorded. As with other primitive types, if the transform feedback
buffers do not contain enough space to capture an entire patch, no
vertices are recorded.
Note that the only way to get patch primitives all the way to transform
feedback is to have tessellation evaluation and geometry shaders
disabled; the output streams from both of those shader stages are
collections of points, lines, or triangles.
(20) Previous transform feedback allowed capturing only fixed-size
primitives; this extension supports variable-sized patches. What
interactions does this functionality have with transform feedback
buffer overflow?
RESOLVED: With fixed-size point, line, or triangle primitives, once any
primitive fails to be recorded due to insufficient space, all subsequent
primitives would also fail. With variable-size patch primitives, the
transform feedback stage might first receive a large patch that doesn't
fit, followed by a smaller patch that could squeeze into the remaining
space.
To allow for different types of implementation of this extension without
requiring special-case handling of this corner case, we've chosen to
leave this behavior undefined -- the smaller patch may or may not be
recorded.
Revision History
Rev. Date Author Changes
---- -------- -------- -----------------------------------------
11 03/07/17 mheyer Update OpenGL ES interactions to clarify
that using a tessellation control shader
without a tessellation evaluation shader
is legal, and PATCHES can be sent past the
tessellation stage.
10 04/16/16 mheyer Add OpenGL ES interactions (written before
revision 9, but not published)
9 02/19/16 pbrown Clarify that non-constant offset vectors are
supported in textureGatherOffsets().
8 09/11/14 pbrown Fix incorrect implicit conversions, which
follow the general pattern of little->big
and int->uint->float. Thanks to Daniel
Rakos, author of similar functionality in
the AMD_gpu_shader_int64 spec.
7 11/08/10 pbrown Fix typos in description of packFloat2x16 and
unpackFloat2x16.
6 03/23/10 pbrown Update overview, dependencies, remove references
to old extension names. Extend the function
overloading prioritization rules from
ARB_gpu_shader5 to account for new data types.
Major overhaul of the issues section to match
the refactoring done to produce ARB specs.
5 03/08/10 pbrown Add interaction with EXT_vertex_attrib_64bit and
NV_vertex_attrib_integer_64bit; enabling this
extension automatically enables 64-bit floating-
point and integer vertex inputs.
4 03/01/10 pbrown Fix prototype for GetUniformui64vNV.
3 01/14/10 pbrown Fix with updated enum assignments.
2 12/08/09 pbrown Add explicit component counting rules for
64-bit integer attributes similar to those
in the ARB_gpu_shader_fp64 spec.
1 pbrown Internal revisions.