1Name 2 3 ARB_enhanced_layouts 4 5Name Strings 6 7 GL_ARB_enhanced_layouts 8 9Contact 10 11 John Kessenich (cepheus 'at' frii.com) 12 13Contributors 14 15 Pat Brown, NVIDIA (pbrown 'at' nvidia.com) 16 Christophe Riccio, AMD 17 18Notice 19 20 Copyright (c) 2013 The Khronos Group Inc. Copyright terms at 21 http://www.khronos.org/registry/speccopyright.html 22 23Specification Update Policy 24 25 Khronos-approved extension specifications are updated in response to 26 issues and bugs prioritized by the Khronos OpenGL Working Group. For 27 extensions which have been promoted to a core Specification, fixes will 28 first appear in the latest version of that core Specification, and will 29 eventually be backported to the extension document. This policy is 30 described in more detail at 31 https://www.khronos.org/registry/OpenGL/docs/update_policy.php 32 33Status 34 35 Complete. Approved by the ARB on June 3, 2013. 36 Ratified by the Khronos Board of Promoters on July 19, 2013. 37 38Version 39 40 Last Modified Date: January 10, 2019 41 Revision: 28 42 43Number 44 45 ARB Extension #146 46 47Dependencies 48 49 This extension is written against the OpenGL 4.3 (Compatibility Profile) 50 Specification, dated February 14, 2013. 51 52 This extension is written against the GLSL 4.30 Specification. 53 54 OpenGL 3.1 and GLSL 1.40 or later are required. 55 56 This extension interacts with OpenGL 3.3 and ARB_explicit_attrib_location. 57 58 This extension interacts with OpenGL 4.0 and ARB_vertex_attrib_64bit. 59 60 This extension interacts with OpenGL 4.0 and ARB_transform_feedback3. 61 62 This extension interacts with OpenGL 4.1 and ARB_separate_shader_objects. 63 64 This extension interacts with OpenGL 4.3 and 65 ARB_shader_storage_buffer_object. 66 67 This extension interacts with OpenGL 4.3 and ARB_program_interface_query. 68 69Overview 70 71 This extension adds the following functionality to layout qualifiers, 72 including broadening the API where this functionality is reflected. 73 74 The following are added: 75 76 1) Use compile-time constant expressions. E.g., 77 78 const int start = 6; 79 layout(location = start + 2) int vec4 v; 80 81 2) Specify explicit byte offsets within a uniform or shader storage block. 82 For example, if you want two vec4 variables "batman" and "robin" to 83 appear at byte offsets 0 and 64 in your block, you can say: 84 85 uniform Block { 86 layout(offset = 0) vec4 batman; 87 layout(offset = 64) vec4 robin; 88 }; 89 90 3) Force alignment within a uniform or shader storage block. The previous 91 example could also be expressed: 92 93 uniform Block { 94 vec4 batman; 95 layout(align = 64) vec4 robin; 96 }; 97 98 This says the member 'robin' must start at the next address that is a 99 multiple of 64. It allows constructing the same layout in C and in GLSL 100 without inventing explicit offsets. 101 102 Explicit offsets and aligned offsets can be combined: 103 104 uniform Block { 105 vec4 batman; 106 layout(offset = 44, align = 8) vec4 robin; 107 }; 108 109 would make 'robin' be at the first 8-byte aligned address, starting at 110 44, which is 48. This is more useful when using the *align* at 111 the block level, which will apply to all members. 112 113 4) Specify component numbers to more fully utilize the vec4-slot interfaces 114 between shader outputs and shader inputs. 115 116 For example, you could fit the following 117 118 - an array of 32 vec3 119 - a single float 120 121 into the space of 32 vec4 slots using the following code: 122 123 // consume X/Y/Z components of 32 vectors 124 layout(location = 0) in vec3 batman[32]; 125 126 // consumes W component of first vector 127 layout(location = 0, component = 3) in float robin; 128 129 Further, an array of vec3 and an array of float can be stored 130 interleaved, using the following. 131 132 // consumes W component of 32 vectors 133 layout(location = 0, component = 3) in float robin[32]; 134 135 // consume X/Y/Z components of 32 vectors 136 layout(location = 0) in vec3 batman[32]; 137 138 5) Specify transform/feedback buffers, locations, and widths. For example: 139 140 layout(xfb_buffer = 0, xfb_offset = 0) out vec3 var1; 141 layout(xfb_buffer = 0, xfb_offset = 24) out vec3 var2; 142 layout(xfb_buffer = 1, xfb_offset = 0) out vec4 var3; 143 144 The second line above says to write var2 out to byte offset 24 of 145 transform/feedback buffer 0. (When doing this, output are only 146 captured when xfb_offset is used.) 147 148 To specify the total number of bytes per entry in a buffer: 149 150 layout(xfb_buffer = 1, xfb_stride = 32) out; 151 152 This is necessary if, say, var3 above, which uses bytes 0-11, 153 does not fully fill the buffer, which in this case takes 32 bytes. 154 155 Use of this feature effectively eliminates the need to use previously 156 existing API commands to describe the transform feedback layout. 157 158 6) Allow locations on input and output blocks for SSO interface matching. 159 160 For example: 161 162 layout(location = 4) in block { 163 vec4 batman; // gets location 4 164 vec4 robin; // gets location 5 165 layout(location = 7) vec4 joker; // gets location 7 166 vec4 riddler; // location 8 167 }; 168 169IP Status 170 171 No known IP claims. 172 173New Procedures and Functions 174 175 None. 176 177New Tokens 178 179 Accepted in the <props> array of GetProgramResourceiv: 180 181 LOCATION_COMPONENT 0x934A 182 TRANSFORM_FEEDBACK_BUFFER_INDEX 0x934B 183 TRANSFORM_FEEDBACK_BUFFER_STRIDE 0x934C 184 185 Accepted by the <programInterface> parameter of GetProgramInterfaceiv, 186 GetProgramResourceIndex, GetProgramResourceName, and 187 GetProgramResourceiv: 188 189 TRANSFORM_FEEDBACK_BUFFER // reuse from core 190 191Modifications to the OpenGL 4.3 (Compatibility Profile) Specification 192 193 Modify Section 7.3.1, Program Interfaces, p. 84 194 195 (insert after the TRANSFORM_FEEDBACK_VARYING bullet, p. 86) 196 197 * TRANSFORM_FEEDBACK_BUFFER corresponds to the set of active buffer 198 binding points to which output variables in the 199 TRANSFORM_FEEDBACK_VARYING interface are written. 200 201 (modify next-to-last paragraph, p. 87, to indicate that variables in the 202 TRANSFORM_FEEDBACK_VARYING interface need not be sorted if specified via 203 layout qualifiers) 204 205 The order of the active resource list is implementation-dependent for all 206 interfaces except for TRANSFORM_FEEDBACK_VARYING. If variables in the 207 TRANSFORM_FEEDBACK_VARYING interface were specified using the 208 TransformFeedbackVaryings command, the active resource list will be 209 arranged in the variable order specified in the most recent call to 210 TransformFeedbackVaryings before the last call to LinkProgram. If 211 variables in the TRANSFORM_FEEDBACK_VARYING interface were specified using 212 layout qualifiers in shader code, the order of the active resource list is 213 implementation-dependent. 214 215 (insert after the first paragraph, p. 88) 216 217 For the TRANSFORM_FEEDBACK_BUFFER interface, the list of active buffer 218 binding points is built by identifying each unique binding point to which 219 one or more active output variables will be written in transform feedback 220 mode. Active transform feedback buffers do not have an associated name 221 string. 222 223 (modify "Errors" section at the bottom of p. 89, for 224 GetProgramInterfaceiv, handling the new TRANSFORM_FEEDBACK_BUFFER 225 interface) 226 227 An INVALID_OPERATION error is generated if pname is MAX_NAME_LENGTH and 228 <programInterface> is ATOMIC_COUNTER_BUFFER or TRANSFORM_FEEDBACK_BUFFER, 229 since active atomic counter and transform feedback buffer resources are 230 not assigned name strings. 231 232 An INVALID_OPERATION error is generated if pname is 233 MAX_NUM_ACTIVE_VARIABLES and programInterface is not UNIFORM_BLOCK, 234 SHADER_STORAGE_BLOCK, ATOMIC_COUNTER_BUFFER, or 235 TRANSFORM_FEEDBACK_BUFFER. 236 237 (modify the "Errors" section in the middle of p. 90, for 238 GetProgramResourceIndex, handling the new TRANSFORM_FEEDBACK_BUFFER 239 interface) 240 241 An INVALID_ENUM error is generated if <programInterface> is 242 ATOMIC_COUNTER_BUFFER or TRANSFORM_FEEDBACK_BUFFER, since active atomic 243 counter and transform feedback buffer resources are not assigned name 244 strings. 245 246 (modify the "Errors" section in the middle of p. 90, for 247 GetProgramResourceName, handling the new TRANSFORM_FEEDBACK_BUFFER 248 interface) 249 250 An INVALID_ENUM error is generated if <programInterface> is 251 ATOMIC_COUNTER_BUFFER or TRANSFORM_FEEDBACK_BUFFER, since active atomic 252 counter and transform feedback buffer resources are not assigned name 253 strings. 254 255 (modify existing entries in table 7.2, "GetProgramResourceiv properties 256 and supported interfaces", pp. 92-93) 257 258 Property Supported Interfaces 259 ------------------- ---------------------------------------- 260 NAME_LENGTH all but ATOMIC_COUNTER_BUFFER and 261 TRANSFORM_FEEDBACK_BUFFER 262 263 OFFSET UNIFORM, BUFFER_VARIABLE, 264 TRANSFORM_FEEDBACK_VARYING 265 266 BLOCK_INDEX, UNIFORM, BUFFER_VARIABLE 267 ARRAY_STRIDE, 268 MATRIX_STRIDE, 269 IS_ROW_MAJOR 270 271 BUFFER_BINDING UNIFORM_BLOCK, ATOMIC_COUNTER_BUFFER, 272 NUM_ACTIVE_VARIABLES, SHADER_STORAGE_BLOCK, 273 ACTIVE_VARIABLES TRANSFORM_FEEDBACK_BUFFER 274 275 BUFFER_DATA_SIZE UNIFORM_BLOCK, ATOMIC_COUNTER_BUFFER, 276 SHADER_STORAGE_BLOCK 277 278 (add to table 7.2, "GetProgramResourceiv properties and supported 279 interfaces", pp. 92-93) 280 281 Property Supported Interfaces 282 ------------------- ---------------------------------------- 283 LOCATION_COMPONENT PROGRAM_INPUT, PROGRAM_OUTPUT 284 285 TRANSFORM_FEEDBACK_ TRANSFORM_FEEDBACK_VARYING 286 BUFFER_INDEX 287 288 TRANSFORM_FEEDBACK_ TRANSFORM_FEEDBACK_BUFFER 289 BUFFER_STRIDE 290 291 (modify the third paragraph, p. 98) 292 293 For the property OFFSET, a single integer identifying the offset of an 294 active variable is written to <params>. For variables in the UNIFORM and 295 BUFFER_VARIABLE interfaces that are backed by a buffer object, the value 296 written is the offset of that variable relative to the base of the buffer 297 range holding its value. For variables in the TRANSFORM_FEEDBACK_VARYING 298 interface, the value written is the offset in the transform feedback 299 buffer storage assigned to each vertex captured in transform feedback mode 300 where the value of the variable will be stored. Such offsets are 301 specified via the /xfb_offset/ layout qualifier or assigned according to 302 the variables position in the list of strings passed to 303 TransformFeedbackVaryings. Offsets are expressed in basic machine units. 304 For all variables not recorded in transform feedback mode, including the 305 special names "gl_NextBuffer", "gl_SkipComponents1", "gl_SkipComponents2", 306 "gl_SkipComponents3", and "gl_SkipComponents4", -1 is written to <params>. 307 308 (modify the next-to-last paragraph, p. 98) 309 310 For the property BUFFER_BINDING, the index of the buffer binding point 311 associated with the active uniform block, shader storage block, atomic 312 counter buffer, or transform feedback buffer is written to <params>. 313 314 (modify the second and third paragraphs, p. 99) 315 316 For the property NUM_ACTIVE_VARIABLES, the number of active variables 317 associated with an active uniform block, shader storage block, atomic 318 counter buffer, or transform feedback buffer is written to <params>. 319 320 For the property ACTIVE_VARIABLES, an array of active variable indices 321 associated with an active uniform block, shader storage block, atomic 322 counter buffer, or transform feedback buffer is written to <params>. The 323 number of values written to params for an active resource is given by the 324 value of the property NUM_ACTIVE_VARIABLES for the resource. 325 326 (insert after the first paragraph, p. 100) 327 328 For the property LOCATION_COMPONENT, a single integer indicating the first 329 component of the location assigned to an active input or output variable 330 is written to <params>. For input and output variables with a component 331 specified by a <layout> qualifier, the specified component is written. 332 For all other input and output variables, the value zero is written. 333 334 (insert after the second paragraph, p. 100) 335 336 For the property TRANSFORM_FEEDBACK_BUFFER_INDEX, a single integer 337 identifying the index of the active transform feedback buffer associated 338 with an active variable is written to <params>. For variables 339 corresponding to the special names "gl_NextBuffer", "gl_SkipComponents1", 340 "gl_SkipComponents2", "gl_SkipComponents3", and "gl_SkipComponents4", -1 341 is written to <params>. 342 343 For the property TRANSFORM_FEEDBACK_BUFFER_STRIDE, a single integer 344 identifying the stride, in basic machine units, between consecutive 345 vertices written to the transform feedback buffer is written to <params>. 346 347 348 Modify Section 7.4.1, Shader Interface Matching, p. 105 349 350 (modify the last bullet of "An output variable is considered to match", 351 adding the 352 353 - the two variables are declared with the same location and component 354 layout qualifiers and match in type and qualification 355 356 (insert a new sentence to the beginning of the last paragraph, p. 105) 357 358 For the purposes of interface matching, variables declared with a location 359 layout qualifier but without a component layout qualifier are considered 360 to have declared a component layout qualifier of zero. Variables or block 361 members declared as structures... 362 363 364 Modify Section 11.1.1, Vertex Attributes, p. 377 365 366 (replace the first two paragraphs, p. 378) 367 368 When an attribute variable declared using one of the scalar or vector data 369 types enumerated in table 11.1 is bound to a generic attribute index <i>, 370 its value(s) are taken from the components of generic attribute <i>. The 371 generic attribute components used depend on the type of the variable and 372 value of the "component" layout qualifier (if any) specified in the 373 variable declaration, as identified in table X.1. An attribute variable 374 declared using a combination of data type and "component" layout qualifier 375 not listed in this table is not supported and will result in shader 376 compilation errors. 377 378 "component" 379 Data type layout qualifier Components used 380 ---------------------- ---------------- --------------- 381 scalar 0 or unspecified x 382 scalar 1 y 383 scalar 2 z 384 scalar 3 w 385 two-component vector 0 or unspecified (x,y) 386 two-component vector 1 (y,z) 387 two-component vector 2 (z,w) 388 three-component vector 0 or unspecified (x,y,z) 389 three-component vector 1 (y,z,w) 390 four-component vector 0 or unspecified (x,y,z,w) 391 392 Table X.1: Generic attribute components accessed by attribute variables 393 394 When an attribute variable declared using a matrix type is bound to a 395 generic attribute index <i>, its values are taken from consecutive generic 396 attributes beginning with generic attribute <i>. Such matrices are 397 treated as an array of column vectors with values taken from the generic 398 attributes identified in table X.2. Individual column vectors are taken 399 from generic attribute components according table X.1, using the vector 400 type from Table X.2 and the "component" layout qualifier (if any) 401 specified in the variable declaration. 402 403 Data type Column vector type Generic attributes used 404 --------------- -------------------- ------------------------ 405 mat2 dmat2 two-component vector i, i+1 406 mat2x3 dmat2x3 three-component vector i, i+1 407 mat2x4 dmat2x4 four-component vector i, i+1 408 mat3x2 dmat3x2 two-component vector i, i+1, i+2 409 mat3 dmat3 three-component vector i, i+1, i+2 410 mat3x4 dmat3x4 four-component vector i, i+1, i+2 411 mat4x2 dmat4x2 two-component vector i, i+1, i+2, i+3 412 mat4x3 dmat4x3 three-component vector i, i+1, i+2, i+3 413 mat4 dmat4 four-component vector i, i+1, i+2, i+3 414 415 Table X.2: Generic attributes and vector types used by column vectors 416 of matrix variables bound to generic attribute index <i>. 417 418 When an attribute variable declared using an array type is bound to 419 generic attribute index <i>, the active array elements are assigned to 420 consecutive generic attributes beginning with generic attribute <i>. The 421 number of attributes and components assigned to each element are 422 determined according to the data type of array elements and "component" 423 layout qualifier (if any) specified in the declaration of the array, as 424 described above. 425 426 427 Modify Section 11.1.2.1, Output Variables (Vertex Shaders), p. 383 428 429 (insert before the third paragraph, p. 384) 430 431 The set of variables to record can be specified in shader text using the 432 "xfb_buffer", "xfb_offset", or "xfb_stride" layout qualifiers. When 433 recording output variables of each vertex in transform feedback mode, a 434 fixed amount of memory is reserved in the buffer bound to each transform 435 feedback buffer binding point. Each output variable recorded is 436 associated with a binding point, specified by the "xfb_buffer" layout 437 qualifier. Each output variable is written to its associated transform 438 feedback binding point at an offset specified by the "xfb_offset" layout 439 qualifier, in basic machine units, relative to the base of the memory 440 reserved for its vertex. The amount of memory reserved in each transform 441 feedback binding point for a single vertex can be specified using the 442 "xfb_stride" layout qualifier. If no "xfb_stride" qualifier is specified 443 for a binding point, the stride is derived by identifying the variable 444 associated with the binding point having the largest offset, and then 445 adding the offset and the size of the variable, in basic machine units. 446 If any variable associated with the binding point contains 447 double-precision floating-point components, the derived stride is aligned 448 to the next multiple of eight basic machine units. If a binding point has 449 no "xfb_stride" qualifier and no associated output variables, its stride 450 is zero. 451 452 (modify third paragraph, p. 384) 453 454 When no "xfb_buffer", "xfb_offset", or "xfb_stride" layout qualifiers are 455 specified, the set of variables to record is specified with the command 456 457 void TransformFeedbackVaryings(uint program, ... 458 459 (replace last paragraph, p. 384) 460 461 The variables in <varyings> are assigned binding points and offsets 462 sequentially, as though each were specified using the "xfb_buffer" and 463 "xfb_offset" layout qualifiers. The strides associated with each binding 464 point are derived by adding the offset and size of the last variable 465 associated with that binding point. The first variable in <varyings> is 466 assigned a binding point and offset of zero. When <bufferMode> is 467 INTERLEAVED_ATTRIBS, each subsequent variable is assigned to the same 468 binding point as the previous variable and an offset equal to the sum of 469 the offset and size of of the previous variable. When <bufferMode> is 470 SEPARATE_ATTRIBS, each subsequent variable is assigned to the binding 471 point following the binding point of the previous variable with an offset 472 of zero. 473 474 Several special identifiers are supported when <bufferMode> is 475 INTERLEAVED_ATTRIBS. These identifiers do not identify output variables 476 captured in transform feedback mode, but can be used to modify the binding 477 point and offsets assigned to subsequent variables. If a string in 478 <varyings> is "gl_NextBuffer", the next variable in <varyings> will be 479 assigned to the next binding point, with an offset of zero. If a string 480 in <varyings> is "gl_SkipComponents1", "gl_SkipComponents2", 481 "gl_SkipComponents3", or "gl_SkipComponents4", the variable is treated as 482 as specifying a one- to four-component floating-point output variable with 483 undefined values. No data will be recorded for such strings, but the 484 offset assigned to the next variable in <varyings> and the stride of the 485 assigned binding point will be affected. 486 487 (modify first paragraph after the errors section, p. 385) 488 489 The state set by TransformFeedbackVaryings or using transform feedback 490 layout qualifiers has no effect on the execution of the program until 491 program is subsequently linked. When LinkProgram is called, the program 492 is linked so that the values of the specified outputs for the vertices of 493 each primitive generated by the GL are written to one or more buffer 494 objects. If the set of output variables to record in transform feedback 495 mode is specified by TransformFeedbackVaryings, a program will fail to 496 link if: 497 498 (insert after the first set of bullets, p. 386) 499 500 If the set of output variables to record in transform feedback mode is 501 specified using layout qualifiers, a program will fail to link if: 502 503 * any pair of variables associated with the same binding point overlap 504 in memory (where the offset of the first variable is less than or 505 equal to the offset of the second, but the sum of the offset and size 506 of the first variable is greater than the offset of the second); 507 508 * any binding point has a stride declared using the "xfb_stride" layout 509 qualifier and the sum of the offset and size of any variable 510 associated with that binding point exceeds the value of this stride; 511 512 * any variable containing double-precision floating-point components 513 514 * has an "xfb_offset" layout qualifier that is not a multiple of 515 eight; or 516 517 * is associated with a binding point with an "xfb_stride" layout 518 qualifier that is not a multiple of eight; 519 520 * the sum of the offset and size of any variable exceeds the maximum 521 stride supported by the implementation (four times the value 522 of MAX_TRANSFORM_FEEDBACK_INTERLEAVED_COMPONENTS); or 523 524 * the "xfb_stride" layout qualifier for any binding point exceeds the 525 maximum stride supported by the implementation. 526 527 (modify the two paragraphs following the bullets, p. 386) 528 529 For transform feedback purposes, each component of outputs declared as 530 double-precision floating-point scalars, vectors, or matrices are 531 considered to consume eight basic machine units, and each component of any 532 other type is considered to consume four basic machine units. 533 534 To determine the set of output variables in a linked program object that 535 will be captured in transform feedback mode and the binding points to 536 which those variables are written, applications can query the properties 537 and active resources of the TRANSFORM_FEEDBACK_VARYING and 538 TRANSFORM_FEEDBACK_BUFFER interfaces. 539 540 (insert before the fourth paragraph, starting with "Additionally, the 541 command" on p. 386) 542 543 If the shader used to record output variables for transform feedback 544 varyings uses the "xfb_buffer", "xfb_offset", or "xfb_stride" layout 545 qualifiers, the values specified by TransformFeedbackVaryings are 546 ignored, and the set of variables captured for transform feedback is 547 instead derived from the specified layout qualifiers. 548 549 550 Modify Section 13.2.2, Transform Feedback Primitive Capture, p. 457 551 552 (split the first paragraph, p. 459, and replace the second half of the 553 paragraph with the following language) 554 555 ... attributes of the subsequent vertices. 556 557 When capturing vertices, the stride associated with each transform 558 feedback binding point indicates the number of basic machine units of 559 storage reserved for each vertex in the bound buffer object. For every 560 vertex captured, each output variable with an assigned transform feedback 561 offset will be written to the storage reserved for the vertex at the 562 associated binding point. When writing output variables that are arrays 563 or structures, individual array elements or structure members are written 564 in order. For vector types, individual components are written in order. 565 For matrix types, outputs are written as an array of column vectors. If 566 any component of an output with an assigned transform feedback offset was 567 not written to by its shader, the value recorded for that component is 568 undefined. The results of writing an output variable to a transform 569 feedback buffer are undefined if any component of that variable would be 570 written at an offset not aligned to the size of the component. When 571 capturing a vertex, any portion of the reserved storage not associated 572 with an output variable with an assigned transform feedback offset will be 573 unmodified. 574 575 (delete the last three paragraphs, p. 459, which describe 576 INTERLEAVED_ATTRIBS and SEPARATE_ATTRIBS mode; this is already handled by 577 the language defining TransformFeedbackAttribs in terms of offsets and 578 strides) 579 580 (modify the first paragraph, p. 460, removing the incorrect reference to 581 "geometry program") 582 583 When using a geometry shader that writes vertices to multiple ... 584 585 (modify the third paragraph, p. 460) 586 587 Any transform feedback binding point used for capturing vertices must have 588 buffer objects bound when BeginTransformFeedback is called. A binding 589 point requires a bound buffer object if and only if its associated stride 590 in the program object used for transform feedback primitive capture is 591 non-zero and the transform feedback buffer is associated with output 592 variables, blocks or block members in the program object. 593 594 Modify Section 15.2.3, Shader Outputs (Fragment Shader Variables), p. 514 595 596 (modify the fifth paragraph, p. 515, making an output variable binding 597 refer to "components of a fragment color") 598 599 The binding of a user-defined output variable to components of a fragment 600 color number can be specified explicitly in shader text or using the 601 command... 602 603 (modify the third paragraph, p. 516) 604 605 When a program is linked, each active user-defined fragment shader output 606 variable will have a binding consisting of a fragment color number, a 607 fragment color index, and a component index. Output variables declared 608 with "location", "component", or "index" layout qualifiers will use the 609 values specified in the shader text. Output variables without such layout 610 qualifiers will use bindings specified by BindFragDataLocationIndexed or 611 BindFragDataLocation, if any. Otherwise, the linker will automatically 612 assign a fragment color number, using any color number not already 613 assigned to another active fragment shader output variable. The fragment 614 color index and component index of an output variable binding will default 615 to zero unless values are explicitly specified by a layout qualifer or 616 BindFragDataLocationIndexed. The properties of an active fragment shader 617 output variable binding can be queried using the command 618 GetProgramResourceiv with a <programInterface> of PROGRAM_OUTPUT and 619 <props> values of LOCATION, LOCATION_INDEX, and LOCATION_COMPONENT. 620 621 When a fragment shader terminates, the value of each active user-defined 622 output variable is written to components of the fragment color output to 623 which it is bound. The set of fragment color components written is 624 determined according to the variable's data type and component index 625 binding, using the mappings in table X.1. For an output variable declared 626 as an array bound to fragment color number <i>, individual active array 627 elements are written to consecutive fragment color numbers beginning with 628 <i>, with the components written determined from the array element's data 629 type and the array variable's component index binding. 630 631 Output binding assignments will cause LinkProgram to fail: 632 633 (modify the third bullet immediately below the previous edit, p. 516, and 634 add a new bullet immediately after it) 635 636 * if two output variables are bound to the same output number and index 637 with overlapping components selected; 638 639 * if two output variables with different component types (signed 640 integer, unsigned integer, or floating-point) are bound to the same 641 output number, even if selected components do not overlap; or 642 643Additions to the OpenGL Shading Language 644 645 Including the following line in a shader can be used to control the 646 language features described in this extension: 647 648 #extension GL_ARB_enhanced_layouts : <behavior> 649 650 where <behavior> is as specified in section 3.3. 651 652 New preprocessor #defines are added to the OpenGL Shading Language: 653 654 #define GL_ARB_enhanced_layouts 1 655 656Additions to Chapter 4 "Variables and Types" of the OpenGL Shading Language 657 658 Section 4.4 "Layout Qualifiers" 659 660 The existing last paragraph already says: 661 662 "More than one layout qualifier may appear in a single declaration. If 663 the same layout-qualifier-name occurs in multiple layout qualifiers 664 for the same declaration, the last one overrides the former ones." 665 666 Expand it to say: 667 668 "More than one layout qualifier may appear in a single declaration. 669 Additionally, the same layout-qualifier-name can occur multiple times 670 within a layout qualifier or across multiple layout qualifiers in the 671 same declaration. When the same layout-qualifier-name occurs 672 multiple times, in a single declaration, the last occurrence overrides 673 the former occurrence(s). Further, if such a layout-qualifier-name 674 will effect subsequent declarations or other observable behavior, it 675 is only the last occurrence that will have any effect, behaving as if 676 the earlier occurrence(s) within the declaration are not present. 677 This is also true for overriding layout-qualifier-names, where one 678 overrides the other (e.g., row_major vs. column_major); only the last 679 occurrence has any effect." 680 681 Section 4.4.1 "Input Layout Qualifiers" 682 683 Change 684 685 "All shaders, except compute shaders, allow input layout location 686 qualifiers on input variable declarations." 687 688 To 689 690 "All shaders, except compute shaders, allow *location* layout qualifiers 691 on input variable declarations, input block declarations, and input 692 block member declarations. Of these, variables and block members 693 (but not blocks) additionally allow the *component* layout qualifier." 694 695 Change 696 697 "The layout qualifier identifier for inputs is 698 699 "layout-qualifier-id 700 location = integer-constant 701 702 "Only one argument is accepted. For example," 703 704 to 705 706 "The layout qualifier identifiers for inputs are 707 708 "layout-qualifier-id 709 location = integral-constant-expression 710 component = integral-constant-expression 711 712 "where integral-constant-expression is defined in Section 4.3.3 713 Constant Expressions as /integral constant expression/" 714 715 "For example," 716 717 Add more examples: 718 719 const int start = 6; 720 layout(location = start + 2) int vec4 v; 721 722 and change the first sentence describing them to 723 724 "will establish that the shader input normal is assigned to vector 725 location number 3 and v is assigned location number 8." 726 727 About 18 other occurrences of "integer-constant" all need to be changed per 728 above to "integral-constant-expression", throughout Sections 4.4.1.2 729 through 4.4.6.2. 730 731 Change 732 733 "If the declared input is a structure, its members will be 734 assigned consecutive locations in the order of declaration, with the 735 first member assigned the location specified for the structure." 736 737 To 738 739 "If the declared input is a structure or block, its members will be 740 assigned consecutive locations in their order of declaration, with the 741 first member assigned the location provided in the layout qualifier. 742 For a structure. It is a compile-time error to use a location 743 qualifier on a member of a structure. For a block, this process 744 applies to the entire block, or until the first member is reached 745 that has a location layout qualifier. When a block member is declared 746 with a location qualifier, its location comes from that qualifier: The 747 member's location qualifier overrides the block-level declaration. 748 Subsequent members are again assigned consecutive locations, based 749 on the newest location, until the next member declared with a *location* 750 layout qualifier. The values used for locations do not have to be 751 declared in increasing order. 752 753 "It is a compile-time error to declare a block with some of its members 754 having a location, but not all. Thus, if a block has no 755 block-level *location* layout qualifier, it is required that either all 756 or none of its members have a *location* layout qualifier." 757 758 Change the next paragraph so it reads 759 760 "The locations consumed by block and structure members are 761 determined..." 762 763 Change the subsequent examples to 764 765 layout(location = 3) in struct S { 766 vec3 a; // gets location 3 767 mat2 b; // gets locations 4 and 5 768 vec4 c[2]; // gets locations 6 and 7 769 layout (location = 8) vec2 A; // ERROR, can't use on struct member 770 } s; 771 772 layout(location = 4) in block { 773 vec4 d; // gets location 4 774 vec4 e; // gets location 5 775 layout(location = 7) vec4 f; // gets location 7 776 vec4 g; // gets location 8 777 layout (location = 1) vec4 h; // gets location 1 778 vec4 i; // gets location 2 779 vec4 j; // gets location 3 780 vec4 k; // ERROR, location 4 already used 781 }; 782 783 Remove the paragraph 784 785 "Location layout qualifiers may be used on input variables declared as 786 structures, but not on individual members. Location layout qualifiers 787 may not be used on input blocks or input block members. Compile-time 788 errors result if these rules are not followed." 789 790 Replace the paragraph (parts of it show up again at the end of this section) 791 792 "A program will fail to link if any two non-vertex shader input 793 variables or block members are assigned to the same location...." 794 795 with part of it's last sentence (keep this here): 796 797 "A program will fail to link if explicit location assignments leave the 798 linker unable to find space for other variables without explicit 799 assignments." 800 801 Add, after the specification for 'location', the following: 802 803 "The *component* qualifier allows the location to be more finely 804 specified for scalars and vectors, down to the individual components 805 within a location that are 806 consumed. It is a compile-time error to use *component* without 807 also specifying *location* (order does not matter). The components 808 within a location are 0, 1, 2, and 3. A variable or block member 809 starting at component N will consume components N, N+1, N+2, ... up 810 through its size. For example: 811 812 // a consumes components 2 and 3 of location 4 813 layout(location = 4, component = 2) vec2 a; 814 815 // b consumes component 1 of location 4 816 layout(location = 4, component = 1) float b; 817 818 // ERROR: c overflows components 2 and 3 819 layout(location = 3, component = 2) vec3 c; 820 821 "If the variable is an array, each element of the array, in order, is 822 assigned to consecutive locations, but all at the same specified 823 component within each location. For example: 824 825 // component 3 in 6 locations are consumed 826 layout(location = 2, component = 3) float d[6]; 827 828 "That is, location 2 component 3 will hold d[0], location 3 component 3 829 will hold d[1], ..., up through location 7 component 3 holding d[5]. 830 831 "This allows packing of two arrays into the same set of locations: 832 833 // e consumes beginning (components 0, 1 and 2) of each of 6 slots 834 layout(location = 0, component = 0) vec3 e[6]; 835 836 // f consumes last component of the same 6 slots 837 layout(location = 0, component = 3) float f[6]; 838 839 "If applying this to an array of arrays, all levels of arrayness are 840 removed to get to the elements that are assigned per location to the 841 specified component. These non-arrayed elements will fill the locations 842 in the order specified for arrays of arrays in section 4.1.9 "Arrays". 843 844 "It is a compile-time error to apply the *component* qualifier to a 845 matrix, a structure, a block, or an array containing any of these. 846 It is a link-time error to specify different components for the same 847 variable within a program. 848 849 "/Location aliasing/ is causing two variables or block members to have 850 the same location number. /Component aliasing/ is assigning the same 851 (or overlapping) component numbers for two location aliases. (Recall 852 if component is not used, component's are assigned starting with 0.) 853 With one exception, location aliasing is allowed only if it does not 854 cause component aliasing; it is a compile-time or link-time error to 855 cause component aliasing. Further, when location aliasing, the aliases 856 sharing the location must have the same underlying numerical type 857 (floating-point or integer) and the same auxiliary storage and 858 interpolation qualification. The one exception where component aliasing 859 is permitted is for two input variables (not block members) to a vertex 860 shader, which are allowed to have component aliasing. This 861 vertex-variable component aliasing is intended only to support vertex 862 shaders where each execution path accesses at most one input per each 863 aliased component. Implementations are permitted, but not required, to 864 generate link-time errors if they detect that every path through the 865 vertex shader executable accesses multiple inputs aliased to any single 866 component." 867 868 Section 4.4.2 "Output Qualifiers" 869 870 Change 871 872 "All shaders, except compute shaders, allow location output layout 873 qualfiers on output variable declarations." 874 875 To 876 877 "As with input layout qualifiers, all shaders except compute shaders 878 allow *location* layout qualifiers on output variable declarations, 879 output block declarations, and output block member declarations. Of 880 these, variables and block members (but not blocks) additionally 881 allow the *component* layout qualifier." 882 883 And add the layout-qualifier-id: 884 885 component = integer-constant-expression 886 887 Following that, add this new paragraph: 888 889 "The usage and rules for using the *component* qualifier, and applying 890 *location* qualifier to blocks and structures, are as described in 891 section 4.4.1 "Input Layout Qualifiers". Additionally, for fragment 892 shader outputs, if two variables are placed within the same location, 893 they must have the same underlying type (floating-point or integer). 894 No component aliasing of output variables or members is allowed." 895 896 Remove the second (redundant) 897 898 location = integer-constant 899 900 Add a new section 4.4.2.1 "Transform Feedback Layout Qualifiers" 901 902 "The vertex, tessellation, and geometry stages allow shaders to control 903 transform feedback. When doing this, shaders will dictate which 904 transform feedback buffers are in use, which output variables will be 905 written to which buffers, and how each buffer is laid out. To 906 accomplish this, shaders allow the following layout qualifier identifiers 907 on output declarations: 908 909 layout-qualifier-id 910 xfb_buffer = integral-constant-expression 911 xfb_offset = integral-constant-expression 912 xfb_stride = integral-constant-expression 913 914 "Any shader making any static use (after preprocessing) of any of these 915 *xfb_* qualifiers will cause the shader to be in a transform feedback 916 capturing mode and hence responsible for describing the transform feedback 917 setup. This mode will capture any output selected by 918 *xfb_offset*, directly or indirectly, to a transform feedback buffer. 919 920 "The *xfb_buffer* qualifier specifies which transform feedback buffer will 921 capture those outputs selected with *xfb_offset*. The *xfb_buffer* 922 qualifier can be applied to the qualifier out, to output variables, to 923 output blocks, and to output block members. Shaders in the transform 924 feedback capturing mode have an initial global default of 925 926 layout(xfb_buffer = 0) out; 927 928 "This default can be changed by declaring a different buffer with xfb_buffer 929 on the interface qualifier out. This is the only way the global default can 930 be changed. When a variable or output block is declared without an 931 xfb_buffer qualifier, it inherits the global default buffer. When a variable 932 or output block is declared with an xfb_buffer qualifier, it has that 933 declared buffer. All members of a block inherit the block's buffer. A 934 member is allowed to declare an xfb_buffer, but it must match the buffer 935 inherited from its block, or a compile-time error results. 936 937 "The *xfb_buffer* qualifier follows the same conventions, behavior, 938 defaults, and inheritance rules as the qualifier stream, and the examples 939 for stream apply here as well. This includes a block's inheritance of the 940 current global default buffer, a block member's inheritance of the block's 941 buffer, and the requirement that any *xfb_buffer* declared on a block 942 member must match the buffer inherited from the block. 943 944 layout(xfb_buffer=2, xfb_offset=0) out block { // block's buffer is 2 945 layout(xfb_buffer = 2) vec4 v; // okay, matches the inherited 2 946 layout(xfb_buffer = 3) vec4 u; // ERROR, mismatched buffer 947 vec4 w; // inherited 948 }; 949 layout (xfb_offset=16) out vec4 t; // initial default is buffer 0 950 layout (xfb_buffer=1) out; // new global default of 1 951 out block { // block has buffer 1 952 vec4 x; // x has buffer 1 (not captured) 953 layout(xfb_buffer = 1) vec4 y; // okay (not captured) 954 layout(xfb_buffer = 0) vec4 z; // ERROR, mismatched buffer 955 }; 956 layout(xfb_offset=0) out vec4 g; // g has buffer 1 957 layout(xfb_buffer=2) out vec4 h; // does not change global default 958 layout(xfb_offset=16) out vec4 j; // j has buffer 1 959 960 "Note this means all members of a block that go to a transform feedback 961 buffer will go to the same buffer. 962 963 "It is a compile-time error to specify an *xfb_buffer* that is greater than 964 the implementation-dependent constant gl_MaxTransformFeedbackBuffers. 965 966 "The *xfb_offset* qualifier assigns a byte offset within a transform 967 feedback buffer. Only variables, block members, or blocks can be qualified 968 with *xfb_offset*. If a block is qualified with *xfb_offset*, all its 969 members are assigned transform feedback buffer offsets. If a block is 970 not qualified with *xfb_offset*, any members of that block not qualified 971 with an *xfb_offset* will not be assigned transform feedback buffer 972 offsets. Only variables and block members that are assigned offsets will 973 be captured (thus, a proper subset of a block can be captured). Each time 974 such a variable or block member is written in a shader, the written value 975 is captured at the assigned offset. If such a block member or variable is 976 not written during a shader invocation, the buffer contents at the assigned 977 offset will be undefined. Even if there are no static writes to a variable 978 or member that is assigned a transform feedback offset, the space is still 979 allocated in the buffer and still affects the stride. 980 981 "Variables and block members qualified with *xfb_offset* can be scalars, 982 vectors, matrices, structures, and (sized) arrays of these. The offset must be 983 a multiple of the size of the first component of the first qualified variable 984 or block member, or a compile-time error results. Further, if applied to 985 an aggregate containing a double, the offset must also be a multiple of 8, 986 and the space taken in the buffer will be a multiple of 8. The given 987 offset applies to the first component of the first member of the qualified 988 entity. Then, within the qualified entity, subsequent components are each 989 assigned, in order, to the next available offset aligned to a multiple of 990 that component's size. Aggregate types are flattened down to the component 991 level to get this sequence of components. It is a compile-time error to 992 apply xfb_offset to the declaration of an unsized array. 993 994 "The *xfb_stride* qualifier specifies how many bytes are consumed by each 995 captured vertex. It applies to the transform feedback buffer for that 996 declaration, whether it is inherited or explicitly declared. It can be 997 applied to variables, 998 blocks, block members, or just the qualifier out. If the buffer is 999 capturing any double-typed outputs, the stride must be a multiple of 8, 1000 otherwise it must be a multiple of 4, or a compile-time or link-time error 1001 results. It is a compile-time or link-time error to have any *xfb_offset* 1002 that overflows *xfb_stride*, whether stated on declarations before or 1003 after the *xfb_stride*, or in different compilation units. While 1004 *xfb_stride* can be declared multiple times for the same buffer, it is a 1005 compile-time or link-time error to have different values specified for the 1006 stride for the same buffer. 1007 1008 "For example: 1009 1010 // buffer 1 has 32-byte stride 1011 layout (xfb_buffer = 1, xfb_stride = 32) out; 1012 1013 // same as previous example; order within layout does not matter 1014 layout (xfb_stride = 32, xfb_buffer = 1) out; 1015 1016 // everything in this block goes to buffer 0 1017 layout (xfb_buffer = 0, xfb_stride = 32) out block1 { 1018 layout (xfb_offset = 0) vec4 a; // a goes to byte offset 0 of buffer 0 1019 layout (xfb_offset = 16) vec4 b; // b goes to offset 16 of buffer 0 1020 }; 1021 1022 layout (xfb_buffer = 1, xfb_offset = 12) out block2 { 1023 vec4 v; // v will be written to byte offsets 12 through 27 of buffer 1 1024 float u; // u will be written to offset 28 1025 layout(xfb_offset = 40) vec4 w; 1026 vec4 x; // x will be written to offset 56, the next available offset 1027 }; 1028 1029 layout (xfb_buffer = 2, xfb_stride = 32) out block3 { 1030 layout (xfb_offset = 12) vec3 c; 1031 layout (xfb_offset = 24) vec3 d; // ERROR, requires stride of 36 1032 layout (xfb_offset = 0) vec3 g; // okay, increasing order not required 1033 }; 1034 1035 "When no *xfb_stride* is specified for a buffer, the stride of a buffer will 1036 be the smallest needed to hold the variable placed at the highest offset, 1037 including any required padding. For example: 1038 1039 // if there no other declarations for buffer 3, it has stride 32 1040 layout (xfb_buffer = 3) out block4 { 1041 layout (xfb_offset = 0) vec4 e; 1042 layout (xfb_offset = 16) vec4 f; 1043 }; 1044 1045 "The resulting stride (implicit or explicit) must be less than or equal to 1046 the implementation-dependent constant 1047 gl_MaxTransformFeedbackInterleavedComponents." 1048 1049 Section 4.4.2.1 Tessellation Control Outputs 1050 1051 Insert in front of the first sentence: 1052 1053 "Other than for the transform feedback layout qualifiers, 1054 1055 Section 4.4.5 "Uniform and Shader Storage Blocks" 1056 1057 Add offset and align to the list, making it be 1058 1059 layout-qualifier-id 1060 shared 1061 packed 1062 std140 1063 std430 1064 row_major 1065 column_major 1066 binding = integral-constant-expression 1067 offset = integral-constant-expression 1068 align = integral-constant-expression 1069 1070 Modify the paragraph starting soon after as "Default layouts..." to read: 1071 1072 "Default layouts for shared, packed, std140, std430, row_major, and 1073 column_major are established at global scope for uniform blocks as" 1074 1075 At the end of the section, add descriptions of these: 1076 1077 "The *offset* qualifier can only be used on block members of blocks 1078 declared with *std140* or *std430* layouts. 1079 The *offset* qualifier forces the qualified member to start at or after the 1080 specified integral-constant-expression, which will be its byte offset 1081 from the beginning of the buffer. It is a compile-time error to 1082 specify an *offset* that is smaller than the offset of the previous 1083 member in the block or that lies within the previous member of the 1084 block. Two blocks linked together in the same program with the same 1085 block name must have the exact same set of members qualified with 1086 *offset* and their integral-constant-expression values must be the 1087 same, or a link-time error results. The specified offset must be a 1088 multiple of the base alignment of the type of the block member it 1089 qualifies, or a compile-time error results. 1090 1091 "The *align* qualifier can only be used on blocks or block members, and 1092 only for blocks declared with *std140* or *std430* layouts. The *align* 1093 qualifier makes the start of each block member have a minimum byte 1094 alignment. It does not affect the internal layout within each member, 1095 which will still follow the std140 or std430 rules. The specified 1096 alignment must be a power of 2, or a compile-time error results. 1097 1098 "The /actual alignment/ of a member will be the greater of the specified 1099 *align* alignment and the standard (e.g., *std140*) base alignment for the 1100 member's type. The /actual offset/ of a member is computed as follows: 1101 If *offset* was declared, start with that offset, otherwise start with the 1102 next available offset. If the resulting offset is not a multiple of the 1103 /actual alignment/, increase it to the first offset that is a multiple of 1104 the /actual alignment/. This results in the /actual offset/ the member 1105 will have. 1106 1107 "When *align* is applied to an array, it effects only the start of the 1108 array, not the array's internal stride. Both an *offset* and an *align* 1109 qualifier can be specified on a declaration. 1110 1111 "The *align* qualifier, when used on a block, has the same effect as 1112 qualifying each member with the same *align* value as declared on the 1113 block, and gets the same compile-time results and errors as if this had 1114 been done. As described in general earlier, an individual member can 1115 specify its own *align*, which overrides the block-level *align*, but 1116 just for that member." 1117 1118 Section 4.5.1 "4.5.1 Redeclaring Built-in Interpolation Variables in the Compatibility Profile" 1119 1120 Modify the paragraph starting "Ideally, these are redeclared..." to read 1121 1122 "Ideally, these are redeclared as part of the redeclaration of an interface 1123 block, as described in section 7.1.1 `Compatibility Profile Built-In Language 1124 Variables'. However, for the above purpose, they can be redeclared as 1125 individual variables at global scope, outside an interface block. Such 1126 redeclarations also allow adding the transform-feedback qualifiers 1127 xfb_buffer, xfb_stride, and xfb_offset to output variables. (Using 1128 xfb_buffer on a variable does not change the global default buffer.)... 1129 <rest of paragraph>." 1130 1131 Section 7.1 "Built-In Language Variables" 1132 1133 Near the end of this section, around 2nd to last paragraph, which is: 1134 1135 "This establishes the output interface the shader will use with the 1136 subsequent pipeline stage. It must be a subset of the built-in 1137 members of gl_PerVertex." 1138 1139 Add the following: 1140 1141 "Such a redeclaration can also add the invariant qualifier, interpolation 1142 qualifiers, and the layout qualifiers xfb_offset, xfb_buffer, and xfb_stride. 1143 It can also add an array size for unsized arrays. For example: 1144 1145 out layout(xfb_buffer = 1, xfb_stride = 16) gl_PerVertex { 1146 vec4 gl_Position; 1147 layout(xfb_offset = 0) float gl_ClipDistance[4]; 1148 }; 1149 1150 "Other layout qualifiers, like location, cannot be added to such a 1151 redeclaration, unless specifically stated." 1152 1153Examples: 1154 1155 layout(std140) uniform block { 1156 vec4 a; 1157 layout(offset = 20) vec3 b; // b takes offsets 20-31 1158 layout(offset = 28) vec2 c; // ERROR, lies within previous member 1159 layout(offset = 36) vec2 d; // d takes offsets 36-43 1160 layout(align = 16) float e; // e takes offsets 48-51 1161 layout(align = 2) double f; // f takes offsets 56-63 1162 layout(align = 6) double g; // ERROR, 6 is not a power of 2 1163 layout(offset = 68) float h; // h takes offsets 64-71 1164 layout(align = 16) dvec3 i; // i takes offsets 80-103 1165 layout(offset = 105, align = 4) float i; // i takes offsets 108-111 1166 };" 1167 1168 1169Additions to Chapter 7.3 "Built-In Constants" of the OpenGL Shading Language 1170 1171 Add 1172 1173 const int gl_MaxTransformFeedbackBuffers = 4; 1174 const int gl_MaxTransformFeedbackInterleavedComponents = 64; 1175 1176Additions to Chapter 9 "Shading Language Grammar for Core Profile" of the OpenGL Shading Language 1177 1178 Change 1179 1180 IDENTIFIER EQUAL INTCONSTANT 1181 1182 to 1183 IDENTIFIER EQUAL constant_expression 1184 1185Additions to the AGL/EGL/GLX/WGL Specifications 1186 1187 None 1188 1189GLX Protocol 1190 1191 None 1192 1193Dependencies on OpenGL 3.3 and ARB_explicit_attrib_location 1194 1195 If neither OpenGL 3.3 nor ARB_explicit_attrib_location are supported, new 1196 "location" and "component" layout qualifier support for vertex shader 1197 inputs and fragment shader outputs is not supported. 1198 1199Dependencies on OpenGL 4.0 and ARB_vertex_attrib_64bit 1200 1201 If neither OpenGL 4.0 nor ARB_vertex_attrib_64bit is supported, references 1202 to double-precision attribute variables should be removed. 1203 1204Dependencies on OpenGL 4.0 and ARB_transform_feedback3 1205 1206 If neither OpenGL 4.0 nor ARB_transform_feedback3 are supported, only a 1207 single binding point can be used for transform feedback using 1208 INTERLEAVED_ATTRIBS, including the new layout qualifier approach. It will 1209 be a compile-time error to use an "xfb_buffer" layout qualifier with a 1210 value other than zero and the value of the implementation-dependent GLSL 1211 constant gl_MaxTransformFeedbackBuffers will be 1. 1212 1213Dependencies on OpenGL 4.1 and ARB_separate_shader_objects 1214 1215 If neither OpenGL 4.1 nor ARB_separate_shader_objects are supported, new 1216 "location" and "component" layout qualifier support for inputs and outputs 1217 other than vertex shader inputs and fragment shader outputs is not 1218 supported. 1219 1220Dependencies on OpenGL 4.3 and ARB_shader_storage_buffer_object 1221 1222 If neither OpenGL 4.3 nor ARB_shader_storage_buffer_object is supported, 1223 references to shader storage blocks should be removed. 1224 1225Dependencies on OpenGL 4.3 and ARB_program_interface_query 1226 1227 If neither OpenGL 4.3 nor ARB_program_interface_query is supported, edits 1228 to section 7.3.1 and the corresponding tokens should be removed. Add an 1229 edit to the spec language describing GetTransformFeedbackVarying to 1230 indicate that when layout qualifiers are used to specify transform 1231 feedback offsets, the set of active transform feedback variables 1232 enumerated by GetTransformFeedbackVarying and related APIs appears in 1233 arbitrary order. 1234 1235 1236Errors 1237 1238 No new API errors. 1239 1240New State 1241 1242 Modify Table 23.53, Program Object Resource State (cont'd) 1243 1244 Initial 1245 Get Value Type Get Command Value Description Sec. 1246 ----------------------- ---- ----------- ------- ------------------------ ----- 1247 LOCATION_COMPONENT Z+ GetProgram- - location component 7.3.1 1248 Resourceiv assigned to active 1249 resource 1250 1251New Implementation Dependent State 1252 1253 None. 1254 1255Conformance Tests 1256 1257 TBD 1258 1259Issues 1260 1261 1) Do we need a sizeof() operator to aid in assigning layout locations? 1262 Would it need to be queried from the app as well? 1263 1264 Aligning based on the size of previous member is what the system already 1265 does. Do we have a use case that needs custom packing following a 1266 structure, which cannot be handled by an *align* layout identifier? 1267 1268 RESOLUTION: No. 1269 1270 2) Do we need to allow layout locations to be placed on blocks? 1271 1272 Discussion: Yes, for SSO matching by location. But, do we still 1273 need them on members? A block could still be a well-defined block 1274 of memory, and if an interface is mixing/matching content of a block 1275 it seems they put the wrong things together in a block. 1276 1277 RESOLUTION: Add for members for symmetry with UBOs and some utility 1278 as well. Order doesn't matter. 1279 1280 3) Do we need to support discovery of the current offset? E.g., 1281 1282 layout(offset = currentOffset + 3) 1283 1284 RESOLUTION: No. 1285 1286 4) Should we add a component-space for layout locations, which is no longer 1287 vec4 centric, but purely component centric? This is perhaps difficult 1288 as an add-on feature, but rather needs the specs as a whole to drop the 1289 vec4 nature of inputs/outputs. 1290 1291 RESOLUTION: No. This is deferred until a future release that can make 1292 a larger change in this area, e.g., wholly drop the vec4 slot nature of 1293 inputs/outputs. 1294 1295 5) Instead of dynamic selection of outputs for transform/feedback, use 1296 locations. 1297 1298 RESOLUTION: Use syntax in the shader layout blocks, not an entry point 1299 in the API. Either "layout(transformfeedback: var1, var2 var3) out;" 1300 or tag individual members. Applies to both inside and outside blocks. 1301 1302 6) Is it an error to specify an *offset* that is not naturally aligned? 1303 1304 RESOLUTION: Yes, all offsets should be naturally aligned, but see 1305 issue 10: it is natural alignment of the type, not the component. 1306 1307 7) Is there an error at some point if an xfb_buffer is not valid? There 1308 are two cases here A) the buffer number is valid, B) the buffer number 1309 is out of range. 1310 1311 RESOLVED A) No, there is no error, it is valid because the shader said so. 1312 1313 RESOLVED B) This should be a compile-time or link-time error. 1314 1315 8) What API changes are needed to support component locations? There is 1316 currently no mention of stages in the specification language above, 1317 implying all stages' inputs and outputs can specify component 1318 locations. Probably, we either need to drop input components to 1319 the vertex stage and output components from the fragment stage, or 1320 consider API changes needed to support them. 1321 1322 RESOLUTION: Behavior is well-defined for all stages. Need to broaden 1323 query functions to include component numbers. 1324 1325 9) How do we keep xfb buffers within implementation-dependent widths? 1326 Is this known at compile time? 1327 1328 RESOLUTION: The actual stride of the buffer is determined by the stride in 1329 the shader, overriding any API settings. However, it is a link-time 1330 error to go over the limits of either 1331 1332 MAX_TRANSFORM_FEEDBACK_INTERLEAVED_COMPONENTS 1333 1334 GLSL only needs to include the limits for interleaved components. 1335 1336 10) For uniform-like buffers only: might want offset of a vec3 to be vec4 1337 aligned, not just component-sized aligned. Is there a portable rule? 1338 Or implementation-dependent rule? 1339 1340 RESOLUTION: Alignments will be multiples of the base alignment of the 1341 member's type. 1342 1343 11) The location associated with a vertex shader input variable or fragment 1344 shader output variable can be specified in the shader using a location 1345 layout qualifier or in the OpenGL API using commands such as 1346 BindAttribLocation and BindFragDataLocation. Should we provide new 1347 variants of the OpenGL API commands (e.g., BindAttribLocationComponent) 1348 allowing applications to specify components with locations? 1349 1350 RESOLVED: No. 1351 1352 12) Vertex shader input and fragment shader output variables declared 1353 without a location layout qualifier will have a location assigned by 1354 the compiler. What components will be assigned to such variables? 1355 1356 RESOLVED: All variables declared without a 'location' layout 1357 qualifier will be assigned a 'component' value of zero. The first 1358 component of any such vertex input variable will be taken from the 1359 first component of the corresponding generic attribute. The first 1360 component of any such fragment output variable will be written to the 1361 first component of corresponding fragment color. 1362 1363 If we allowed to compiler to automatically assign vertex input or 1364 fragment output variables to components other than zero, it could 1365 avoid link errors in cases where a shader requires more locations than 1366 the implementation supports. However, such a change would break 1367 existing applications that query the locations of their input or 1368 output variables, since they wouldn't be expecting component 1369 assignments other than zero. If we really wanted to support this, 1370 we'd probably need a directive in the shader indicating that the 1371 compiler can assign to arbitrary components. 1372 1373 13) How should we allow applications to query the components associated 1374 with shader input and output variables? 1375 1376 RESOLVED: Extend the generic ARB_program_interface_query (OpenGL 1377 4.3) active resource query API GetProgramResourceiv by providing a new 1378 property LOCATION_COMPONENT. This will query the component associated 1379 with a location assignment, in the same way that the existing LOCATION 1380 and LOCATION_INDEX properties query the location and location index 1381 numbers. 1382 1383 14) OpenGL 4.3 also includes the queries GetProgramResourceLocation and 1384 GetProgramResourceLocationIndex to directly query the location and 1385 location index of a named variable. Should we provide a similar query 1386 GetProgramResourceLocationComponent for location components? 1387 1388 RESOLVED: No. 1389 1390 ARB_program_interface_query provided the GetProgramResourceLocation 1391 entry point to serve as a generic version of pre-4.3 entry points such 1392 as GetUniformLocation, and to a lesser extent GetActiveAttrib and 1393 GetFragDataLocation. These entry points, particularly 1394 GetUniformLocation, are commonly used. We also provided 1395 GetProgramResourceLocationIndex to query the much less commonly-used 1396 location index, mostly for completeness. Both commands are simply 1397 short-cuts; it's possible for an application to perform such queries 1398 by calling GetProgramResourceIndex to map a variable name to an active 1399 resource index and then calling GetProgramResourceiv to query the 1400 location or location index. If we care about full orthogonality, we 1401 should add a new GetProgramResourceComponent command. If not, 1402 applications could still query component bindings with the sequence 1403 above. 1404 1405 Since the only way to assign non-zero component indices to input or 1406 output variables is via explicit shader text, these queries seem less 1407 important. In earlier versions of OpenGL, the compiler always 1408 assigned the locations of uniforms, and it was always necessary to 1409 query their locations to perform an update. 1410 1411 15) OpenGL 4.3 also includes older APIs to query the locations of vertex 1412 shader inputs and fragment shader outputs (GetActiveAttrib, 1413 GetFragDataLocation, GetFragDataIndex). Should we provide similar 1414 queries for location components? 1415 1416 RESOLVED: No. We added the generic ARB_program_interface_query 1417 feature to OpenGL 4.3 so we didn't have to keep adding new APIs and 1418 tokens for every combination of resource type and property. 1419 1420 16) For active vertex shader inputs and fragment shader outputs, what 1421 happens if two variables with different basic component types are 1422 bound to different components of the same generic attribute or 1423 fragment color output? 1424 1425 RESOLVED: For fragment shader outputs, generate a link error. For 1426 vertex shader inputs, no link error occurs. However, the values of 1427 any vertex shader input not matching the attribute type programmed in 1428 the API (via VertexAttrib* or VertexAttrib*Pointer) will be undefined. 1429 1430 In unextended OpenGL 4.3, we already require that the generic 1431 attribute associated with a vertex shader input variable be specified 1432 using the same component type as the variable. Additionally, we 1433 require that the framebuffer attachments receiving a fragment output 1434 color must have the same component type as the output variable. In 1435 either case, values are undefined to avoid the overhead of a mandatory 1436 draw-time error check based on frequently-changed vertex attribute 1437 values. In code like the following: 1438 1439 layout(location=3) in float var1; 1440 layout(location=4) in int var2; 1441 1442 the value of <var1> is undefined if generic attribute 3 isn't 1443 specified with floating-point values and the value of <var2> is 1444 undefined if generic attribute 4 isn't specified with integer values. 1445 But it's always possible for an application to specify correct 1446 attribute values for each type. 1447 1448 Mismatches due to component layout qualifers have similar problems. 1449 In a vertex shader with the following declarations: 1450 1451 layout(location=3, component=0) in float var1; 1452 layout(location=3, component=1) in int var2; 1453 1454 the vertex shader would want to read the <x> component of generic 1455 attribute 3 as a floating-point value and the <y> component of that 1456 attribute as a signed integer. We provide no way to specify separate 1457 components of a single attribute with a different type, so one of the 1458 values must be undefined if the shader is considered legal. 1459 1460 We chose to make this illegal for fragment shader outputs, since it 1461 can't possibly do the right thing without relying on undefined raw 1462 bit-cast behavior. We do allow this for vertex shader inputs, because 1463 we've supported "aliasing" behavior since OpenGL 2.0. This allows for 1464 an "uber-shader" with variables like: 1465 1466 layout(location=3) in float var1; 1467 layout(location=3) in int var2; 1468 1469 where sometimes it uses <var1> and sometimes <var2>. Since we don't 1470 treat the code above (with overlapping components) as an error, it 1471 would be strange to treat non-overlapping component assignments as an 1472 error. 1473 1474 17) How will applications be able to query the layout of transform 1475 feedback varyings if they are specified in the shader? 1476 1477 RESOLVED: Add the ability to query offset and active buffer 1478 associations for each variable in the TRANSFORM_FEEDBACK_VARYING 1479 interface, which can now be specified by layout qualifier. 1480 Additionally, add a new interface TRANSFORM_FEEDBACK_BUFFER, which 1481 enumerates the set of active binding points used in transform feedback 1482 (similar to the ATOMIC_COUNTER_BUFFER interface for atomic counter 1483 uniforms). 1484 1485 In unextended OpenGL 4.3, transform feedback varyings are specified by 1486 passing a list of name strings to TransformFeedbackVaryings() before 1487 linking, where those name strings include both real variables and 1488 special "marker" variables like "gl_SkipComponents1" and 1489 "gl_NextBuffer". The application can then query back the list of 1490 transform feedback varyings and their properties, including markers, 1491 using the TRANSFORM_FEEDBACK_VARYING interface with the 1492 GetProgramResourceName and GetProgramResourceiv APIs. Additionally, 1493 applications can use the legacy OpenGL 3.0 API 1494 GetTransformFeedbackVarying(). The varyings are enumerated in the 1495 order specified in TransformFeedbackVaryings(), and it's up to the 1496 application to figure out the offsets/buffers assigned to each. 1497 ("Figuring" this out is often unnecessary, since applications have 1498 already specified the variable list.) The special markers need to be 1499 enumerated as variables in this API to allow the applications 1500 applications can figure out the storage. 1501 1502 When using the existing enumeration API with variables with transform 1503 feedback layout qualifiers, the active variables are enumerated in 1504 arbitrary order and offsets/bindings can be queried explicitly. No 1505 special markers like "gl_NextBuffer" are enumerated. 1506 1507 One other option considered was specifying that the linker 1508 reverse-engineer a list of outputs for TransformFeedbackVaryings based 1509 on layout qualifiers and then operate as if that list were provided 1510 directly. For example, if you specified something like: 1511 1512 layout(xfb_buffer=0, xfb_stride=48) out; 1513 layout(xfb_buffer=0, xfb_offset=4) out vec4 batman; 1514 layout(xfb_buffer=2, xfb_offset=0) out vec4 robin; 1515 layout(xfb_buffer=2, xfb_offset=16) out vec3 joker; 1516 1517 this reverse-engineering would build the following list: 1518 1519 gl_SkipComponents1 // first 4 bytes 1520 batman // next 16 bytes 1521 gl_SkipComponents4 // another 16 bytes, still in buffer 0 1522 gl_SkipComponents3 // final 12 bytes, per xfb_stride 1523 gl_NextBuffer 1524 gl_NextBuffer 1525 robin // first 16 bytes in buffer 2 1526 joker // last 12 bytes in buffer 2 1527 1528 Having an API to query offsets and buffers more directly seemed 1529 preferable. 1530 1531 The new API is patterned after the ATOMIC_COUNTER_BUFFER interface, 1532 which also has variables associated with a collection of numbered 1533 binding points. Consider the code above and an implementation that 1534 sorts active binding points and variables by declaration order. The 1535 commands 1536 1537 GetProgramInterface(program, TRANSFORM_FEEDBACK_BUFFER, 1538 ACTIVE_RESOURCES, &value); 1539 GetProgramInterface(program, TRANSFORM_FEEDBACK_VARYING, 1540 ACTIVE_RESOURCES, &value); 1541 1542 return 2 (binding points 0 and 2) and 3 ("batman", "robin", and 1543 "joker"). 1544 1545 GetProgramInterface(program, TRANSFORM_FEEDBACK_BUFFER, 1546 MAX_NUM_ACTIVE_VARIABLES, &value); 1547 1548 returns 2 (the two variables "robin" and "joker" associated with 1549 binding point 2). GetProgramResourceiv for the two active binding 1550 points in the TRANSFORM_FEEDBACK_BUFFER interface would return: 1551 1552 property index 0 (binding 0) index 1 (binding 2) 1553 -------------------- -------------------- -------------------- 1554 BUFFER_BINDING 0 2 1555 NUM_ACTIVE_VARIABLES 1 2 1556 ACTIVE_VARIABLES { 0 } { 1, 2 } 1557 TRANSFORM_FEEDBACK_ 48 28 1558 BUFFER_STRIDE 1559 1560 GetProgramResourceiv for the three active variables in the 1561 TRANSFORM_FEEDBACK_VARYING interface would return: 1562 1563 (batman) (robin) (joker) 1564 property index 0 index 1 index 2 1565 -------------------- ------------ ------------ ------------ 1566 NAME_LENGTH 7 6 6 1567 TYPE FLOAT_VEC4 FLOAT_VEC4 FLOAT_VEC3 1568 ARRAY_SIZE 0 0 0 1569 OFFSET 4 0 16 1570 TRANSFORM_FEEDBACK_ 0 1 1 1571 BUFFER_INDEX 1572 1573 18) If you have a program where transform feedback layout qualifiers are 1574 specified both in the shader text and via TransformFeedbackVaryings, 1575 what happens? 1576 1577 RESOLVED: To be consistent with other features where similar things 1578 can happen (e.g., BindAttribLocation), we should allow the 1579 declarations in the shader text to "win". When LinkProgram is called, 1580 transform feedback state specified via TransformFeedbackVaryings() is 1581 ignored if the shader used for transform feedback specifies an 1582 "xfb_offset" layout qualifier on any of its variables. 1583 1584 19) Do we need #extension support for this feature? 1585 1586 RESOLVED: Yes. There is no reason we couldn't support some of the 1587 features (e.g, UBO offset) on OpenGL 3.X hardware. We will require 1588 OpenGL 3.1 / GLSL 1.40, since this is where layout qualifiers were 1589 first supported. For each extended feature, we will require the 1590 relevant core version or extension: 1591 1592 * OpenGL 3.3 and ARB_explicit_attrib_location for location and 1593 component qualifiers on vertex shader inputs and fragment shader 1594 outputs. 1595 1596 * OpenGL 4.1 and ARB_separate_shader_objects for location and 1597 component qualifiers all other shader inputs and outputs. 1598 1599 * OpenGL 4.0 and ARB_transform_feedback3 on multiple output buffers in 1600 interleaved mode (i.e., "xfb_buffer" values other than zero). 1601 1602 * OpenGL 4.3 and ARB_shader_storage_buffer_object for extended layout 1603 qualifiers on shader storage blocks. 1604 1605 * OpenGL 4.3 and ARB_program_interface_query to query offsets assigned 1606 to transform feedback varyings. 1607 1608 20) For "varyings" (e.g., vertex shader outputs, fragment shader inputs), 1609 component selection via layout qualifiers allow you to store two 1610 different variables in a single vector "location". Those variables 1611 might have different data types or interpolation qualifiers? Is this 1612 a problem for any implemenations of this extension? 1613 1614 RESOLVED: We will have a compile-time or link-time error for 1615 differing types or different interpolation qualifiers assigned to the 1616 same location. 1617 1618 21) Is the new ability to query offsets and active buffers for each 1619 variable in the TRANSFORM_FEEDBACK_VARYING interface supported for 1620 programs whose transform feedback outputs are specified via 1621 TransformFeedbackVaryings? 1622 1623 RESOLVED: Yes. The implementation will build a list of 1624 offsets/bindings during linking. 1625 1626 22) We do need to precisely define what it means to have transform 1627 feedback layout declared in the shader text (e.g., the XFB layout 1628 qualifiers are declared anywhere), and how various corner cases work. 1629 Examples: 1630 1631 A) What qualifiers can be used globally on "out", on block 1632 declarations, and individual variables? 1633 1634 B) If a shader has an "xfb_stride" qualifier for a buffer, but doesn't 1635 declare "xfb_offset" for any variable associated with that buffer, 1636 what happens? 1637 1638 C) If the shader has an "xfb_buffer" qualifier identifying a buffer, 1639 but doesn't declare "xfb_offset" on anything associated with it, 1640 what happens? 1641 1642 D) If we have variables with "xfb_offset" associated with buffers 0 and 1643 2, what happens with buffer 1? 1644 1645 E) If the shader declares "xfb_offset" on some but not all block 1646 members, what happens with the ones without an offset? Are they not 1647 captured? 1648 1649 F) If a shader variable is qualified with "xfb_offset" but is not 1650 statically referenced, what happens? 1651 1652 RESOLVED: For issue (A), we allow "xfb_offset" on blocks, block 1653 members, and variables. When using "xfb_offset" on a block, all 1654 members are assigned consecutive offsets. For issue (B), the buffer 1655 has N bytes reserved for each vertex, but nothing will be written to 1656 it. For issue (C), variables not qualified with "xfb_offset" are not 1657 captured, which makes the associated "xfb_buffer" qualifier 1658 irrelevant. For issue (D), nothing is captured to buffer 1, and if no 1659 "xfb_stride" qualifier is specified for buffer 1, no storage will be 1660 reserved there. For issue (E), block members without an offset are 1661 not captured. For issue (F), all variables with an assigned offset 1662 will have storage reserved (possibly affecting the stride) whether or 1663 not they are statically referenced. Unreferenced variables, as well 1664 as referenced variables not written for a given shader invocation, 1665 will be treated as having undefined values. 1666 1667 23) This is related to issues 16 and 20. Its resolution was that we 1668 would have an error if two fragment shader outputs with different 1669 component types were assigned to different components of the same 1670 location. We wouldn't have an error for vertex shader inputs 1671 because of the aliasing allowed in the spec since 2.0. 1672 1673 What should we do for "varyings", which don't interface with 1674 resources in the API (vertex shader inputs, fragment shader outputs). 1675 Would implementations have a problem with the following pair of 1676 vertex shader outputs/fragment shader inputs? 1677 1678 // different types, different components, same vector 1679 layout(location=2,component=1) out float f; 1680 layout(location=2,component=2) out int g; 1681 1682 Further, for the "mixed component types in a vector", do we need 1683 language related to the automatic assignment of variables without a 1684 location? For example, let's say we had fragment outputs like: 1685 1686 layout(location=0,component=3) out int f; 1687 layout(location=0,component=0) out vec3 g; 1688 1689 we'd have an error due to the component type mismatch. But what if we 1690 had this? 1691 1692 layout(location=0,component=3) out int f; 1693 out vec3 g; // location assigned by compiler 1694 1695 Should the compiler would be required to avoid location 0 in this 1696 case, even though it could "fit" into the first three components? 1697 1698 RESOLVED: For fragment outputs, no mixing is allowed, while 1699 for varyings between stages, the compiler is free to assign locations 1700 as it sees fit. If the underlying hardware is vector-based and 1701 requires all components of a vector to have identical 1702 types/qualifiers, it may need to avoid certain locations. If there is 1703 no such limitation, the compiler is free to pack variables of 1704 different types into a single location. 1705 1706 24) Should we allow "xfb_stride" layout qualifiers on block declations? 1707 Strides must be associated with a binding point ("xfb_binding"), but 1708 there is not a 1:1 correspondence between blocks and binding points. 1709 1710 UNRESOLVED: TBD 1711 1712 25) Should we allow "xfb_offset" on block declarations to specify that all 1713 block members are captured with increasing offset? If so, should we 1714 allow the "xfb_offset" qualifier on block members to override the 1715 offset for that member and subsequent ones? Also, if we allow it, 1716 what happens if you try to qualfy a block member with a different 1717 value for "xfb_buffer"? 1718 1719 UNRESOLVED: TBD 1720 1721 26) How should we handle "xfb_offset" and "xfb_stride" layout qualifiers 1722 when the shader specifies that it wants to capture double-precision 1723 scalars, vectors, matrices, as well as arrays and structures 1724 containing these types? 1725 1726 UNRESOLVED: In unextended OpenGL 4.3, we specify undefined behavior 1727 if we attempt to capture any double-precision component that doesn't 1728 have an offset aligned to a multiple of 8 bytes. This is discussed in 1729 issue (4) of the ARB_gpu_shader_fp64 extension, which notes that to 1730 align all doubles captured, three things must happen: 1731 1732 (a) the offset of the base of a buffer object must be a multiple of 1733 eight bytes; 1734 1735 (b) the amount of data captured per vertex must be a multiple of 1736 eight bytes; and 1737 1738 (c) each double-precision variable captured must be aligned to a 1739 multiple of eight bytes relative to the beginning of a vertex. 1740 1741 We could have enforced restrictions (b) and (c) in LinkProgram in 1742 ARB_gpu_shader_fp64, but chose not to because we couldn't conveniently 1743 enforce (a). Applications can always work around issues (b) and (c) 1744 by injecting padding via "gl_SkipComponents1" markers in their list of 1745 varyings. We also could have (but didn't) specified that the linker 1746 would insert such padding automatically. 1747 1748 It might have been a good idea to have enforced (b) and (c) anyway to 1749 reduce the cases where undefined behavior occurs. Since this 1750 extension provides a new way to specify output layout, we can choose 1751 to specify a new behavior when using the new method, without changing 1752 the handling of the old method. We are choosing to specify a link 1753 error if "xfb_offset" or "xfb_stride" is specified but incorrectly 1754 aligned, and to specify that the linker injects padding if the 1755 offset/stride are derived automatically. 1756 1757 1758Revision History 1759 1760 Revision 1, 19-Dec-2012 (JohnK) 1761 - Create overview. 1762 Revision 2, 21-Jan-2013 (JohnK) 1763 - Pin down a specific proposal in the overview, and add first 1764 5 issues. 1765 Revision 3, 23-Jan-2013 (JohnK) 1766 - Allow locations on input/output blocks/members 1767 - Add details about alignment rules, aliasing, number ranges, etc. 1768 - Resolve issues 1, 2, 3, and 5. 1769 Revision 4, 14-Feb-2013 (JohnK) 1770 - Update from ARB meeting 1771 - Resolve issue 4 1772 - Incorporate resolution of issue 5 1773 Revision 5, 13-Mar-2013 (JohnK) 1774 - Simplify overview 1775 - First draft specification language for features 1-5 (not 6). 1776 Revision 6, 28-Mar-2013 (JohnK) 1777 - Change xfb streams and components to buffers and offsets 1778 (aligned and non aliasing) 1779 - Uniform buffer-like offsets must be naturally aligned. 1780 - Updated issues 6-9 1781 Revision 7, 28-Mar-2013 (JohnK) 1782 - xfb_width -> xfb_stride, order doesn't matter 1783 - resolve issues 2, 7, 8, and 9 1784 - add issue 10 1785 Revision 8, 18-Apr-2013 (pbrown) 1786 - Add API specification language to query components assigned to 1787 input/output variables. 1788 - Add spec language describing the effects of component assignments 1789 to vertex shader inputs and fragment shader outputs, which interface 1790 with other API resources (generic attributes, FBO attachments). 1791 - Add stub spec language describing how transform feedback layout 1792 qualifiers operate in the API; we have issues to resolve before 1793 attempting the final language. 1794 - Add issues 11-18. 1795 Revision 9, 18-Apr-2013 (pbrown) 1796 - Add more issues, including issue 19. 1797 Revision 10, 3-May-2013 (pbrown) 1798 - Add new program interface query support for transform feedback 1799 varyings (to query offsets and binding points for each variable) 1800 and transform feedback buffers (to query stride). 1801 - Add an example of the enumeration API in issue 17. 1802 - Start reworking the transform feedback section to use a collection 1803 of variables with offsets and strides instead of a list of 1804 consecutive variables. 1805 - Add errors if a fragment shader output location is shared between 1806 variables with differetn component types. 1807 - Add clarifications on the process of assigning locations to fragment 1808 shader outputs (avoiding locations used by any explicit assignments). 1809 - Close a number of previously unresolved issues. 1810 - Add issues 20 and 21, and fork issue 22 from issue 18. 1811 Revision 11, 6-May-2013 (JohnK) 1812 - Resolve bug 10132, which includes doing the following: 1813 - Expand on the rules for repeated layout qualifiers, ordering, effect 1814 - Don't allow /component/ on structs 1815 - Initial statef of "layout(xfb_buffer = 0) out;" 1816 - rules for applying xfb_offset to a block, array, or matrix 1817 - add gl_MaxTransformFeedbackInterleavedComponents 1818 - restrict *align* to blocks and block members 1819 - unresolve issue 7 1820 - update issue 9 1821 - add issue 23 1822 Revision 12, 7-May-2013 (JohnK) 1823 - Resolve bug 10130, which means the following: 1824 - Resolve issue 10 1825 - alignments from the align qualifier will be a multiple of the base 1826 alignment of the type 1827 - offset qualifier ids must be a multiple of the base alignment of the 1828 type 1829 - minor typo fixes 1830 Revision 13, 9-May-2013 (JohnK) 1831 - Allow location layout qualifiers on input/output blocks 1832 - This incorporates the resolution of issue 2 1833 Revision 14, 9-May-2013 (JohnK) 1834 - Resolved issues 7, 19, 20, 21, and 23. 1835 Revision 15, 10-May-2013 (JohnK) 1836 - Address feedback from pbrown review cycle 1837 Revision 16, 13-May-2013 (JohnK) 1838 - Add #extension (issue 19) 1839 - Add gl_MaxTransformFeedbackInterleavedComponents = 64; 1840 - Incorporated issues 7, 20, and 23 1841 - Update issue 22 1842 - Break out xfb_ stuff into its own section 1843 - Flesh out output location/component qualifier specification 1844 - Lots of editorial changes, including moving to bold for layout qualifier names 1845 Revision 17, 16-May-2013 (JohnK) 1846 - Resolve and incorporate issue 22. 1847 Revision 18, 18-May-2013 (pbrown) 1848 - Add API specification language for transform feedback-related link 1849 errors to cover cases of variables overflowing the specified stride 1850 of their associated binding. 1851 - Rework the API specification language describing how primitives are 1852 captured in transform feedback mode to deal in offsets and strides 1853 instead of ordered lists of variables. Revision 10 had already 1854 re-defined TransformFeedbackVaryings as specifying offsets and 1855 strides. 1856 - Clarify that the OFFSET property of the TRANSFORM_FEEDBACK_VARYING 1857 returns the actual offset used for the variable, whether it was 1858 specified directly using a layout qualifier or indirectly using 1859 TransformFeedbackVaryings (issue 21). 1860 - Remove reference to MAX_TRANSFORM_FEEDBACK_SEPARATE_COMPONENTS in 1861 issue 9; when using layout qualifiers, we always capture in 1862 INTERLEAVED_ATTRIBS mode. 1863 - Cleaned up issue 22, added resolutions for each of the sub-issues. 1864 - Add issues 24 and 25. 1865 - Minor cleanups for a few other issues. 1866 Revision 19, 18-May-2013 (pbrown) 1867 - Add dependencies for use of ARB_enhanced_layouts as an extension. 1868 Require OpenGL 3.1 / GLSL 1.40, since that's where layout qualifiers 1869 were first added. For various features involving layout qualifers, 1870 require the extension or core version where those layout qualifiers 1871 were first supported. 1872 - Fix a typo involving MAX_TRANSFORM_FEEDBACK_INTERLEAVED_COMPONENTS. 1873 - Close issue 19. 1874 Revision 20, 21-May-2013 (JohnK) 1875 - Remove erroneous disembodied xfb_stride example 1876 Revision 21, 21-May-2013 (pdaniell) 1877 - Assign enum token values 1878 Revision 22, 28-May-2013 (JohnK) 1879 - Fix bugs 10249 and 10267: Expand on (stream's) rules of inheritance for 1880 xfb_buffer, allow xbf_offset to be on both a block its members, and 1881 xfb_stride can appear an anything. Other clarifications. 1882 - Fix bug 10266: xfb_stride must be a multiple of 8 if capturing doubles, 1883 and offsets are aligned to multiples of the component's size. 1884 - Fix bug 10247: Describe how actual offsets are computed based on offset 1885 and align. 1886 - Fix bug 10248: Either a whole block has location layout qualification or 1887 none of it does. 1888 - Other minor editorial changes. 1889 Revision 23, 28-May-2013 (pbrown) 1890 - Add API language specifying that automatically derived transform 1891 feedback strides (when xfb_stride is not used) will be padded out to a 1892 multiple of 8 when the buffer captures one or more doubles. 1893 - Add API language specifying a link error if the "xfb_offset" set for 1894 any variable containing doubles is not a multiple of 8, or if the 1895 "xfb_stride" set for any binding point with an associated variable 1896 containing doubles is not a multiple of 8. 1897 - Add issue 26. 1898 Revision 24, 30-May-2013 (pbrown) 1899 - Fixed a typo in the dependencies section for OpenGL 4.1 and 1900 ARB_separate_shader_objects. 1901 Revision 25, 31-May-2013 (JohnK) 1902 - Bug 10248: Redo aliasing language regarding location and component 1903 aliasing. 1904 - Bug 10318: More strongly state that align operates at the member 1905 level and not internally within members. 1906 - Bug 10321: More strongly state that xfb_offset applied to aggregates 1907 (arrays, structures, nesting,...) operates by flattening the aggregate 1908 down to a sequence of components. 1909 Revision 26, 3-July-2013 (JohnK) 1910 - Include mention of API changes in the overview, and fix the offset example. 1911 - Bug 10371: Be explicit that when the gl_PerVertex block is redeclared, 1912 the declaration can add on invariant, xfb_offset, xfb_buffer, and 1913 xfb_strideto its members, as well as array size for gl_ClipDistance. 1914 - Bug 10327: Editorial: Expanded the introduction to the transform-feedback 1915 section. Described inheritance for xfb_bufferwithout referring to stream. 1916 - A few minor editorial corrections. 1917 Revision 27, June 13, 2014 (Jon Leech) 1918 - Remove GetProgramResourceLocation* as commands accepting the 1919 TRANSFORM_FEEDBACK_BUFFER interface from the New Tokens section (Bug 1920 10588). 1921 Revision 28, January 10, 2019 (Jon Leech) 1922 - Clarify that a transform feedback buffer only needs to be bound if 1923 the buffer is active (gitlab #38). 1924