1Name 2 3 ARB_vertex_attrib_64bit 4 5Name Strings 6 7 GL_ARB_vertex_attrib_64bit 8 9Contact 10 11 Graham Sellers, AMD (graham.sellers 'at' amd.com) 12 Pat Brown, NVIDIA (pbrown 'at' nvidia.com) 13 Piers Daniell, NVIDIA (pdaniell 'at' nvidia.com) 14 15Contributors 16 17 Barthold Lichtenbelt, NVIDIA 18 Bill Licea-Kane, AMD 19 Eric Werness, NVIDIA 20 Graham Sellers, AMD 21 Greg Roth, NVIDIA 22 Jeff Bolz, NVIDIA 23 Nick Haemel, AMD 24 Pierre Boudier, AMD 25 Piers Daniell, NVIDIA 26 27Notice 28 29 Copyright (c) 2010-2013 The Khronos Group Inc. Copyright terms at 30 http://www.khronos.org/registry/speccopyright.html 31 32Specification Update Policy 33 34 Khronos-approved extension specifications are updated in response to 35 issues and bugs prioritized by the Khronos OpenGL Working Group. For 36 extensions which have been promoted to a core Specification, fixes will 37 first appear in the latest version of that core Specification, and will 38 eventually be backported to the extension document. This policy is 39 described in more detail at 40 https://www.khronos.org/registry/OpenGL/docs/update_policy.php 41 42Status 43 44 Complete. Approved by the ARB on June 9, 2010. 45 Approved by the Khronos Board of Promoters on July 23, 2010. 46 47Version 48 49 Last Modified Date: June 10, 2014 50 Revision: 10 51 52Number 53 54 ARB Extension #99 55 56Dependencies 57 58 This extension is written against the OpenGL 3.2 specification 59 (Compatibility Profile). 60 61 This extension is written against version 1.50 (revision 09) of the OpenGL 62 Shading Language Specification. 63 64 OpenGL 3.0 and GLSL 1.30 are required. 65 66 ARB_gpu_shader_fp64 (or equivalent functionality) is required. 67 68 This extension interacts with OpenGL 3.1 implementations not supporting 69 ARB_compatibility and with the core profile of OpenGL 3.2. 70 71 This extension interacts with EXT_direct_state_access. 72 73 This extension interacts with NV_gpu_shader5. 74 75 This extension interacts with NV_vertex_attrib_integer_64bit. 76 77 This extension interacts with ARB_explicit_attrib_location, 78 ARB_separate_shader_objects, OpenGL 3.3, and OpenGL 4.1. 79 80Overview 81 82 This extension provides OpenGL shading language support for vertex shader 83 inputs with 64-bit floating-point components and OpenGL API support for 84 specifying the value of those inputs using vertex array or immediate mode 85 entry points. This builds on the support for general-purpose support for 86 64-bit floating-point values in the ARB_gpu_shader_fp64 extension. 87 88 This extension provides a new class of vertex attribute functions, 89 beginning with "VertexAttribL" ("L" for "long"), that can be used to 90 specify attributes with 64-bit floating-point components. This extension 91 provides no automatic type conversion between attribute and shader 92 variables; single-precision attributes are not automatically converted to 93 double-precision or vice versa. For shader variables with 64-bit 94 component types, the "VertexAttribL" functions must be used to specify 95 attribute values. For other shader variables, the "VertexAttribL" 96 functions must not be used. If a vertex attribute is specified using the 97 wrong attribute function, the values of the corresponding shader input are 98 undefined. This approach requiring matching types is identical to that 99 used for the "VertexAttribI" functions provided by OpenGL 3.0 and the 100 EXT_gpu_shader4 extension. 101 102 Additionally, some vertex shader inputs using the wider 64-bit components 103 may count double against the implementation-dependent limit on the number 104 of vertex shader attribute vectors. A 64-bit scalar or a two-component 105 vector consumes only a single generic vertex attribute; three- and 106 four-component "long" may count as two. This approach is similar to the 107 one used in the current GL where matrix attributes consume multiple 108 attributes. 109 110 Note that 64-bit generic vertex attributes were nominally supported 111 beginning with the introduction of vertex shaders in OpenGL 2.0. However, 112 the OpenGL Shading Language at the time had no support for 64-bit data 113 types, so any such values were automatically converted to 32-bit. 114 115 Support for 64-bit floating-point vertex attributes in this extension can 116 be combined with other extensions. In particular, this extension provides 117 an entry point that can be used with EXT_direct_state_access to directly 118 set state for any vertex array object. Also, the related 119 NV_vertex_attrib_integer_64bit extension provides an entry point to 120 specify bindless vertex attribute arrays with 64-bit components, integer 121 or floating-point. 122 123IP Status 124 125 No known IP claims. 126 127New Procedures and Functions 128 129 void VertexAttribL1d(uint index, double x); 130 void VertexAttribL2d(uint index, double x, double y); 131 void VertexAttribL3d(uint index, double x, double y, double z); 132 void VertexAttribL4d(uint index, double x, double y, double z, double w); 133 void VertexAttribL1dv(uint index, const double *v); 134 void VertexAttribL2dv(uint index, const double *v); 135 void VertexAttribL3dv(uint index, const double *v); 136 void VertexAttribL4dv(uint index, const double *v); 137 138 void VertexAttribLPointer(uint index, int size, enum type, sizei stride, 139 const void *pointer); 140 141 void GetVertexAttribLdv(uint index, enum pname, double *params); 142 143 void VertexArrayVertexAttribLOffsetEXT(uint vaobj, uint buffer, 144 uint index, int size, 145 enum type, sizei stride, 146 intptr offset); 147 148 (note: VertexArrayVertexAttribLOffsetEXT is provided only if 149 EXT_direct_state_access is supported.) 150 151New Tokens 152 153 Returned in the <type> parameter of GetActiveAttrib: 154 155 DOUBLE 156 DOUBLE_VEC2 0x8FFC 157 DOUBLE_VEC3 0x8FFD 158 DOUBLE_VEC4 0x8FFE 159 DOUBLE_MAT2 0x8F46 160 DOUBLE_MAT3 0x8F47 161 DOUBLE_MAT4 0x8F48 162 DOUBLE_MAT2x3 0x8F49 163 DOUBLE_MAT2x4 0x8F4A 164 DOUBLE_MAT3x2 0x8F4B 165 DOUBLE_MAT3x4 0x8F4C 166 DOUBLE_MAT4x2 0x8F4D 167 DOUBLE_MAT4x3 0x8F4E 168 169 Note: These enums are defined in ARB_gpu_shader_fp64, which is required 170 by this extension. They are included here only for completeness. 171 172Additions to Chapter 2 of the OpenGL 3.2 (Compatibility Profile) Specification 173(OpenGL Operation) 174 175 Modify Section 2.7, Vertex Specification (p. 24) 176 177 (delete third paragraph, p. 33, beginning with "The resulting attribute 178 values are undefined") 179 180 (rework the description of the VertexAttribI* commands, and add support 181 for new VertexAttribL* commands, p. 33) 182 183 To load values into a generic shader attribute declared as a signed or 184 unsigned integer or integer vector, use the commands 185 186 void VertexAttribI{1,2,3,4}{i,ui}( uint index, T values ); 187 void VertexAttribI{1,2,3,4}{i,ui}v( uint index, T values ); 188 void VertexAttribI4{b,s,ub,us}v( uint index, T values ); 189 190 These commands specify values that are extended to full signed or unsigned 191 integers, then loaded into the generic attribute at slot index in the same 192 fashion as described above. 193 194 To load values into a generic shader attribute declared as a double, or 195 into vectors or matrices thereof, use the commands 196 197 void VertexAttribL{1,2,3,4}d(uint index, T values); 198 void VertexAttribL{1,2,3,4}dv(uint index, T values); 199 200 These commands specify one, two, three or four values. Note that attribute 201 variables declared with "double" types must be loaded with 202 VertexAttribL*d{v}; loading attributes with VertexAttrib*d{v} will 203 produce undefined results. 204 205 For all VertexAttrib* commands, the error INVALID_VALUE is generated if 206 <index> is greater than or equal to MAX_VERTEX_ATTRIBS. 207 208 The full set of VertexAttrib* commands specify generic attributes whose 209 components are one of the data types: 210 211 * floating-point values (VertexAttrib*), 212 * signed or unsigned integers (VertexAttribI*), and 213 * double-precision floating-point values (VertexAttribL*d*) 214 215 The values loaded into a shader attribute variable bound to generic 216 attribute <index> are undefined if the data type of the attribute 217 components specified by the most recent VertexAttrib* command do not match 218 the data type of the variable. 219 220 221 Modify Section 2.8, Vertex Arrays, p. 34 222 223 (insert new paragraph after first paragraph, p. 37) 224 225 The command 226 227 void VertexAttribLPointer(uint index, int size, enum type, 228 sizei stride, const void *pointer); 229 230 specifies state for a generic vertex attribute array associated with a 231 shader attribute variable declared with 64-bit double precision components. 232 <type> must be DOUBLE. <index>, <size>, and <stride> behave as defined in 233 all other vertex commands; <size> may be one, two, three or four. 234 235 Each component of an array specified by VertexAttribLPointer will be 236 encoded into one or more generic attribute components as specified for the 237 VertexAttribL* commands in Section 2.7. The error INVALID_VALUE is 238 generated if <index> is greater than or equal to MAX_VERTEX_ATTRIBS. 239 240 241 (modify pseudo-code, p. 38, to handle VertexAttribLPointer) 242 243 ... 244 for (j = 1; j < genericAttributes; j++) { 245 if (generic vertex attribute j array enabled) { 246 if (generic attribute j array set by VertexAttribLPointer) { 247 VertexAttribL[size][type]v(j, generic vertex attribute j 248 array element i); 249 } else if (generic attribute j array set by VertexAttribIPointer) { 250 VertexAttribI[size][type]v(j, generic vertex attribute j 251 array element i); 252 } else if (generic vertex attribute j array normalization flag 253 is set, and type is not FLOAT or DOUBLE) { 254 VertexAttrib[size]N[type]v(j, generic vertex attribute j 255 array element i); 256 } else { 257 VertexAttrib[size][type]v(j, generic vertex attribute j 258 array element i); 259 } 260 } 261 } 262 263 if (generic attribute 0 array enabled) { 264 if (generic attribute 0 array set by VertexAttribLPointers) { 265 VertexAttribL[size][type]v(0, generic vertex attribute 0 266 array element i); 267 } else if (generic attribute 0 array set by VertexAttribIPointer) { 268 VertexAttribI[size][type]v(0, generic vertex attribute 0 269 array element i); 270 } else if (generic vertex attribute 0 array normalization flag 271 is set, and type is not FLOAT or DOUBLE) { 272 VertexAttrib[size]N[type]v(0, generic vertex attribute 0 273 array element i); 274 } else { 275 VertexAttrib[size][type]v(0, generic vertex attribute 0 276 array element i); 277 } 278 } else if (vertex array enabled) { 279 ... 280 281 282 Modify the "Add to the end of Section 2.10 (Vertex Array Objects)" section 283 of EXT_direct_state_access 284 285 (add a new function prototype to the initial list of commands) 286 287 void VertexArrayVertexAttribLOffsetEXT(uint vaobj, uint buffer, 288 uint index, int size, 289 enum type, sizei stride, 290 intptr offset); 291 292 (No edits are made to the language added in this section. The same 293 general rules described in EXT_direct_state_access apply here -- <vaobj> 294 identifies a vertex array object used instead of the currently bound one, 295 <buffer> is used in place of the buffer object bound to ARRAY_BUFFER, and 296 the command otherwise behaves like VertexAttribLPointer with <pointer> 297 set to <offset>.) 298 299 300 Modify Section 2.14.3, Vertex Attributes, p. 86 301 302 (replace last paragraph, p. 86) 303 304 When an attribute variable declared using one of the scalar or vector data 305 types enumerated in Table X.1 and is bound to a generic attribute index 306 <i>, its value(s) are taken from the components of generic attribute <i>. 307 Scalars are extracted from the x component; two-, three-, and 308 four-component vectors are extracted from the, (x, y), (x, y, z), or (x, 309 y, z, w) components, respectively. 310 311 Data type Command 312 ------------------------------- ---------------------------------- 313 int int8_t int16_t int32_t VertexAttribI1i 314 ivec2 i8vec2 i16vec2 i32vec2 VertexAttribI2i 315 ivec3 i8vec3 i16vec3 i32vec3 VertexAttribI3i 316 ivec4 i8vec4 i16vec4 i32vec4 VertexAttribI4i 317 318 uint uint8_t uint16_t uint32_t VertexAttribI1ui 319 uvec2 u8vec2 u16vec2 u32vec2 VertexAttribI2ui 320 uvec3 u8vec3 u16vec3 u32vec3 VertexAttribI3ui 321 uvec4 u8vec4 u16vec4 u32vec4 VertexAttribI4ui 322 323 float float16_t float32_t VertexAttrib1{f,b,s,i,ub,us,ui,d} 324 vec2 f16vec2 f32vec2 VertexAttrib2{f,b,s,i,ub,us,ui,d} 325 vec3 f16vec3 f32vec3 VertexAttrib3{f,b,s,i,ub,us,ui,d} 326 vec4 f16vec4 f32vec4 VertexAttrib4{f,b,s,i,ub,us,ui,d} 327 328 double float64_t VertexAttribL1d 329 dvec2 f64vec2 VertexAttribL2d 330 dvec3 f64vec3 VertexAttribL3d 331 dvec4 f64vec4 VertexAttribL4d 332 333 334 Table X.1: Scalar and vector vertex attribute types and VertexAttrib* 335 commands used to set the values of the corresponding generic attribute. 336 337 When an attribute variable is declared as a mat2, mat3x2, mat4x2, its 338 matrix columns are taken from the (x, y) components of generic attributes 339 <i> and <i>+1 (mat2, dmat2), from attributes <i> through <i>+2 (mat3x2), 340 or from attributes <i> through <i>+3 (mat4x2). When an attribute variable 341 is declared as a mat2x3, mat3 or mat4x3, its matrix columns are taken from 342 the (x, y, z) components of generic attributes i and <i>+1 (mat2x3), from 343 attributes <i> through <i>+2 (mat3), or from attributes i through <i>+3 344 (mat4x3). When an attribute variable is declared as a mat2x4, mat3x4 or 345 mat4, its matrix columns are taken from the (x, y, z, w) components of 346 generic attributes <i> and <i>+1 (mat2x4), from attributes <i> through 347 <i>+2 (mat3x4), or from attributes <i> through <i>+3 (mat4). When an 348 attribute variable is declared as a double-precision matrix (dmat2, dmat3, 349 dmat4, dmat2x3, dmat2x4, dmat3x2, dmat3x4, dmat4x2, dmat4x3), its matrix 350 columns are taken from the same generic attributes as the equivalent 351 single-precision matrix type, with values specified using the 352 VertexAttribL* or VertexAttribLPointer commands. 353 354 For the 64-bit double precision types listed in Table X.1, no default 355 attribute values are provided if the values of the vertex attribute variable 356 are specified with fewer components than required for the attribute 357 variable. For example, the fourth component of a variable of type dvec4 358 will be undefined if specified using VertexAttribL3dv or using a vertex 359 array specified with VertexAttribLPointer and a size of three. 360 361 362 (modify the second paragraph, p. 87) ... exceeds MAX_VERTEX_ATTRIBS. For 363 the purposes of this comparison, attribute variables of the type dvec3, 364 dvec4, dmat2x3, dmat2x4, dmat3, dmat3x4, dmat4x3, and dmat4 may count as 365 consuming twice as many attributes as equivalent single-precision types. 366 While these types use the same number of generic attributes as their 367 single-precision equivalents, implementations are permitted to consume two 368 single-precision vectors of internal storage for each three- or 369 four-component double-precision vector. 370 371 (extend the list of types in the first paragraph, p. 88) 372 ... UNSIGNED_INT_VEC3, UNSIGNED_INT_VEC4, DOUBLE, DOUBLE_VEC2, 373 DOUBLE_VEC3, DOUBLE_VEC4, DOUBLE_MAT2, DOUBLE_MAT3, DOUBLE_MAT4, 374 DOUBLE_MAT2x3, DOUBLE_MAT2x4, DOUBLE_MAT3x2, DOUBLE_MAT3x4, DOUBLE_MAT4x2, 375 or DOUBLE_MAT4x3. 376 377 (add the following entries to table 2.13: OpenGL Shading Language type 378 tokens returned by GetActiveUniform and GetActiveUniformsiv, and 379 corresponding shading language keywords declaring each such type., p. 96) 380 381 Type Name Token | Keyword 382 --------------------------------- 383 DOUBLE | double 384 DOUBLE_VEC2 | dvec2 385 DOUBLE_VEC3 | dvec3 386 DOUBLE_VEC4 | dvec4 387 DOUBLE_MAT2 | dmat2 388 DOUBLE_MAT3 | dmat3 389 DOUBLE_MAT4 | dmat4 390 DOUBLE_MAT2x3 | dmat2x3 391 DOUBLE_MAT2x4 | dmat2x4 392 DOUBLE_MAT3x2 | dmat3x2 393 DOUBLE_MAT3x4 | dmat3x4 394 DOUBLE_MAT4x2 | dmat4x2 395 DOUBLE_MAT4x3 | dmat4x3 396 397Additions to Chapter 3 of the OpenGL 3.2 (Compatibility Profile) Specification 398(Rasterization) 399 400 None. 401 402Additions to Chapter 4 of the OpenGL 3.2 (Compatibility Profile) Specification 403(Per-Fragment Operations and the Frame Buffer) 404 405 None. 406 407Additions to Chapter 5 of the OpenGL 3.2 (Compatibility Profile) Specification 408(Special Functions) 409 410 Modify Section 5.4.1, Commands Not Usable in Display Lists, p. 358 411 412 (add to "Vertex arrays" list) VertexAttribLPointer, and 413 VertexArrayVertexAttribLOffsetEXT. 414 415 (note: GetVertexAttribL* commands are also not allowed in display lists, 416 but is already covered by blanket language in "Other queries") 417 418 419Additions to Chapter 6 of the OpenGL 3.2 (Compatibility Profile) Specification 420(State and State Requests) 421 422 Modify Section 6.1.15, Shader and Program Queries, p. 384 423 424 (add to the last list of commands, p. 387) 425 426 void GetVertexAttribLdv(uint index, enum pname, double *params); 427 428 (modify the third paragraph, p. 388) The query CURRENT_VERTEX_ATTRIB 429 returns the current value for the generic attribute 430 <index>. GetVertexAttribdv and GetVertexAttribfv read and return the 431 current attribute values as four single-precision floating-point values; 432 GetVertexAttribiv reads them as floating-point values and converts them to 433 four integer values; GetVertexAttribIiv reads and returns them as signed 434 integers; GetVertexAttribIuiv reads and returns them as four unsigned 435 integers; GetVertexAttribLdv reads and returns them as four double-precision 436 floating-point values. The results of the query are undefined if the 437 current attribute values are read using one data type but were specified 438 using a different one. The error INVALID_OPERATION is generated if index 439 is zero, as there is no current value for generic attribute zero. 440 441 442Additions to Appendix A of the OpenGL 3.2 (Compatibility Profile) 443Specification (Invariance) 444 445 None. 446 447Additions to the AGL/GLX/WGL Specifications 448 449 None. 450 451Modifications to The OpenGL Shading Language Specification, Version 1.50 452(Revision 09) 453 454 Including the following line in a shader can be used to control the 455 language features described in this extension: 456 457 #extension GL_ARB_vertex_attrib_64bit : <behavior> 458 459 where <behavior> is as specified in section 3.3. 460 461 New preprocessor #defines are added to the OpenGL Shading Language: 462 463 #define GL_ARB_vertex_attrib_64bit 1 464 465 466 Modify Section 4.3.4, Inputs, p. 31 467 468 (modify third paragraph of the section, p. 31, allowing double-precision 469 vertex shader inputs) ... Vertex shader inputs can only be single- or 470 double-precision floating-point scalars, vectors, or matrices, or signed 471 and unsigned integers and integer vectors. Vertex shader inputs can also 472 form arrays of these types, but not structures. 473 474 475GLX Protocol 476 477 !!! TBD !!! 478 479Dependencies on OpenGL 3.1 and OpenGL 3.2 480 481 When using an OpenGL 3.1 context without support for the ARB_compatibility 482 extension or the core profile of OpenGL 3.2, remove the pseudocode 483 describing the operation of ArrayElement. The core profile specifies 484 commands like DrawArrays and DrawElements more concisely. Additionally, 485 remove edits relevant to (deleted) display list functionality. 486 487Dependencies on EXT_direct_state_access 488 489 If EXT_direct_state_access is not supported, references to the function 490 VertexArrayVertexAttribLOffsetEXT should be removed. 491 492Dependencies on NV_gpu_shader5 493 494 If NV_gpu_shader5 is not supported, references to the sized data types 495 provided by these extensions (e.g., int8_t, float16_t, u16vec4, f64vec2) 496 in Table X.1 should be removed. The full set of types in the table is 497 provided for completeness. 498 499Dependencies on NV_vertex_attrib_integer_64bit 500 501 The extension NV_vertex_attrib_integer_64bit provides similar 502 VertexAttribL* support for 64-bit signed and unsigned integer vertex 503 shader inputs. That extension also uses the VertexAttribLPointer 504 function to specify 64-bit integer vertex attribute arrays. 505 506 Even if an application only uses 64-bit floating-point values in their 507 vertex shader, NV_vertex_attrib_integer_64bit may still be useful. That 508 extension also provides the VertexAttribLFormatNV function, which allows 509 the "bindless" vertex attribute array support provided by the 510 NV_vertex_buffer_unified_memory extension to be used with 64-bit 511 components, integer or floating-point. 512 513Dependencies on ARB_explicit_attrib_location, ARB_separate_shader_objects, 514OpenGL 3.3, and OpenGL 4.1 515 516 If ARB_explicit_attrib_location (or OpenGL 3.3) is supported, vertex 517 shader input variables (including ones with double-precision components) 518 can select associated generic attributes with an explicit location layout 519 qualifier in lieu of calling BindAttribLocation. If 520 ARB_separate_shader_objects (or OpenGL 4.1) is supported, the layout 521 location qualifier introduced by this extension is extended to apply to 522 inputs for non-vertex shaders and outputs for non-fragment shaders. As 523 this extension requires ARB_gpu_shader_fp64 (or OpenGL 4.0), such inputs 524 and outputs can have double-precision component types. 525 526 When these extensions are supported, there are special rules for the 527 number of locations consumed by "dvec3" and "dvec4" types, which require 528 more storage than is available in a four-component single-precision 529 vector. The rules are: 530 531 * dvec3/dvec4 vertex inputs consume one location (generic vertex 532 attribute), but can count as two vectors for the purposes of 533 determining if the vertex shader consumes too many inputs 534 535 * dvec3/dvec4 inputs and outputs for other stages consume two locations 536 537 The relevant spec edits (modifying language introduced by 538 ARB_explicit_attrib_location) can be found in the 539 ARB_separate_shader_objects extension. 540 541Errors 542 543 For all VertexAttrib* commands, the error INVALID_VALUE is generated if 544 <index> is greater than or equal to MAX_VERTEX_ATTRIBS. 545 546 For VertexAttribLPointer, VertexAttribLFormat, and 547 VertexArrayVertexAttribLOffsetEXT, the error INVALID_VALUE is generated if 548 <index> is greater than or equal to MAX_VERTEX_ATTRIBS. 549 550New State 551 552 None. 553 554New Implementation Dependent State 555 556 None. 557 558Issues 559 560 (1) Should we allow 64-bit double-precision vertex attributes in the OpenGL 561 API? If so, how should we handle 64-bit double-precision values? 562 563 RESOLVED: Yes, we will allow vertex shader inputs to have any scalar 564 or vector type, including sized types. Doubles appear to the API as any 565 other type. The new 'L' versions of the entry points are added to 566 distinguish 64-bit attributes from existing DOUBLE support, where doubles 567 are down-converted to floats. 568 569 (2) How does the handling of 64-bit vertex attribute components in this 570 extension interact with the existing vertex attribute functions that 571 support doubles? 572 573 RESOLVED: While it is possible for fixed-function pipeline 574 implementations to operate directly on doubles, most (if not all) such 575 implementations simply convert doubles to floats. The OpenGL Shading 576 Language has not supported double-precision types to date, so all 577 previous shading language inputs needed to be converted to float by 578 necessity. 579 580 While it would be possible to support the existing double-precision 581 vertex APIs (e.g., VertexAttrib4dv) to feed shading language variables 582 with double-precision types, any such approach involves the prohibitive 583 dynamic typing overhead discussed above. As a result, we chose to 584 create a parallel VertexAttribL* API. 585 586 A similar approach was chosen for the integer attributes in OpenGL 3.0, 587 where there was a pre-existing set of vertex APIs that accepted integers 588 that were converted to floating-point values via straight value 589 conversion or normalization. Re-using existing integer APIs to feed the 590 (new) integer variable types would have required similarly expensive 591 dynamic typing. 592 593 (3) How should we handle vertex attributes for three- and four-component 594 vectors with double-precision components? How do we support these 595 with vertex arrays? 596 597 RESOLVED: Double-precision attributes may consume twice as much 598 internal storage as their single-precision counterparts. For the 599 purposes of determining if a vertex shader uses "too many" attribute 600 vectors in LinkProgram, implementations are permitted (but not required) 601 to count "dvec3" and "dvec4" vertex shader inputs as consuming twice as 602 many input vectors as corresponding single-precision types. 603 Implementations are required to count inputs of type "double" and 604 "dvec2" as a single vector, since these types require no more storage 605 than a "vec4". 606 607 Note however, that for the purposes of mapping inputs to generic vertex 608 attributes, "dvec3" and "dvec4" inputs are counted as consuming one 609 attribute/location. For example, if a vertex shader specifies: 610 611 layout(location=4) in dvec4 attribs[4]; 612 613 the values for the four elements of "attribs" will be taken from vertex 614 attributes 4-7, though "attribs" may be counted as consuming eight 615 vectors worth of attributes. 616 617 (4) Are default values supported for vertex attributes with 64-bit 618 components? 619 620 RESOLVED: No. With existing APIs, calling VertexAttrib3f() defines a 621 FOUR-component vector where the fourth component assumes the value 1.0. 622 No such defaults are provided for 64-bit components; if you load the 623 values of an attribute of type "dvec4" with VertexAttribL3dv(), the 624 value of the fourth component of the attribute variable will be 625 undefined. 626 627 The APIs for loading 64-bit vertex attributes were designed to limit the 628 amount of data type conversion required of the implementation; providing 629 new type-dependent default values runs contrary to that design. 630 631 Note that the original defaults were present in part to accommodate 632 fixed-function vertex and fragment processing, where certain operations 633 were defined in the most general form but reasonable defaults allowed 634 targeted optimizations. For example, vertex transformations were 635 defined to operate on four-component object coordinates, even though 636 four-component input positions are relatively rare. Specifying a 637 default W value of 1.0 allows for a fully-general implementation that 638 doesn't need to do special cases based on the input position, but can 639 still choose to do so as an optimization. Programmable shaders, on the 640 other hand, can easily be written to ignore irrelevant components and 641 substitute constants themselves. 642 643 (5) Should this have a separate extension string entry or be simply 644 implied by extensions such as ARB_gpu_shader5 or ARB_gpu_shader_fp64? 645 646 RESOLVED: Treat as a separate extension, since there may be several 647 such extensions with varying capabilities. 648 649 Additionally, we provide a separate GLSL "#extension" identifier for 650 this extension because ARB_gpu_shader_fp64 was adopted without support 651 for vertex inputs with 64-bit components. 652 653 (6) How does this extension provide 64-bit vertex attribute components for 654 assembly programs supported by NV_gpu_program5? 655 656 RESOLVED: NV_gpu_program5 allows programs to declare input variables 657 with 64-bit components using the "LONG ATTRIB" declaration syntax. 658 These inputs will be matched up against corresponding vertex attributes 659 in the same manner as with GLSL. Also, as with GLSL, the values of each 660 vertex program input must be specified with the correct API function 661 (VertexAttrib* vs. VertexAttribL*). 662 663 664Revision History 665 666 Rev. Date Author Changes 667 ---- -------- -------- ----------------------------------------------- 668 10 06/10/14 Jon Leech Fix typo in name of EXT_direct_state_access 669 (Bug 7704). 670 671 9 08/01/11 pbrown Clarify that "dvec3" and "dvec4" vertex shader 672 inputs consume only a single "location" for the 673 purpose of matching inputs to generic vertex 674 attributes, but may consume two vectors for the 675 purposes of determining if too many attribute 676 vectors are used (bug 7809). Also, add missing 677 language describing the set of attributes 678 consumed by matrix vertex attributes (copied 679 from OpenGL 4.1), with fixes to explicitly 680 address "dmat*" types. Fix issue (3) to match. 681 682 8 01/18/11 Jon Leech Make description of component data types 683 match the commands specifying them 684 (Bug 7235). 685 686 7 07/06/10 pbrown Fix cut-and-paste errors in table mapping 687 GLSL types to API entry points. 688 689 6 04/09/10 pdaniell ARBify the spec for inclusion in OpenGL 4.1. 690 691 5 03/21/10 pbrown Minor wording updates to the spec overview, 692 dependencies, issues, and body. 693 694 4 01/29/10 pbrown Update extension to accomodate the removal of 695 fp64 vertex inputs from ARB_gpu_shader_fp64 (bug 696 5953). The API support for enumerating fp64 697 inputs and the GLSL support allowing fp64 vertex 698 inputs now belongs to this extension. For the 699 GLSL support, we add a "#extension" token to 700 specify that fp64 vertex inputs should be 701 allowed. Also, update several issues. 702 703 3 gsellers Updates based on discussion 704 705 2 gsellers EXT'ify. 706 707 1 pbrown Internal revisions. 708