1Name 2 3 EXT_bindable_uniform 4 5Name String 6 7 GL_EXT_bindable_uniform 8 9Contact 10 11 Pat Brown, NVIDIA (pbrown 'at' nvidia.com) 12 Barthold Lichtenbelt, NVIDIA (blichtenbelt 'at' nvidia.com) 13 14Status 15 16 Shipping for GeForce 8 Series (November 2006) 17 18Version 19 20 Last Modified Date: 04/04/2008 21 Author revision: 15 22 23Number 24 25 342 26 27Dependencies 28 29 OpenGL 1.1 is required. 30 31 This extension is written against the OpenGL 2.0 specification and version 32 1.10.59 of the OpenGL Shading Language specification. 33 34 This extension interacts with GL_EXT_geometry_shader4. 35 36Overview 37 38 This extension introduces the concept of bindable uniforms to the OpenGL 39 Shading Language. A uniform variable can be declared bindable, which 40 means that the storage for the uniform is not allocated by the 41 compiler/linker anymore, but is backed by a buffer object. This buffer 42 object is bound to the bindable uniform through the new command 43 UniformBufferEXT(). Binding needs to happen after linking a program 44 object. 45 46 Binding different buffer objects to a bindable uniform allows an 47 application to easily use different "uniform data sets", without having to 48 re-specify the data every time. 49 50 A buffer object can be bound to bindable uniforms in different program 51 objects. If those bindable uniforms are all of the same type, accessing a 52 bindable uniform in program object A will result in the same data if the 53 same access is made in program object B. This provides a mechanism for 54 'environment uniforms', uniform values that can be shared among multiple 55 program objects. 56 57New Procedures and Functions 58 59 void UniformBufferEXT(uint program, int location, uint buffer); 60 int GetUniformBufferSizeEXT(uint program, int location); 61 intptr GetUniformOffsetEXT(uint program, int location); 62 63New Tokens 64 65 Accepted by the <pname> parameter of GetBooleanv, GetIntegerv, GetFloatv, 66 and GetDoublev: 67 68 MAX_VERTEX_BINDABLE_UNIFORMS_EXT 0x8DE2 69 MAX_FRAGMENT_BINDABLE_UNIFORMS_EXT 0x8DE3 70 MAX_GEOMETRY_BINDABLE_UNIFORMS_EXT 0x8DE4 71 MAX_BINDABLE_UNIFORM_SIZE_EXT 0x8DED 72 UNIFORM_BUFFER_BINDING_EXT 0x8DEF 73 74 Accepted by the <target> parameters of BindBuffer, BufferData, 75 BufferSubData, MapBuffer, UnmapBuffer, GetBufferSubData, and 76 GetBufferPointerv: 77 78 UNIFORM_BUFFER_EXT 0x8DEE 79 80Additions to Chapter 2 of the OpenGL 2.0 Specification (OpenGL Operation) 81 82 Modify section 2.15.3 "Shader Variables", page 75. 83 84 Add the following paragraph between the second and third paragraph on page 85 79, "Uniform Variables" 86 87 Uniform variables can be further characterized into bindable 88 uniforms. Storage for bindable uniforms does not come out of the, 89 potentially limited, uniform variable storage discussed in the previous 90 paragraph. Instead, storage for a bindable uniform is provided by a buffer 91 object that is bound to the uniform variable. Binding different buffer 92 objects to a bindable uniform allows an application to easily use 93 different "uniform data sets", without having to re-specify the data every 94 time. A buffer object can be bound to bindable uniforms in different 95 program objects. If those bindable uniforms are all of the same type, 96 accessing a bindable uniform in program object A will result in the same 97 data if the same access is made in program object B. This provides a 98 mechanism for 'environment', uniform values that can be shared among 99 multiple program objects. 100 101 Change the first sentence of the third paragraph, p. 79, as follows: 102 103 When a program object is successfully linked, all non-bindable active 104 uniforms belonging to the program object are initialized to zero (FALSE 105 for Booleans). All active bindable uniforms have their buffer object 106 bindings reset to an invalid state. A successful link will also generate a 107 location for each active uniform, including active bindable uniforms. The 108 values of active uniforms can be changed using this location and the 109 appropriate Uniform* command (see below). For bindable uniforms, a buffer 110 object has to be first bound to the uniform before changing its 111 value. These locations are invalidated. 112 113 Change the second to last paragraph, p. 79, as follows: 114 115 A valid name for a non-bindable uniform cannot be a structure, an array of 116 structures, or any portion of a single vector or a matrix. A valid name 117 for a bindable uniform cannot be any portion of a single vector or 118 matrix. In order to identify a valid name, ... 119 120 Change the fifth paragraph, p. 81, as follows: 121 122 The given values are loaded into the uniform variable location identified 123 by <location>. The parameter <location> cannot identify a bindable uniform 124 structure or a bindable uniform array of structures. When loading data for 125 a bindable uniform, the data will be stored in the appropriate location of 126 the buffer object bound to the bindable uniform (see UniformBufferEXT 127 below). 128 129 Add the following bullets to the list of errors on p. 82: 130 131 - If <location> refers to a bindable uniform structure or a bindable 132 uniform array of structures. 133 134 - If <location> refers to a bindable uniform that has no buffer object 135 bound to the uniform. 136 137 - If <location> refers to a bindable uniform and the bound buffer object 138 is not of sufficient size. This means that the buffer object is 139 smaller than the size that would be returned by 140 GetUniformBufferSizeEXT for the bindable uniform. 141 142 - If <location> refers to a bindable uniform and the buffer object is 143 bound to multiple bindable uniforms in the currently active program 144 object. 145 146 Add a sub-section called "Bindable Uniforms" above the section "Samplers", 147 p. 82: 148 149 The number of active bindable uniform variables that can be supported by a 150 vertex shader is limited and specified by the implementation dependent 151 constant MAX_VERTEX_BINDABLE_UNIFORMS_EXT. The minimum supported number 152 of bindable uniforms is eight. A link error will be generated if the 153 program object contains more active bindable uniform variables. 154 155 To query the minimum size needed for a buffer object to back a given 156 bindable uniform, use the command: 157 158 int GetUniformBufferSizeEXT(uint program, int location); 159 160 This command returns the size in basic machine units of the smallest 161 buffer object that can be used for the bindable uniform given by 162 <location>. The size returned is intended to be passed as the <size> 163 parameter to the BufferData() command. The error INVALID_OPERATION will be 164 generated if <location> does not correspond to an active bindable uniform 165 in <program>. The parameter <location> has to be location corresponding 166 to the name of the bindable uniform itself, otherwise the error 167 INVALID_OPERATION is generated. If the bindable uniform is a structure, 168 <location> can not refer to a structure member. If it is an array, 169 <location> can not refer to any array member other than the first one. If 170 <program> has not been successfully linked, the error INVALID_OPERATION is 171 generated. 172 173 There is an implementation-dependent limit on the size of bindable uniform 174 variables. LinkProgram will fail if the storage required for the uniform 175 (in basic machine units) exceeds MAX_BINDABLE_UNIFORM_SIZE_EXT. 176 177 To bind a buffer object to a bindable uniform, use the command: 178 179 void UniformBufferEXT(uint program, int location, uint buffer) 180 181 This command binds the buffer object <buffer> to the bindable uniform 182 <location> in the program object <program>. Any previous binding to the 183 bindable uniform <location> is broken. Before calling UniformBufferEXT the 184 buffer object has to be created, but it does not have to be initialized 185 with data nor its size set. Passing the value zero in <buffer> will 186 unbind the currently bound buffer object. The error INVALID_OPERATION is 187 generated if <location> does not correspond to an active bindable uniform 188 in <program>. The parameter <location> has to correspond to the name of 189 the uniform variable itself, as described for GetUniformBufferSizeEXT, 190 otherwise the error INVALID_OPERATION is generated. If <program> has not 191 been successfully linked, or if <buffer> is not the name of an existing 192 buffer object, the error INVALID_OPERATION is generated. 193 194 A buffer object cannot be bound to more than one uniform variable in any 195 single program object. However, a buffer object can be bound to bindable 196 uniform variables in multiple program objects. Furthermore, if those 197 bindable uniforms are all of the same type, accessing a scalar, vector, a 198 member of a structure, or an element of an array in program object A will 199 result in the same data if the same scalar, vector, structure member, or 200 array element is accessed in program object B. Additionally the structures 201 in both program objects have to have the same members, specified in the 202 same order, declared with the same data types and have the same name. If 203 the buffer object bound to the uniform variable is smaller than the 204 minimum size required to store the uniform variable, as reported by 205 GetUniformbufferSizeEXT, the results of reading the variable (or any 206 portion thereof) are undefined. 207 208 If LinkProgram is called on a program object that has already been linked, 209 any buffer objects bound to the bindable uniforms in the program are 210 unbound prior to linking, as though UniformBufferEXT were called for each 211 bindable uniform with a <buffer> value of zero. 212 213 Buffer objects used to store uniform variables may be created and 214 manipulated by buffer object functions (e.g., BufferData, BufferSubData, 215 MapBuffer) by calling BindBuffer with a <target> of UNIFORM_BUFFER_EXT. 216 It is not necessary to bind a buffer object to UNIFORM_BUFFER_EXT in order 217 to use it with an active program object. 218 219 The exact layout of bindable uniform variables in buffer object storage is 220 not defined. However, the values of signed integer, unsigned integer, or 221 floating-point uniforms, or vectors thereof, may be updated by modifying 222 the underlying buffer object storage using either MapBuffer or 223 BufferSubData. The command 224 225 intptr GetUniformOffsetEXT(uint program, int location); 226 227 returns the offset (in bytes) of the uniform in <program> whose location 228 as returned by GetUniformLocation is <location>. The error INVALID_VALUE 229 is generated if the object named by <program> does not exist. The error 230 INVALID_OPERATION is generated if <program> is not a program object, if 231 <program> was not linked successfully, or if <location> refers to a 232 uniform that was not declared as bindable. The memory layout of matrix, 233 boolean, or boolean vector uniforms is not defined, and the error 234 INVALID_OPERATION will be generated if <location> refers to a boolean, 235 boolean vector, or matrix uniform. The value -1 is returned by 236 GetUniformOffsetEXT if an error is generated. 237 238 The values of such uniforms may be changing by writing signed integer, 239 unsigned integer, or floating-point values into the buffer object at the 240 byte offset returned by GetUniformOffsetEXT. For vectors, two to four 241 integers or floating-point values should be written to consecutive 242 locations in the buffer object storage. For arrays of scalar or vector 243 variables, the number of bytes between individual array members is 244 guaranteed to be constant, but array members are not guaranteed to be 245 stored in adjacent locations. For example, some implementations may pad 246 scalars, or two- or three-component vectors out to a four-component 247 vector. 248 249 Change the first paragraph below the sub-heading 'Samplers', p. 82, as 250 follows: 251 252 Samplers are special uniforms used in the OpenGL Shading Language to 253 identify the texture object used for each texture lookup. Samplers cannot 254 be declared as bindable in a shader. The value of a sampler indicates the 255 texture image unit being accessed. Setting a sampler's value. 256 257 Add the following bullets to the list of error conditions for Begin on 258 p. 87: 259 260 - There is one, or more, bindable uniform(s) in the currently 261 active program object that does not have a buffer object 262 bound to it. 263 264 - There is one, or more, bindable uniform(s) in the currently active 265 program object that have a buffer object bound to it of insufficient 266 size. This means that the buffer object is smaller than the size that 267 would be returned by GetUniformBufferSizeEXT for the bindable uniform. 268 269 - A buffer object is bound to multiple bindable uniforms in the currently 270 active program object. 271 272 273Additions to Chapter 3 of the OpenGL 2.0 Specification (Rasterization) 274 275 Modify Section 3.11.1 "Shader Variables", p. 193 276 277 Add a paragraph between the first and second paragraph, p. 194 278 279 The number of active bindable uniform variables that can be supported by a 280 fragment shader is limited and specified by the implementation dependent 281 constant MAX_FRAGMENT_BINDABLE_UNIFORMS_EXT. The minimum supported number 282 of bindable uniforms is eight. A link error will be generated if the 283 program object contains more active bindable uniform variables. 284 285Additions to Chapter 4 of the OpenGL 2.0 Specification (Per-Fragment 286Operations and the Frame Buffer) 287 288 None. 289 290Additions to Chapter 5 of the OpenGL 2.0 Specification (Special Functions) 291 292 Change section 5.4 Display Lists, p. 237 293 294 Add the command UniformBufferEXT to the list of commands that are not 295 compiled into a display list, but executed immediately, under "Program and 296 Shader Objects", p. 241. 297 298Additions to Chapter 6 of the OpenGL 2.0 Specification (State and State 299Requests) 300 301 None. 302 303Additions to Appendix A of the OpenGL 2.0 Specification (Invariance) 304 305 None. 306 307Additions to the AGL/GLX/WGL Specifications 308 309 None. 310 311Interactions with GL_EXT_geometry_shader4 312 313 If GL_EXT_geometry_shader4 is supported, a geometry shader will also 314 support bindable uniforms. The following paragraph needs to be added to 315 the section that discusses geometry shaders: 316 317 "The number of active bindable uniform variables that can be supported by 318 a geometry shader is limited and specified by the implementation dependent 319 constant MAX_GEOMETRY_BINDABLE_UNIFORMS_EXT. The minimum supported number 320 of bindable uniforms is eight. A link error will be generated if the 321 program object contains more active bindable uniform variables." 322 323 The implementation dependent value MAX_GEOMETRY_BINDABLE_UNIFORMS_EXT will 324 need to be added to the state tables and assigned an enum value. 325 326Errors 327 328 The error INVALID_VALUE is generated by UniformBufferEXT, 329 GetUniformBufferSize, or GetUniformOffsetEXT if <program> is not the name 330 of a program or shader object. 331 332 The error INVALID_OPERATION is generated by UniformBufferEXT, 333 GetUniformBufferSize, or GetUniformOffsetEXT if <program> is the name of a 334 shader object. 335 336 The error INVALID_OPERATION is generated by the Uniform* commands if 337 <location> refers to a bindable uniform structure or an array of such 338 structures. 339 340 The error INVALID_OPERATION is generated by the Uniform* commands if 341 <location> refers to a bindable uniform that has no buffer object bound. 342 343 The error INVALID_OPERATION is generated by the Uniform* commands if 344 <location> refers to a bindable uniform and the bound buffer object is not 345 of sufficient size to store data into <location>. 346 347 The error INVALID_OPERATION is generated by the GetUniformBufferSizeEXT 348 and UniformBufferEXT commands if <program> has not been successfully 349 linked. 350 351 The error INVALID_OPERATION is generated by the GetUniformBufferSizeEXT 352 and UniformBufferEXT commands if <location> is not the location 353 corresponding to the name of the bindable uniform itself or if <location> 354 does not correspond to an active bindable uniform in <program>. 355 356 The error INVALID_OPERATION is generated by GetUniformOffsetEXT if 357 <program> was not linked successfully, if <location> refers to a uniform 358 that was not declared as bindable, or if <location> refers to a boolean, 359 boolean vector, or matrix uniform. 360 361 The error INVALID_OPERATION is generated by the UniformBufferEXT command if 362 <buffer> is not the name of a buffer object. 363 364 The error INVALID_OPERATION is generated by Begin, Rasterpos or any 365 command that performs an implicit Begin if: 366 367 - A buffer object is bound to multiple bindable uniforms in the currently 368 active program object. 369 370 - There is one, or more, bindable uniform(s) in the currently active 371 program object that does not have a buffer object bound to it. 372 373 - There is one, or more, bindable uniform(s) in the currently active 374 program object that have a buffer object bound to it of insufficient 375 size. This means that the buffer object is smaller than the size that 376 would be returned by GetUniformBufferSizeEXT for the bindable uniform. 377 378New State 379 380 Initial 381 Get Value Type Get Command Value Description Sec Attribute 382 -------------------------- ---- ----------- ----- ------------------------- ----- --------- 383 UNIFORM_BUFFER_BINDING_EXT Z+ GetIntegerv 0 Uniform buffer bound to 2.15 - 384 the context for buffer 385 object manipulation. 386 387New Implementation Dependent State 388 389 Minimum 390 Get Value Type Get Command Value Description Section Attrib 391 ---------------------- ---- ----------- ----- --------------------- ------- ------ 392 MAX_BINDABLE_VERTEX_ Z+ GetIntegerv 8 Number of bindable 2.15 - 393 UNIFORMS_EXT uniforms per vertex 394 shader 395 MAX_BINDABLE_FRAGMENT_ Z+ GetIntegerv 8 Number of bindable 3.11.1 - 396 UNIFORMS_EXT uniforms per fragment 397 shader 398 MAX_BINDABLE_GEOMETRY_ Z+ GetIntegerv 8 Number of bindable X.X.X - 399 UNIFORMS_EXT uniforms per geometry 400 shader 401 MAX_BINDABLE_UNIFORM_ Z+ GetIntegerv 16384 Maximum size (in bytes) 2.15 - 402 SIZE_EXT for bindable uniform 403 storage. 404 405Modifications to The OpenGL Shading Language Specification, Version 4061.10.59 407 408 Including the following line in a shader can be used to control the 409 language features described in this extension: 410 411 #extension GL_EXT_bindable_uniform: <behavior> 412 413 where <behavior> is as specified in section 3.3. 414 415 A new preprocessor #define is added to the OpenGL Shading Language: 416 417 #define GL_EXT_bindable_uniform 1 418 419 Add to section 3.6 "Keywords" 420 421 Add the following keyword: 422 423 bindable 424 425 Change section 4.3 "Type Qualifiers" 426 427 In the qualifier table, add the following sub-qualifiers under the uniform 428 qualifier: 429 430 bindable uniform 431 432 Change section 4.3.5 "Uniform" 433 434 Add the following paragraphs between the last and the second to last 435 paragraphs: 436 437 Uniform variables, except for samplers, can optionally be further 438 qualified with "bindable". If "bindable" is present, the storage for the 439 uniform comes from a buffer object, which is bound to the uniform through 440 the GL API, as described in section 2.15.3 of the OpenGL 2.0 441 specification. In this case, the memory used does not count against the 442 storage limit described in the previous paragraph. When using the 443 "bindable" keyword, it must immediately precede the "uniform" keyword. 444 445 An example bindable uniform declaration is: 446 447 bindable uniform float foo; 448 449 Only a limited number of uniforms can be bindable for each type of 450 shader. If this limit is exceeded, it will cause a compile-time or 451 link-time error. Bindable uniforms that are declared but not used do not 452 count against this limit. 453 454 Add to section 9 "Shading Language Grammar" 455 456 type_qualifer: 457 CONST 458 ATTRIBUTE // Vertex only 459 uniform-modifieropt UNIFORM 460 461 uniform-modifier: 462 BINDABLE 463 464Issues 465 466 1. Is binding a buffer object to a uniform done before or after linking a 467 program object? 468 469 DISCUSSION: There is no need to re-link when changing the buffer object 470 that backs a uniform. Re-binding can therefore be relatively quickly. 471 Binding is be done using the location of the uniform retrieved by 472 GetUniformLocation, to make it even faster (instead of binding by name 473 of the uniform). 474 475 Reasons to do this before linking: The linker might want to know what 476 buffer object backs the uniform. Binding of a buffer object to a 477 bindable uniform, in this case, will have to be done using the name of 478 the uniform (no location is available until after linking). Changing the 479 binding of a buffer object to a bindable uniform means the program 480 object will have to be re-linked, which would substantially increase the 481 overhead of using multiple different "constant sets" in a single 482 program. 483 484 RESOLUTION: Binding a buffer object to a bindable uniform needs to be 485 done after the program object is linked. One of the purposes of this 486 extension is to be able to switch among multiple sets of uniform values 487 efficiently. 488 489 2. Is the memory layout of a bindable uniform available to an application? 490 491 DISCUSSION: Buffer objects are arrays of bytes. The application can map 492 a buffer object and retrieve a pointer to it, and read or write into it 493 directly. Or, the application can use the BufferSubData() command to 494 store data in a buffer object. They can also be filled using ReadPixels 495 (with ARB_pixel_buffer_object), or filled using extensions such as the 496 new transform feedback extension. 497 498 If the layout of a uniform in buffer object memory is known, these 499 different ways of filling a buffer object could be leveraged. On the 500 other hand, different compiler implementations may want a different 501 packing schemes that may or may not match an end-user's expectations 502 (e.g., all individual uniforms might be stored as vec4's). If only the 503 Uniform*() API were allowed to modify buffer objects, we could 504 completely hide the layout of bindable uniforms. Unfortuantely, that 505 would limit how the buffer object can be linked to other sources of 506 data. 507 508 RESOLUTION: RESOLVED. The memory layout of a bindable uniform variable 509 will not be specified. However, a query function will be added that 510 allows applications to determine the layout and load their buffer object 511 via API's other than Uniform*() accordingly if they choose. 512 Unfortunately, the layout may not be consistent across implementations 513 of this extension. 514 515 Providing a better standard set of packing rules is highly desirable, 516 and we hope to design and add such functionality in an extension in the 517 near future. 518 519 3. How is synchronization handled between a program object using a buffer 520 object and updates to the buffer object? 521 522 DISCUSSION: For example, what happens when a ReadPixels into a buffer 523 object is outstanding, that is bound to a bindable uniform while the 524 program object, containing the bindable uniform, is in use? 525 526 RESOLUTION: UNRESOLVED. It is probably the GL implementation's 527 responsibility to properly synchronize such usages. This issue needs 528 solving for GL_EXT_texture_buffer_object also, and should be consistent. 529 530 4. A limited number of bindable uniforms can exist in one program 531 object. Should this limit be queriable? 532 533 DISCUSSION: The link operation will fail if too many bindable uniforms 534 are declared and active. Should the limit on the number of active 535 bindable uniforms be queriable by the application? 536 537 RESOLUTION: Yes, this limit is queriable. 538 539 5. Is the limit discussed in the previous issue per shader type? 540 541 DISCUSSION: Is there a different limit for vertex shader and fragment 542 shaders? Hardware might support different limits. The storage for 543 uniform variables is a limit queriable per shader type, thus it would be 544 nice to be consistent with the existing model. 545 546 RESOLUTION: YES. 547 548 6. Can an application find out programmatically that a uniform is declared 549 as a bindable uniform? 550 551 DISCUSSION: Using GetActiveUniform() the application can 552 programmatically find out which uniforms are active, what their type and 553 size etc it. Do we need to add a mechanism for an application to find 554 out if an active uniform is a bindable uniform? 555 556 RESOLUTION: UNRESOLVED. To be consistent, the answer should be 557 yes. However, extending GetActiveUniform() is not possible, which means 558 we need a new API command. If we define a new API command, it probably 559 is better to define something like: GetNewActiveUniform(int program, 560 uint index, enum property, void *data); Or alternatively, define new API 561 to query the properties of a uniform per uniform location: 562 GetActiveUniformProperty(int program, int location, enum property, void 563 *data) 564 565 7. What to do when the buffer object bound to a bindable uniform is not big 566 enough to back the uniform or if no buffer object is bound at all? 567 568 DISCUSSION: The size of a buffer object can be changed, after it is 569 bound, by calling BufferData. It is possible that the buffer object 570 isn't sufficiently big enough to back the bindable uniform. This is an 571 issue when loading values for uniforms and when actually rendering. In 572 the case of loading uniforms, should the Uniform* API generate an error? 573 In the case of rendering, should this be a Begin error? 574 575 RESOLUTION: RESOLVED. It is a Begin error if a buffer object is too 576 small or no buffer object is bound at all. The Uniform* commands will 577 generate an error in these cases as well. 578 579 8. What restrictions are there on binding a buffer object to more than one 580 bindable uniform? 581 582 DISCUSSION: Can a buffer object be bound to more than one uniform within 583 a program object? No, this does not seem to be a good idea. Can a 584 buffer object be bound to more than one uniform in different program 585 objects? Yes, this is useful functionality to have. If each uniform is 586 also of the same type, then data access in program object A then the 587 same access in program object B results in the same data. In the latter 588 case, if the uniform variables are arrays, must the arrays have the same 589 length declared? No, that is too big of a restriction. The application 590 is responsible for making sure the buffer object is sufficiently sized 591 to provide storage for the largest bindable uniform array. 592 593 RESOLUTION: RESOLVED. 594 595 9. It is not allowed to bind a buffer object to more than one bindable 596 uniform in a program object. There are several operations that could be 597 affected by this rule: UseProgram(), the uniform loading commands 598 Uniform*, Begin, RasterPos and any related rendering command. Should 599 each operation generate an error if the rule is violated? 600 601 DISCUSSION: See also issue 7. The UseProgram command could generate an 602 error if the rule is violated. However, it is possible to change the 603 binding of a buffer object to a bindable uniform even after UseProgram 604 has been issued. Thus should the Uniform* commands also check for this? 605 If so, is that going to be a performance burden on uniform loading? Or 606 should it be undefined? Finally, at rendering time violation of this 607 rule will have to be checked. If violated, it seems to make sense to 608 generate an error. 609 610 RESOLUTION: RESOLVED. Make violation of the rule a Begin error and a 611 Uniform* error. 612 613 10. How to provide the ability to use bindable uniform arrays (or bindable 614 uniform arrays of structures) where the amount of data can differ based 615 on the buffer object bound to it? 616 617 DISCUSSION: In other words, the size of the bindable uniform is no 618 longer declared in the shader, but determined by the buffer object 619 backing it. This can be achieved through a variety of ways: 620 621 bindable uniform vec3 foo[1]; 622 623 Where we would allow indexing 'off the end' of the array 'foo', because 624 it is backed by a buffer object. The actual size of the array will be 625 implicitly inferred from the buffer object bound to it. It'll be the 626 shader's responsibility to not index outside the size of the buffer 627 object. That in turn means that the layout in buffer object memory of a 628 bindable uniform needs to be exposed to the application. 629 630 Or we could support something like: 631 632 bindable uniform vec3 foo[100000]; // Some really big number 633 634 and make all accesses inside the buffer object bound to "foo" legal. 635 636 Or we could support something like: 637 638 bindable uniform float foo[]; 639 640 foo[3] = 1.0; 641 foo[i] = . 642 643 Where 'i' could be a run-time index. 644 645 RESOLUTION: For now, we will not support this functionality. 646 647 11. Do we want to have bindable namespaces instead of the uniform qualifier 648 "bindable"? 649 650 DISCUSSION: Something like this: 651 652 bindable { 653 vec3 blarg; 654 int booyah; 655 }; 656 657 where "blarg" and "booyah" can be referred to directly, but are both 658 bindable to the same buffer. You can achieve this with bindable uniforms 659 stored in structures: 660 661 bindable uniform struct { 662 vec3 blarg; 663 int booyah; 664 } foo; 665 666 but then have to use "foo.blarg" and "foo.booyah". 667 668 RESOLUTION: Not in this extension. This might be nice programming sugar, 669 but not essential. Such a feature may be added in a future extension 670 building on this one. 671 672 12. How can an application load data into a bindable uniform? 673 674 RESOLUTION: See also issue 2. Uniform variables declared as bindable can 675 be loaded using the existing Uniform* commands, or data can be loaded in 676 the buffer object bound to the uniform using any of the existing 677 mechanisms. 678 679 13. Should it be allowed to load data, using the Uniform* commands, into a 680 buffer object that is bound to more than one bindable uniform variable 681 in a program object? 682 683 DISCUSSION: It is a Begin error to attempt to render in this situation. 684 685 RESOLUTION: Yes, to be consistent with the Begin error, it is also an 686 error to load a value in this case. 687 688 14. Should a buffer object binding point be provided for bindable uniforms? 689 690 DISCUSSION: All current OpenGL buffer object manipulation functions take 691 a <target> to which a buffer object must be bound. In this extension, 692 buffer objects are bound to uniforms stored in a program, and are not 693 bound directly to the context. So these bindings may not be used to 694 manipulate the 695 696 RESOLUTION: Yes, a new <target> called UNIFORM_BUFFER_EXT is provided. 697 698 The following is a simple example of creating, binding, and populating a 699 buffer object for a bindable uniform named "stuff", which is an array of 700 vec4 values: 701 702 GLuint program, buffer; 703 GLint location, size; 704 GLfloat values; 705 706 // ... compile shaders and link <program> 707 location = glGetUniformLocation(program, "stuff"); 708 size = GetUniformBufferSize(program, location); 709 glGenBuffers(1, &buffer); 710 glBindBuffer(GL_UNIFORM_BUFFER_EXT, buffer); 711 glBufferData(GL_UNIFORM_BUFFER_EXT, size, NULL, STATIC_READ); 712 glUniformBufferEXT(program, location, buffer); 713 ... 714 glUseProgram(program); 715 glUniform4fv(location, count, values); 716 717Revision History 718 719 Rev. Date Author Changes 720 ---- -------- -------- ----------------------------------------- 721 15 04/04/08 aeddy Moved state sections into the proper order. 722 723 14 02/14/08 pbrown Clarify some confusing language about the memory 724 layout restrictions and GetUniformOffsetEXT. 725 726 13 12/13/07 pbrown Minor clarification on what values can be passed 727 to GetUniformBufferSizeEXT and UniformBufferEXT. 728 729 12 12/15/06 pbrown Documented that the '#extension' token 730 for this extension should begin with "GL_", 731 as apparently called for per convention. 732 733 11 -- Pre-release revisions. 734