| 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. |
