| Name |
| |
| ARB_vertex_attrib_64bit |
| |
| Name Strings |
| |
| GL_ARB_vertex_attrib_64bit |
| |
| Contact |
| |
| Graham Sellers, AMD (graham.sellers 'at' amd.com) |
| Pat Brown, NVIDIA (pbrown 'at' nvidia.com) |
| Piers Daniell, NVIDIA (pdaniell 'at' nvidia.com) |
| |
| Contributors |
| |
| Barthold Lichtenbelt, NVIDIA |
| Bill Licea-Kane, AMD |
| Eric Werness, NVIDIA |
| Graham Sellers, AMD |
| Greg Roth, NVIDIA |
| Jeff Bolz, NVIDIA |
| Nick Haemel, AMD |
| Pierre Boudier, AMD |
| Piers Daniell, NVIDIA |
| |
| Notice |
| |
| Copyright (c) 2010-2013 The Khronos Group Inc. Copyright terms at |
| http://www.khronos.org/registry/speccopyright.html |
| |
| Specification Update Policy |
| |
| Khronos-approved extension specifications are updated in response to |
| issues and bugs prioritized by the Khronos OpenGL Working Group. For |
| extensions which have been promoted to a core Specification, fixes will |
| first appear in the latest version of that core Specification, and will |
| eventually be backported to the extension document. This policy is |
| described in more detail at |
| https://www.khronos.org/registry/OpenGL/docs/update_policy.php |
| |
| Status |
| |
| Complete. Approved by the ARB on June 9, 2010. |
| Approved by the Khronos Board of Promoters on July 23, 2010. |
| |
| Version |
| |
| Last Modified Date: June 10, 2014 |
| Revision: 10 |
| |
| Number |
| |
| ARB Extension #99 |
| |
| Dependencies |
| |
| This extension is written against the OpenGL 3.2 specification |
| (Compatibility Profile). |
| |
| This extension is written against version 1.50 (revision 09) of the OpenGL |
| Shading Language Specification. |
| |
| OpenGL 3.0 and GLSL 1.30 are required. |
| |
| ARB_gpu_shader_fp64 (or equivalent functionality) is required. |
| |
| This extension interacts with OpenGL 3.1 implementations not supporting |
| ARB_compatibility and with the core profile of OpenGL 3.2. |
| |
| This extension interacts with EXT_direct_state_access. |
| |
| This extension interacts with NV_gpu_shader5. |
| |
| This extension interacts with NV_vertex_attrib_integer_64bit. |
| |
| This extension interacts with ARB_explicit_attrib_location, |
| ARB_separate_shader_objects, OpenGL 3.3, and OpenGL 4.1. |
| |
| Overview |
| |
| This extension provides OpenGL shading language support for vertex shader |
| inputs with 64-bit floating-point components and OpenGL API support for |
| specifying the value of those inputs using vertex array or immediate mode |
| entry points. This builds on the support for general-purpose support for |
| 64-bit floating-point values in the ARB_gpu_shader_fp64 extension. |
| |
| This extension provides a new class of vertex attribute functions, |
| beginning with "VertexAttribL" ("L" for "long"), that can be used to |
| specify attributes with 64-bit floating-point components. This extension |
| provides no automatic type conversion between attribute and shader |
| variables; single-precision attributes are not automatically converted to |
| double-precision or vice versa. For shader variables with 64-bit |
| component types, the "VertexAttribL" functions must be used to specify |
| attribute values. For other shader variables, the "VertexAttribL" |
| functions must not be used. If a vertex attribute is specified using the |
| wrong attribute function, the values of the corresponding shader input are |
| undefined. This approach requiring matching types is identical to that |
| used for the "VertexAttribI" functions provided by OpenGL 3.0 and the |
| EXT_gpu_shader4 extension. |
| |
| Additionally, some vertex shader inputs using the wider 64-bit components |
| may count double against the implementation-dependent limit on the number |
| of vertex shader attribute vectors. A 64-bit scalar or a two-component |
| vector consumes only a single generic vertex attribute; three- and |
| four-component "long" may count as two. This approach is similar to the |
| one used in the current GL where matrix attributes consume multiple |
| attributes. |
| |
| Note that 64-bit generic vertex attributes were nominally supported |
| beginning with the introduction of vertex shaders in OpenGL 2.0. However, |
| the OpenGL Shading Language at the time had no support for 64-bit data |
| types, so any such values were automatically converted to 32-bit. |
| |
| Support for 64-bit floating-point vertex attributes in this extension can |
| be combined with other extensions. In particular, this extension provides |
| an entry point that can be used with EXT_direct_state_access to directly |
| set state for any vertex array object. Also, the related |
| NV_vertex_attrib_integer_64bit extension provides an entry point to |
| specify bindless vertex attribute arrays with 64-bit components, integer |
| or floating-point. |
| |
| IP Status |
| |
| No known IP claims. |
| |
| New Procedures and Functions |
| |
| void VertexAttribL1d(uint index, double x); |
| void VertexAttribL2d(uint index, double x, double y); |
| void VertexAttribL3d(uint index, double x, double y, double z); |
| void VertexAttribL4d(uint index, double x, double y, double z, double w); |
| void VertexAttribL1dv(uint index, const double *v); |
| void VertexAttribL2dv(uint index, const double *v); |
| void VertexAttribL3dv(uint index, const double *v); |
| void VertexAttribL4dv(uint index, const double *v); |
| |
| void VertexAttribLPointer(uint index, int size, enum type, sizei stride, |
| const void *pointer); |
| |
| void GetVertexAttribLdv(uint index, enum pname, double *params); |
| |
| void VertexArrayVertexAttribLOffsetEXT(uint vaobj, uint buffer, |
| uint index, int size, |
| enum type, sizei stride, |
| intptr offset); |
| |
| (note: VertexArrayVertexAttribLOffsetEXT is provided only if |
| EXT_direct_state_access is supported.) |
| |
| New Tokens |
| |
| Returned in the <type> parameter of GetActiveAttrib: |
| |
| DOUBLE |
| DOUBLE_VEC2 0x8FFC |
| DOUBLE_VEC3 0x8FFD |
| DOUBLE_VEC4 0x8FFE |
| DOUBLE_MAT2 0x8F46 |
| DOUBLE_MAT3 0x8F47 |
| DOUBLE_MAT4 0x8F48 |
| DOUBLE_MAT2x3 0x8F49 |
| DOUBLE_MAT2x4 0x8F4A |
| DOUBLE_MAT3x2 0x8F4B |
| DOUBLE_MAT3x4 0x8F4C |
| DOUBLE_MAT4x2 0x8F4D |
| DOUBLE_MAT4x3 0x8F4E |
| |
| Note: These enums are defined in ARB_gpu_shader_fp64, which is required |
| by this extension. They are included here only for completeness. |
| |
| Additions to Chapter 2 of the OpenGL 3.2 (Compatibility Profile) Specification |
| (OpenGL Operation) |
| |
| Modify Section 2.7, Vertex Specification (p. 24) |
| |
| (delete third paragraph, p. 33, beginning with "The resulting attribute |
| values are undefined") |
| |
| (rework the description of the VertexAttribI* commands, and add support |
| for new VertexAttribL* commands, p. 33) |
| |
| To load values into a generic shader attribute declared as a signed or |
| unsigned integer or integer vector, use the commands |
| |
| void VertexAttribI{1,2,3,4}{i,ui}( uint index, T values ); |
| void VertexAttribI{1,2,3,4}{i,ui}v( uint index, T values ); |
| void VertexAttribI4{b,s,ub,us}v( uint index, T values ); |
| |
| These commands specify values that are extended to full signed or unsigned |
| integers, then loaded into the generic attribute at slot index in the same |
| fashion as described above. |
| |
| To load values into a generic shader attribute declared as a double, or |
| into vectors or matrices thereof, use the commands |
| |
| void VertexAttribL{1,2,3,4}d(uint index, T values); |
| void VertexAttribL{1,2,3,4}dv(uint index, T values); |
| |
| These commands specify one, two, three or four values. Note that attribute |
| variables declared with "double" types must be loaded with |
| VertexAttribL*d{v}; loading attributes with VertexAttrib*d{v} will |
| produce undefined results. |
| |
| For all VertexAttrib* commands, the error INVALID_VALUE is generated if |
| <index> is greater than or equal to MAX_VERTEX_ATTRIBS. |
| |
| The full set of VertexAttrib* commands specify generic attributes whose |
| components are one of the data types: |
| |
| * floating-point values (VertexAttrib*), |
| * signed or unsigned integers (VertexAttribI*), and |
| * double-precision floating-point values (VertexAttribL*d*) |
| |
| The values loaded into a shader attribute variable bound to generic |
| attribute <index> are undefined if the data type of the attribute |
| components specified by the most recent VertexAttrib* command do not match |
| the data type of the variable. |
| |
| |
| Modify Section 2.8, Vertex Arrays, p. 34 |
| |
| (insert new paragraph after first paragraph, p. 37) |
| |
| The command |
| |
| void VertexAttribLPointer(uint index, int size, enum type, |
| sizei stride, const void *pointer); |
| |
| specifies state for a generic vertex attribute array associated with a |
| shader attribute variable declared with 64-bit double precision components. |
| <type> must be DOUBLE. <index>, <size>, and <stride> behave as defined in |
| all other vertex commands; <size> may be one, two, three or four. |
| |
| Each component of an array specified by VertexAttribLPointer will be |
| encoded into one or more generic attribute components as specified for the |
| VertexAttribL* commands in Section 2.7. The error INVALID_VALUE is |
| generated if <index> is greater than or equal to MAX_VERTEX_ATTRIBS. |
| |
| |
| (modify pseudo-code, p. 38, to handle VertexAttribLPointer) |
| |
| ... |
| for (j = 1; j < genericAttributes; j++) { |
| if (generic vertex attribute j array enabled) { |
| if (generic attribute j array set by VertexAttribLPointer) { |
| VertexAttribL[size][type]v(j, generic vertex attribute j |
| array element i); |
| } else if (generic attribute j array set by VertexAttribIPointer) { |
| VertexAttribI[size][type]v(j, generic vertex attribute j |
| array element i); |
| } else if (generic vertex attribute j array normalization flag |
| is set, and type is not FLOAT or DOUBLE) { |
| VertexAttrib[size]N[type]v(j, generic vertex attribute j |
| array element i); |
| } else { |
| VertexAttrib[size][type]v(j, generic vertex attribute j |
| array element i); |
| } |
| } |
| } |
| |
| if (generic attribute 0 array enabled) { |
| if (generic attribute 0 array set by VertexAttribLPointers) { |
| VertexAttribL[size][type]v(0, generic vertex attribute 0 |
| array element i); |
| } else if (generic attribute 0 array set by VertexAttribIPointer) { |
| VertexAttribI[size][type]v(0, generic vertex attribute 0 |
| array element i); |
| } else if (generic vertex attribute 0 array normalization flag |
| is set, and type is not FLOAT or DOUBLE) { |
| VertexAttrib[size]N[type]v(0, generic vertex attribute 0 |
| array element i); |
| } else { |
| VertexAttrib[size][type]v(0, generic vertex attribute 0 |
| array element i); |
| } |
| } else if (vertex array enabled) { |
| ... |
| |
| |
| Modify the "Add to the end of Section 2.10 (Vertex Array Objects)" section |
| of EXT_direct_state_access |
| |
| (add a new function prototype to the initial list of commands) |
| |
| void VertexArrayVertexAttribLOffsetEXT(uint vaobj, uint buffer, |
| uint index, int size, |
| enum type, sizei stride, |
| intptr offset); |
| |
| (No edits are made to the language added in this section. The same |
| general rules described in EXT_direct_state_access apply here -- <vaobj> |
| identifies a vertex array object used instead of the currently bound one, |
| <buffer> is used in place of the buffer object bound to ARRAY_BUFFER, and |
| the command otherwise behaves like VertexAttribLPointer with <pointer> |
| set to <offset>.) |
| |
| |
| Modify Section 2.14.3, Vertex Attributes, p. 86 |
| |
| (replace last paragraph, p. 86) |
| |
| When an attribute variable declared using one of the scalar or vector data |
| types enumerated in Table X.1 and is bound to a generic attribute index |
| <i>, its value(s) are taken from the components of generic attribute <i>. |
| Scalars are extracted from the x component; two-, three-, and |
| four-component vectors are extracted from the, (x, y), (x, y, z), or (x, |
| y, z, w) components, respectively. |
| |
| Data type Command |
| ------------------------------- ---------------------------------- |
| int int8_t int16_t int32_t VertexAttribI1i |
| ivec2 i8vec2 i16vec2 i32vec2 VertexAttribI2i |
| ivec3 i8vec3 i16vec3 i32vec3 VertexAttribI3i |
| ivec4 i8vec4 i16vec4 i32vec4 VertexAttribI4i |
| |
| uint uint8_t uint16_t uint32_t VertexAttribI1ui |
| uvec2 u8vec2 u16vec2 u32vec2 VertexAttribI2ui |
| uvec3 u8vec3 u16vec3 u32vec3 VertexAttribI3ui |
| uvec4 u8vec4 u16vec4 u32vec4 VertexAttribI4ui |
| |
| float float16_t float32_t VertexAttrib1{f,b,s,i,ub,us,ui,d} |
| vec2 f16vec2 f32vec2 VertexAttrib2{f,b,s,i,ub,us,ui,d} |
| vec3 f16vec3 f32vec3 VertexAttrib3{f,b,s,i,ub,us,ui,d} |
| vec4 f16vec4 f32vec4 VertexAttrib4{f,b,s,i,ub,us,ui,d} |
| |
| double float64_t VertexAttribL1d |
| dvec2 f64vec2 VertexAttribL2d |
| dvec3 f64vec3 VertexAttribL3d |
| dvec4 f64vec4 VertexAttribL4d |
| |
| |
| Table X.1: Scalar and vector vertex attribute types and VertexAttrib* |
| commands used to set the values of the corresponding generic attribute. |
| |
| When an attribute variable is declared as a mat2, mat3x2, mat4x2, its |
| matrix columns are taken from the (x, y) components of generic attributes |
| <i> and <i>+1 (mat2, dmat2), from attributes <i> through <i>+2 (mat3x2), |
| or from attributes <i> through <i>+3 (mat4x2). When an attribute variable |
| is declared as a mat2x3, mat3 or mat4x3, its matrix columns are taken from |
| the (x, y, z) components of generic attributes i and <i>+1 (mat2x3), from |
| attributes <i> through <i>+2 (mat3), or from attributes i through <i>+3 |
| (mat4x3). When an attribute variable is declared as a mat2x4, mat3x4 or |
| mat4, its matrix columns are taken from the (x, y, z, w) components of |
| generic attributes <i> and <i>+1 (mat2x4), from attributes <i> through |
| <i>+2 (mat3x4), or from attributes <i> through <i>+3 (mat4). When an |
| attribute variable is declared as a double-precision matrix (dmat2, dmat3, |
| dmat4, dmat2x3, dmat2x4, dmat3x2, dmat3x4, dmat4x2, dmat4x3), its matrix |
| columns are taken from the same generic attributes as the equivalent |
| single-precision matrix type, with values specified using the |
| VertexAttribL* or VertexAttribLPointer commands. |
| |
| For the 64-bit double precision types listed in Table X.1, no default |
| attribute values are provided if the values of the vertex attribute variable |
| are specified with fewer components than required for the attribute |
| variable. For example, the fourth component of a variable of type dvec4 |
| will be undefined if specified using VertexAttribL3dv or using a vertex |
| array specified with VertexAttribLPointer and a size of three. |
| |
| |
| (modify the second paragraph, p. 87) ... exceeds MAX_VERTEX_ATTRIBS. For |
| the purposes of this comparison, attribute variables of the type dvec3, |
| dvec4, dmat2x3, dmat2x4, dmat3, dmat3x4, dmat4x3, and dmat4 may count as |
| consuming twice as many attributes as equivalent single-precision types. |
| While these types use the same number of generic attributes as their |
| single-precision equivalents, implementations are permitted to consume two |
| single-precision vectors of internal storage for each three- or |
| four-component double-precision vector. |
| |
| (extend the list of types in the first paragraph, p. 88) |
| ... UNSIGNED_INT_VEC3, UNSIGNED_INT_VEC4, DOUBLE, DOUBLE_VEC2, |
| DOUBLE_VEC3, DOUBLE_VEC4, DOUBLE_MAT2, DOUBLE_MAT3, DOUBLE_MAT4, |
| DOUBLE_MAT2x3, DOUBLE_MAT2x4, DOUBLE_MAT3x2, DOUBLE_MAT3x4, DOUBLE_MAT4x2, |
| or DOUBLE_MAT4x3. |
| |
| (add the following entries to table 2.13: OpenGL Shading Language type |
| tokens returned by GetActiveUniform and GetActiveUniformsiv, and |
| corresponding shading language keywords declaring each such type., p. 96) |
| |
| Type Name Token | Keyword |
| --------------------------------- |
| DOUBLE | double |
| DOUBLE_VEC2 | dvec2 |
| DOUBLE_VEC3 | dvec3 |
| DOUBLE_VEC4 | dvec4 |
| DOUBLE_MAT2 | dmat2 |
| DOUBLE_MAT3 | dmat3 |
| DOUBLE_MAT4 | dmat4 |
| DOUBLE_MAT2x3 | dmat2x3 |
| DOUBLE_MAT2x4 | dmat2x4 |
| DOUBLE_MAT3x2 | dmat3x2 |
| DOUBLE_MAT3x4 | dmat3x4 |
| DOUBLE_MAT4x2 | dmat4x2 |
| DOUBLE_MAT4x3 | dmat4x3 |
| |
| 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) |
| |
| Modify Section 5.4.1, Commands Not Usable in Display Lists, p. 358 |
| |
| (add to "Vertex arrays" list) VertexAttribLPointer, and |
| VertexArrayVertexAttribLOffsetEXT. |
| |
| (note: GetVertexAttribL* commands are also not allowed in display lists, |
| but is already covered by blanket language in "Other queries") |
| |
| |
| 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. 384 |
| |
| (add to the last list of commands, p. 387) |
| |
| void GetVertexAttribLdv(uint index, enum pname, double *params); |
| |
| (modify the third paragraph, p. 388) The query CURRENT_VERTEX_ATTRIB |
| returns the current value for the generic attribute |
| <index>. GetVertexAttribdv and GetVertexAttribfv read and return the |
| current attribute values as four single-precision floating-point values; |
| GetVertexAttribiv reads them as floating-point values and converts them to |
| four integer values; GetVertexAttribIiv reads and returns them as signed |
| integers; GetVertexAttribIuiv reads and returns them as four unsigned |
| integers; GetVertexAttribLdv reads and returns them as four double-precision |
| floating-point values. The results of the query are undefined if the |
| current attribute values are read using one data type but were specified |
| using a different one. The error INVALID_OPERATION is generated if index |
| is zero, as there is no current value for generic attribute zero. |
| |
| |
| 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_ARB_vertex_attrib_64bit : <behavior> |
| |
| where <behavior> is as specified in section 3.3. |
| |
| New preprocessor #defines are added to the OpenGL Shading Language: |
| |
| #define GL_ARB_vertex_attrib_64bit 1 |
| |
| |
| Modify Section 4.3.4, Inputs, p. 31 |
| |
| (modify third paragraph of the section, p. 31, allowing double-precision |
| vertex shader inputs) ... Vertex shader inputs can only be single- or |
| double-precision floating-point scalars, vectors, or matrices, or signed |
| and unsigned integers and integer vectors. Vertex shader inputs can also |
| form arrays of these types, but not structures. |
| |
| |
| GLX Protocol |
| |
| !!! TBD !!! |
| |
| Dependencies on OpenGL 3.1 and OpenGL 3.2 |
| |
| When using an OpenGL 3.1 context without support for the ARB_compatibility |
| extension or the core profile of OpenGL 3.2, remove the pseudocode |
| describing the operation of ArrayElement. The core profile specifies |
| commands like DrawArrays and DrawElements more concisely. Additionally, |
| remove edits relevant to (deleted) display list functionality. |
| |
| Dependencies on EXT_direct_state_access |
| |
| If EXT_direct_state_access is not supported, references to the function |
| VertexArrayVertexAttribLOffsetEXT should be removed. |
| |
| Dependencies on NV_gpu_shader5 |
| |
| If NV_gpu_shader5 is not supported, references to the sized data types |
| provided by these extensions (e.g., int8_t, float16_t, u16vec4, f64vec2) |
| in Table X.1 should be removed. The full set of types in the table is |
| provided for completeness. |
| |
| Dependencies on NV_vertex_attrib_integer_64bit |
| |
| The extension NV_vertex_attrib_integer_64bit provides similar |
| VertexAttribL* support for 64-bit signed and unsigned integer vertex |
| shader inputs. That extension also uses the VertexAttribLPointer |
| function to specify 64-bit integer vertex attribute arrays. |
| |
| Even if an application only uses 64-bit floating-point values in their |
| vertex shader, NV_vertex_attrib_integer_64bit may still be useful. That |
| extension also provides the VertexAttribLFormatNV function, which allows |
| the "bindless" vertex attribute array support provided by the |
| NV_vertex_buffer_unified_memory extension to be used with 64-bit |
| components, integer or floating-point. |
| |
| Dependencies on ARB_explicit_attrib_location, ARB_separate_shader_objects, |
| OpenGL 3.3, and OpenGL 4.1 |
| |
| If ARB_explicit_attrib_location (or OpenGL 3.3) is supported, vertex |
| shader input variables (including ones with double-precision components) |
| can select associated generic attributes with an explicit location layout |
| qualifier in lieu of calling BindAttribLocation. If |
| ARB_separate_shader_objects (or OpenGL 4.1) is supported, the layout |
| location qualifier introduced by this extension is extended to apply to |
| inputs for non-vertex shaders and outputs for non-fragment shaders. As |
| this extension requires ARB_gpu_shader_fp64 (or OpenGL 4.0), such inputs |
| and outputs can have double-precision component types. |
| |
| When these extensions are supported, there are special rules for the |
| number of locations consumed by "dvec3" and "dvec4" types, which require |
| more storage than is available in a four-component single-precision |
| vector. The rules are: |
| |
| * dvec3/dvec4 vertex inputs consume one location (generic vertex |
| attribute), but can count as two vectors for the purposes of |
| determining if the vertex shader consumes too many inputs |
| |
| * dvec3/dvec4 inputs and outputs for other stages consume two locations |
| |
| The relevant spec edits (modifying language introduced by |
| ARB_explicit_attrib_location) can be found in the |
| ARB_separate_shader_objects extension. |
| |
| Errors |
| |
| For all VertexAttrib* commands, the error INVALID_VALUE is generated if |
| <index> is greater than or equal to MAX_VERTEX_ATTRIBS. |
| |
| For VertexAttribLPointer, VertexAttribLFormat, and |
| VertexArrayVertexAttribLOffsetEXT, the error INVALID_VALUE is generated if |
| <index> is greater than or equal to MAX_VERTEX_ATTRIBS. |
| |
| New State |
| |
| None. |
| |
| New Implementation Dependent State |
| |
| None. |
| |
| Issues |
| |
| (1) Should we allow 64-bit double-precision vertex attributes in the OpenGL |
| API? If so, how should we handle 64-bit double-precision values? |
| |
| RESOLVED: Yes, we will allow vertex shader inputs to have any scalar |
| or vector type, including sized types. Doubles appear to the API as any |
| other type. The new 'L' versions of the entry points are added to |
| distinguish 64-bit attributes from existing DOUBLE support, where doubles |
| are down-converted to floats. |
| |
| (2) How does the handling of 64-bit vertex attribute components in this |
| extension interact with the existing vertex attribute functions that |
| support doubles? |
| |
| RESOLVED: While it is possible for fixed-function pipeline |
| implementations to operate directly on doubles, most (if not all) such |
| implementations simply convert doubles to floats. The OpenGL Shading |
| Language has not supported double-precision types to date, so all |
| previous shading language inputs needed to be converted to float by |
| necessity. |
| |
| While it would be possible to support the existing double-precision |
| vertex APIs (e.g., VertexAttrib4dv) to feed shading language variables |
| with double-precision types, any such approach involves the prohibitive |
| dynamic typing overhead discussed above. As a result, we chose to |
| create a parallel VertexAttribL* API. |
| |
| A similar approach was chosen for the integer attributes in OpenGL 3.0, |
| where there was a pre-existing set of vertex APIs that accepted integers |
| that were converted to floating-point values via straight value |
| conversion or normalization. Re-using existing integer APIs to feed the |
| (new) integer variable types would have required similarly expensive |
| dynamic typing. |
| |
| (3) How should we handle vertex attributes for three- and four-component |
| vectors with double-precision components? How do we support these |
| with vertex arrays? |
| |
| RESOLVED: Double-precision attributes may consume twice as much |
| internal storage as their single-precision counterparts. For the |
| purposes of determining if a vertex shader uses "too many" attribute |
| vectors in LinkProgram, implementations are permitted (but not required) |
| to count "dvec3" and "dvec4" vertex shader inputs as consuming twice as |
| many input vectors as corresponding single-precision types. |
| Implementations are required to count inputs of type "double" and |
| "dvec2" as a single vector, since these types require no more storage |
| than a "vec4". |
| |
| Note however, that for the purposes of mapping inputs to generic vertex |
| attributes, "dvec3" and "dvec4" inputs are counted as consuming one |
| attribute/location. For example, if a vertex shader specifies: |
| |
| layout(location=4) in dvec4 attribs[4]; |
| |
| the values for the four elements of "attribs" will be taken from vertex |
| attributes 4-7, though "attribs" may be counted as consuming eight |
| vectors worth of attributes. |
| |
| (4) Are default values supported for vertex attributes with 64-bit |
| components? |
| |
| RESOLVED: No. With existing APIs, calling VertexAttrib3f() defines a |
| FOUR-component vector where the fourth component assumes the value 1.0. |
| No such defaults are provided for 64-bit components; if you load the |
| values of an attribute of type "dvec4" with VertexAttribL3dv(), the |
| value of the fourth component of the attribute variable will be |
| undefined. |
| |
| The APIs for loading 64-bit vertex attributes were designed to limit the |
| amount of data type conversion required of the implementation; providing |
| new type-dependent default values runs contrary to that design. |
| |
| Note that the original defaults were present in part to accommodate |
| fixed-function vertex and fragment processing, where certain operations |
| were defined in the most general form but reasonable defaults allowed |
| targeted optimizations. For example, vertex transformations were |
| defined to operate on four-component object coordinates, even though |
| four-component input positions are relatively rare. Specifying a |
| default W value of 1.0 allows for a fully-general implementation that |
| doesn't need to do special cases based on the input position, but can |
| still choose to do so as an optimization. Programmable shaders, on the |
| other hand, can easily be written to ignore irrelevant components and |
| substitute constants themselves. |
| |
| (5) Should this have a separate extension string entry or be simply |
| implied by extensions such as ARB_gpu_shader5 or ARB_gpu_shader_fp64? |
| |
| RESOLVED: Treat as a separate extension, since there may be several |
| such extensions with varying capabilities. |
| |
| Additionally, we provide a separate GLSL "#extension" identifier for |
| this extension because ARB_gpu_shader_fp64 was adopted without support |
| for vertex inputs with 64-bit components. |
| |
| (6) How does this extension provide 64-bit vertex attribute components for |
| assembly programs supported by NV_gpu_program5? |
| |
| RESOLVED: NV_gpu_program5 allows programs to declare input variables |
| with 64-bit components using the "LONG ATTRIB" declaration syntax. |
| These inputs will be matched up against corresponding vertex attributes |
| in the same manner as with GLSL. Also, as with GLSL, the values of each |
| vertex program input must be specified with the correct API function |
| (VertexAttrib* vs. VertexAttribL*). |
| |
| |
| Revision History |
| |
| Rev. Date Author Changes |
| ---- -------- -------- ----------------------------------------------- |
| 10 06/10/14 Jon Leech Fix typo in name of EXT_direct_state_access |
| (Bug 7704). |
| |
| 9 08/01/11 pbrown Clarify that "dvec3" and "dvec4" vertex shader |
| inputs consume only a single "location" for the |
| purpose of matching inputs to generic vertex |
| attributes, but may consume two vectors for the |
| purposes of determining if too many attribute |
| vectors are used (bug 7809). Also, add missing |
| language describing the set of attributes |
| consumed by matrix vertex attributes (copied |
| from OpenGL 4.1), with fixes to explicitly |
| address "dmat*" types. Fix issue (3) to match. |
| |
| 8 01/18/11 Jon Leech Make description of component data types |
| match the commands specifying them |
| (Bug 7235). |
| |
| 7 07/06/10 pbrown Fix cut-and-paste errors in table mapping |
| GLSL types to API entry points. |
| |
| 6 04/09/10 pdaniell ARBify the spec for inclusion in OpenGL 4.1. |
| |
| 5 03/21/10 pbrown Minor wording updates to the spec overview, |
| dependencies, issues, and body. |
| |
| 4 01/29/10 pbrown Update extension to accomodate the removal of |
| fp64 vertex inputs from ARB_gpu_shader_fp64 (bug |
| 5953). The API support for enumerating fp64 |
| inputs and the GLSL support allowing fp64 vertex |
| inputs now belongs to this extension. For the |
| GLSL support, we add a "#extension" token to |
| specify that fp64 vertex inputs should be |
| allowed. Also, update several issues. |
| |
| 3 gsellers Updates based on discussion |
| |
| 2 gsellers EXT'ify. |
| |
| 1 pbrown Internal revisions. |