1Name 2 3 ARB_texture_buffer_object 4 5Name Strings 6 7 GL_ARB_texture_buffer_object 8 9Contact 10 11 Pat Brown, NVIDIA Corporation (pbrown 'at' nvidia.com) 12 13Notice 14 15 Copyright (c) 2008-2013 The Khronos Group Inc. Copyright terms at 16 http://www.khronos.org/registry/speccopyright.html 17 18Specification Update Policy 19 20 Khronos-approved extension specifications are updated in response to 21 issues and bugs prioritized by the Khronos OpenGL Working Group. For 22 extensions which have been promoted to a core Specification, fixes will 23 first appear in the latest version of that core Specification, and will 24 eventually be backported to the extension document. This policy is 25 described in more detail at 26 https://www.khronos.org/registry/OpenGL/docs/update_policy.php 27 28Status 29 30 Approved by the ARB on July 11, 2008 31 32Version 33 34 Last Modified Date: 06/04/2015 35 Revision: 8 36 37Number 38 39 ARB Extension #51 40 41Dependencies 42 43 OpenGL 2.0 is required. 44 45 NV_gpu_program4 or EXT_gpu_shader4 is required. 46 47 This extension is written against the OpenGL 2.0 specification. 48 49 This extension depends trivially on EXT_texture_array. 50 51 This extension depends trivially on NV_texture_shader. 52 53 This extension depends trivially on EXT_texture_integer. 54 55 This extension depends trivially on ARB_texture_float. 56 57 This extension depends trivially on ARB_half_float_pixel. 58 59 This extension interacts with ARB_map_buffer_range. 60 61Overview 62 63 This extension provides a new texture type, called a buffer texture. 64 Buffer textures are one-dimensional arrays of texels whose storage comes 65 from an attached buffer object. When a buffer object is bound to a buffer 66 texture, a format is specified, and the data in the buffer object is 67 treated as an array of texels of the specified format. 68 69 The use of a buffer object to provide storage allows the texture data to 70 be specified in a number of different ways: via buffer object loads 71 (BufferData), direct CPU writes (MapBuffer), framebuffer readbacks 72 (EXT_pixel_buffer_object extension). A buffer object can also be loaded 73 by transform feedback (NV_transform_feedback extension), which captures 74 selected transformed attributes of vertices processed by the GL. Several 75 of these mechanisms do not require an extra data copy, which would be 76 required when using conventional TexImage-like entry points. 77 78 Buffer textures do not support mipmapping, texture lookups with normalized 79 floating-point texture coordinates, and texture filtering of any sort, and 80 may not be used in fixed-function fragment processing. They can be 81 accessed via single texel fetch operations in programmable shaders. For 82 assembly shaders (NV_gpu_program4), the TXF instruction is used. For GLSL 83 (EXT_gpu_shader4), a new sampler type and texel fetch function are used. 84 85 While buffer textures can be substantially larger than equivalent 86 one-dimensional textures; the maximum texture size supported for buffer 87 textures in the initial implementation of this extension is 2^27 texels, 88 versus 2^13 (8192) texels for otherwise equivalent one-dimensional 89 textures. When a buffer object is attached to a buffer texture, a size is 90 not specified; rather, the number of texels in the texture is taken by 91 dividing the size of the buffer object by the size of each texel. 92 93New Procedures and Functions 94 95 void TexBufferARB(enum target, enum internalformat, uint buffer); 96 97New Tokens 98 99 Accepted by the <target> parameter of BindBuffer, BufferData, 100 BufferSubData, MapBuffer, MapBufferRangeARB, BindTexture, UnmapBuffer, 101 GetBufferSubData, GetBufferParameteriv, GetBufferPointerv, and TexBufferARB, 102 and the <pname> parameter of GetBooleanv, GetDoublev, GetFloatv, and 103 GetIntegerv: 104 105 TEXTURE_BUFFER_ARB 0x8C2A 106 107 Accepted by the <pname> parameters of GetBooleanv, GetDoublev, 108 GetFloatv, and GetIntegerv: 109 110 MAX_TEXTURE_BUFFER_SIZE_ARB 0x8C2B 111 TEXTURE_BINDING_BUFFER_ARB 0x8C2C 112 TEXTURE_BUFFER_DATA_STORE_BINDING_ARB 0x8C2D 113 TEXTURE_BUFFER_FORMAT_ARB 0x8C2E 114 115Additions to Chapter 2 of the OpenGL 2.0 Specification (OpenGL Operation) 116 117 None. 118 119Additions to Chapter 3 of the OpenGL 2.0 Specification (Rasterization) 120 121 (Insert new Section 3.8.4, Buffer Textures. Renumber subsequent 122 sections.) 123 124 In addition to one-, two-, and three-dimensional and cube map textures 125 described in previous sections, one additional type of texture is 126 supported. A buffer texture is similar to a one-dimensional texture. 127 However, unlike other texture types, the texel array is not stored as part 128 of the texture. Instead, a buffer object is attached to a buffer texture 129 and the texel array is taken from the data store of an attached buffer 130 object. When the contents of a buffer object's data store are modified, 131 those changes are reflected in the contents of any buffer texture to which 132 the buffer object is attached. Also unlike other textures, buffer 133 textures do not have multiple image levels; only a single data store is 134 available. 135 136 The command 137 138 void TexBufferARB(enum target, enum internalformat, uint buffer); 139 140 attaches the storage for the buffer object named <buffer> to the active 141 buffer texture, and specifies an internal format for the texel array found 142 in the attached buffer object. If <buffer> is zero, any buffer object 143 attached to the buffer texture is detached, and no new buffer object is 144 attached. If <buffer> is non-zero, but is not the name of an existing 145 buffer object, the error INVALID_OPERATION is generated. <target> must be 146 TEXTURE_BUFFER_ARB. <internalformat> specifies the storage format, and 147 must be one of the sized internal formats found in Table X.1. 148 149 When a buffer object is attached to a buffer texture, the buffer object's 150 data store is taken as the texture's texel array. The number of texels in 151 the buffer texture's texel array is given by 152 153 floor(<buffer_size> / (<components> * sizeof(<base_type>)), 154 155 where <buffer_size> is the size of the buffer object, in basic machine 156 units and <components> and <base_type> are the element count and base data 157 type for elements, as specified in Table X.1. The number of texels in the 158 texel array is then clamped to the implementation-dependent limit 159 MAX_TEXTURE_BUFFER_SIZE_ARB. When a buffer texture is accessed in a 160 shader, the results of a texel fetch are undefined if the specified texel 161 number is greater than or equal to the clamped number of texels in the 162 texel array. 163 164 When a buffer texture is accessed in a shader, an integer is provided to 165 indicate the texel number being accessed. If no buffer object is bound to 166 the buffer texture, the results of the texel access are undefined. 167 Otherwise, the attached buffer object's data store is interpreted as an 168 array of elements of the GL data type corresponding to <internalformat>. 169 Each texel consists of one to four elements that are mapped to texture 170 components (R, G, B, A, L, and I). Element <m> of the texel numbered <n> 171 is taken from element <n> * <components> + <m> of the attached buffer 172 object's data store. Elements and texels are both numbered starting with 173 zero. For texture formats with normalized components, the extracted 174 values are converted to floating-point values according to Table 2.9. The 175 components of the texture are then converted to an (R,G,B,A) vector 176 according to Table X.21, and returned to the shader as a four-component 177 result vector with components of the appropriate data type for the 178 texture's internal format. The base data type, component count, 179 normalized component information, and mapping of data store elements to 180 texture components is specified in Table X.1. 181 182 Component 183 Sized Internal Format Base Type Components Norm 0 1 2 3 184 ------------------------ --------- ---------- ---- ------- 185 ALPHA8 ubyte 1 Y A . . . 186 ALPHA16 ushort 1 Y A . . . 187 ALPHA16F_ARB half 1 N A . . . 188 ALPHA32F_ARB float 1 N A . . . 189 ALPHA8I_EXT byte 1 N A . . . 190 ALPHA16I_EXT short 1 N A . . . 191 ALPHA32I_EXT int 1 N A . . . 192 ALPHA8UI_EXT ubyte 1 N A . . . 193 ALPHA16UI_EXT ushort 1 N A . . . 194 ALPHA32UI_EXT uint 1 N A . . . 195 196 LUMINANCE8 ubyte 1 Y L . . . 197 LUMINANCE16 ushort 1 Y L . . . 198 LUMINANCE16F_ARB half 1 N L . . . 199 LUMINANCE32F_ARB float 1 N L . . . 200 LUMINANCE8I_EXT byte 1 N L . . . 201 LUMINANCE16I_EXT short 1 N L . . . 202 LUMINANCE32I_EXT int 1 N L . . . 203 LUMINANCE8UI_EXT ubyte 1 N L . . . 204 LUMINANCE16UI_EXT ushort 1 N L . . . 205 LUMINANCE32UI_EXT uint 1 N L . . . 206 207 LUMINANCE8_ALPHA8 ubyte 2 Y L A . . 208 LUMINANCE16_ALPHA16 ushort 2 Y L A . . 209 LUMINANCE_ALPHA16F_ARB half 2 N L A . . 210 LUMINANCE_ALPHA32F_ARB float 2 N L A . . 211 LUMINANCE_ALPHA8I_EXT byte 2 N L A . . 212 LUMINANCE_ALPHA16I_EXT short 2 N L A . . 213 LUMINANCE_ALPHA32I_EXT int 2 N L A . . 214 LUMINANCE_ALPHA8UI_EXT ubyte 2 N L A . . 215 LUMINANCE_ALPHA16UI_EXT ushort 2 N L A . . 216 LUMINANCE_ALPHA32UI_EXT uint 2 N L A . . 217 218 INTENSITY8 ubyte 1 Y I . . . 219 INTENSITY16 ushort 1 Y I . . . 220 INTENSITY16F_ARB half 1 N I . . . 221 INTENSITY32F_ARB float 1 N I . . . 222 INTENSITY8I_EXT byte 1 N I . . . 223 INTENSITY16I_EXT short 1 N A . . . 224 INTENSITY32I_EXT int 1 N A . . . 225 INTENSITY8UI_EXT ubyte 1 N A . . . 226 INTENSITY16UI_EXT ushort 1 N A . . . 227 INTENSITY32UI_EXT uint 1 N A . . . 228 229 RGBA8 ubyte 4 Y R G B A 230 RGBA16 ushort 4 Y R G B A 231 RGBA16F_ARB half 4 N R G B A 232 RGBA32F_ARB float 4 N R G B A 233 RGBA8I_EXT byte 4 N R G B A 234 RGBA16I_EXT short 4 N R G B A 235 RGBA32I_EXT int 4 N R G B A 236 RGBA8UI_EXT ubyte 4 N R G B A 237 RGBA16UI_EXT ushort 4 N R G B A 238 RGBA32UI_EXT uint 4 N R G B A 239 240 Table X.1, Internal Formats for Buffer Textures. For each format, the 241 data type of each element is indicated in the "Base Type" column and the 242 element count is in the "Components" column. The "Norm" column 243 indicates whether components should be treated as normalized 244 floating-point values. The "Component 0, 1, 2, and 3" columns indicate 245 the mapping of each element of a texel to texture components. 246 247 In addition to attaching buffer objects to textures, buffer objects can be 248 bound to the buffer object target named TEXTURE_BUFFER_ARB, in order to 249 specify, modify, or read the buffer object's data store. The buffer 250 object bound to TEXTURE_BUFFER_ARB has no effect on rendering. A buffer 251 object is bound to TEXTURE_BUFFER_ARB by calling BindBuffer with <target> 252 set to TEXTURE_BUFFER_ARB. If no corresponding buffer object exists, one 253 is initialized as defined in section 2.9. 254 255 The commands BufferData, BufferSubData, MapBuffer, and UnmapBuffer may all 256 be used with <target> set to TEXTURE_BUFFER_ARB. In this case, these 257 commands operate in the same fashion as described in section 2.9, but on 258 the buffer currently bound to the TEXTURE_BUFFER_ARB target. 259 260 Modify Section 3.8.11, Texture State and Proxy State (p. 178) 261 262 (insert into the first paragraph of the section, p. 178) ... a zero 263 compressed size, and zero-sized components). The buffer texture target 264 contains an integer identifying the buffer object that buffer that 265 provided the data store for the texture, initially zero, and an integer 266 identifying the internal format of the texture, initially LUMINANCE8. 267 Next, there are the two sets of texture properties; ... 268 269 Modify Section 3.8.12, Texture Objects (p. 180) 270 271 (modify first paragraphs of section, p. 180, simply adding references to 272 buffer textures, which are treated as texture objects) 273 274 In addition to the default textures TEXTURE_1D, TEXTURE_2D, TEXTURE_3D, 275 TEXTURE_CUBE_MAP, and TEXTURE_BUFFER_ARB, named one-, two-, and 276 three-dimensional, cube map, and buffer texture objects can be created and 277 operated upon. The name space for texture objects is the unsigned 278 integers, with zero reserved by the GL. 279 280 A texture object is created by binding an unused name to TEXTURE_1D, 281 TEXTURE_2D, TEXTURE_3D, TEXTURE_CUBE_MAP, or TEXTURE_BUFFER_ARB. The 282 binding is effected by calling 283 284 void BindTexture( enum target, uint texture ); 285 286 with target set to the desired texture target and texture set to the 287 unused name. The resulting texture object is a new state vector, 288 comprising all the state values listed in section 3.8.11, set to the same 289 initial values. If the new texture object is bound to TEXTURE_1D, 290 TEXTURE_2D, TEXTURE_3D, TEXTURE_CUBE_MAP, or TEXTURE_BUFFER_ARB, it is and 291 remains a one-, two-, three-dimensional, cube map, or buffer texture 292 respectively until it is deleted. 293 294 BindTexture may also be used to bind an existing texture object to either 295 TEXTURE_1D, TEXTURE_2D, TEXTURE_3D, TEXTURE_CUBE_MAP, or 296 TEXTURE_BUFFER_ARB. The error INVALID_OPERATION is generated if an attempt 297 is made to bind a texture object of different dimensionality than the 298 specified target. If the bind is successful no change is made to the state 299 of the bound texture object, and any previous binding to target is broken. 300 301 ... 302 303 In the initial state, TEXTURE_1D, TEXTURE_2D, TEXTURE_3D, 304 TEXTURE_CUBE_MAP, and TEXTURE_BUFFER_ARB have one-, two-, 305 three-dimensional, cube map, and buffer texture state vectors respectively 306 associated with them. In order that access to these initial textures not 307 be lost, they are treated as texture objects all of whose names are 0. The 308 initial one-, two-, three-dimensional, cube map, and buffer texture is 309 therefore operated upon, queried, and applied as TEXTURE_1D, TEXTURE_2D, 310 TEXTURE_3D, TEXTURE_CUBE_MAP, or TEXTURE_BUFFER_ARB respectively while 0 311 is bound to the corresponding targets. 312 313 Texture objects are deleted by calling 314 315 void DeleteTextures( sizei n, uint *textures ); 316 317 textures contains n names of texture objects to be deleted. After a 318 texture object is deleted, it has no contents or dimensionality, and its 319 name is again unused. If a texture that is currently bound to one of the 320 targets TEXTURE_1D, TEXTURE_2D, TEXTURE_3D, TEXTURE_CUBE_MAP, or 321 TEXTURE_BUFFER_ARB is deleted, it is as though BindTexture had been 322 executed with the same target and texture zero. Unused names in textures 323 are silently ignored, as is the value zero. 324 325 (modify second paragraph, p. 182, adding buffer textures, plus cube map 326 textures, which is an oversight in the core specification) 327 328 The texture object name space, including the initial one-, two-, and 329 three-dimensional, cube map, and buffer texture objects, is shared among 330 all texture units. A texture object may be bound to more than one texture 331 unit simultaneously. After a texture object is bound, any GL operations on 332 that target object affect any other texture units to which the same 333 texture object is bound. 334 335Additions to Chapter 4 of the OpenGL 2.0 Specification (Per-Fragment 336Operations and the Frame Buffer) 337 338 None. 339 340Additions to Chapter 5 of the OpenGL 2.0 Specification (Special Functions) 341 342 Modify Section 5.4, Display Lists (p. 237) 343 344 (modify "Vertex buffer objects" portion of the list of non-listable 345 commands, p. 241) 346 347 Buffer objects: GenBuffers, DeleteBuffers, BindBuffer, BufferData, 348 BufferSubData, MapBuffer, UnmapBuffer, and TexBufferARB. 349 350Additions to Chapter 6 of the OpenGL 2.0 Specification (State and 351State Requests) 352 353 Modify Section 6.1.13, Buffer Object Queries (p. 255) 354 355 (modify the first paragraph on p. 256) The command 356 357 void GetBufferSubData( enum target, intptr offset, 358 sizeiptr size, void *data ); 359 360 queries the data contents of a buffer object. target is ARRAY_BUFFER, 361 ELEMENT_ARRAY_BUFFER, or TEXTURE_BUFFER_ARB. ... 362 363 (modify the last paragraph of the section, p. 256) While the data store of 364 a buffer object is mapped, the pointer to the data store can be queried by 365 calling 366 367 void GetBufferPointerv( enum target, enum pname, void **params ); 368 369 with target set to ARRAY_BUFFER, ELEMENT_ARRAY_BUFFER, or 370 TEXTURE_BUFFER_ARB, and pname set to BUFFER MAP POINTER. 371 372Additions to Appendix A of the OpenGL 2.0 Specification (Invariance) 373 374 None. 375 376Additions to the AGL/GLX/WGL Specifications 377 378 None. 379 380Dependencies on EXT_texture_array 381 382 If EXT_texture_array is supported, the introductory language describing 383 buffer textures should acknowledge the existence of array textures. Other 384 than that, there are no dependencies between the two extensions. 385 386Dependencies on NV_texture_shader 387 388 If NV_texture_shader is not supported, references to the signed normalized 389 internal formats provided by that extension should be removed, and such 390 formats may not be passed to TexBufferARB. 391 392Dependencies on EXT_texture_integer 393 394 If EXT_texture_integer is not supported, references to the signed and 395 unsigned integer internal formats provided by that extension should be 396 removed, and such formats may not be passed to TexBufferARB. 397 398Dependencies on ARB_texture_float 399 400 If ARB_texture_float is not supported, references to the floating-point 401 internal formats provided by that extension should be removed, and such 402 formats may not be passed to TexBufferARB. 403 404Dependencies on ARB_half_float_pixel 405 406 If ARB_texture_float is not supported, references to the 16-bit 407 floating-point internal formats provided by ARB_texture_float should be 408 removed, and such formats may not be passed to TexBufferARB. If an 409 implementation supports ARB_texture_float, but does not support 410 ARB_half_float_pixel, 16-bit floating-point texture formats may be 411 available using normal texture mechanisms, but not with buffer textures. 412 413GLX Protocol 414 415 The following rendering command is sent to the server as 416 a part of glXRender request: 417 418 TexBufferARB 419 420 2 16 rendering command length 421 2 367 rendering command opcode 422 4 ENUM target 423 4 ENUM internalformat 424 4 CARD32 buffer 425 426Errors 427 428 INVALID_OPERATION is generated by TexBufferARB if <buffer> is non-zero and 429 is not the name of an existing buffer object. 430 431New State 432 433 (add to table 6.15, Texture State Per Texture Unit/Binding Point p. 276) 434 435 Initial 436 Get Value Type Get Command Value Description Sec. Attribute 437 --------------------------------- ---- ----------- ------- --------------------------- ------ --------- 438 TEXTURE_BINDING_BUFFER_ARB 2*xZ+ GetIntegerv 0 Texture object bound to 3.8.12 texture 439 TEXTURE_BUFFER_ARB 440 441 (add to table 6.16, Texture State Per Texture Object, p. 276) 442 443 Initial 444 Get Value Type Get Command Value Description Sec. Attribute 445 --------------------------------- ---- ----------- ------- --------------------------- ------ --------- 446 TEXTURE_BUFFER_DATA_STORE_ nxZ+ GetIntegerv 0 Buffer object bound as 3.8.12 texture 447 BINDING_ARB the data store for the 448 active image unit's buffer 449 texture 450 TEXTURE_BUFFER_FORMAT_ARB nxZ+ GetIntegerv LUMIN- Internal format for the 3.8.12 texture 451 ANCE8 active image unit's buffer 452 texture 453 454 (add to table 6.37, Miscellaneous State, p. 298) 455 456 Initial 457 Get Value Type Get Command Value Description Sec. Attribute 458 --------------------------------- ---- ----------- ------- --------------------------- ------ --------- 459 TEXTURE_BUFFER_ARB Z+ GetIntegerv 0 Buffer object bound to 3.8.12 texture 460 the generic buffer texture 461 binding point 462 463New Implementation Dependent State 464 465 (modify Table 6.32, p. 293) 466 Minimum 467 Get Value Type Get Command Value Description Sec. Attribute 468 --------------------------- ---- ----------- ------- --------------------- ----- --------- 469 MAX_TEXTURE_BUFFER_SIZE_ARB Z+ GetIntegerv 65536 number of addressable 3.8.4 - 470 texels for buffer 471 textures 472 473Issues 474 475 (1) Buffer textures are potentially large one-dimensional arrays that can 476 be accessed with single-texel fetches. How should this functionality 477 be exposed? 478 479 RESOLVED: Several options were considered. The final approach creates 480 a new type of texture object, called a buffer texture, whose texel array 481 is taken from the data store from a buffer object. The combined set of 482 extensions using buffer objects provides numerous locations where the GL 483 can read and write data to a buffer object: 484 485 EXT_vertex_buffer_object allows vertex attributes to be pulled from a 486 buffer object. 487 488 EXT_pixel_buffer_object allows pixel operations (DrawPixels, 489 ReadPixels, TexImage) to read or write data to a buffer object. 490 491 EXT_parameter_buffer_object and EXT_bindable_uniform allows assembly 492 vertex, fragment, and geometry programs, and all GLSL shaders to read 493 program parameter / uniform data from a buffer object. 494 495 ARB_texture_buffer_object allows programs to read texture data from a 496 buffer object. 497 498 NV_transform_feedback allows programs to write transformed vertex 499 attributes to a buffer object. 500 501 When combined, interesting feedback paths are possible, where large 502 arrays of data can be generated by the GPU and the consumed by it in 503 multi-pass algorithms, using the buffer object's storage to hold 504 intermediate data. This allows applications to run complicated 505 algorithms on the GPU without necessarily pulling data back to host CPU 506 for additional processing. 507 508 Given that buffer object memory is visible to users as raw memory, all 509 uses of the memory must have well-defined data formats. For VBO and 510 PBO, those formats are explicitly given by calls such as VertexPointer, 511 TexImage2D, or ReadPixels. When used as a buffer texture, it is 512 necessary to specify an internal format with which the bytes of the 513 buffer object's data store are interpreted. 514 515 Another option considered was to greatly increase the maximum texture 516 size for 1D texture. This has the advantage of not requiring new 517 mechanisms. However, there are a couple limitations of this approach. 518 First, conventional textures have their own storage that is not 519 accessible elsewhere, which limits some of the sharing opportunities 520 described above. Second, buffer textures do have slightly different 521 hardware implementations than 1D textures. In the hardware of interest, 522 "normal" 1D textures can be mipmapped and filtered, but have a maximum 523 size that is considerably smaller than that supported for buffer 524 textures. If both texture types used the same API mechanism, it might 525 be necessary to reprogram texture hardware and/or shaders depending on 526 the size of the textures used. This will incur CPU overhead to 527 determine if such reprogramming is necessary and to perform the 528 reprogramming if so. 529 530 (2) Since buffer textures borrow storage from buffer objects, whose 531 storage is visible to applications, a format must be imposed on the 532 bytes of the buffer object. What texture formats are supported for 533 buffer objects? 534 535 RESOLVED: All sized one-, two-, and four-component internal formats 536 with 8-, 16-, and 32-bit components are supported. Unsized internal 537 formats, and sized formats with other component sizes are also not 538 supported. Three-component (RGB) formats are not supported due to 539 hardware limitations. 540 541 All component data types supported for normal textures are also 542 supported for buffer textures. This includes unsigned [0,1] normalized 543 components (e.g., RGBA8), floating-point components from 544 ARB_texture_float (e.g., RGBA32F_ARB), signed and unsigned integer 545 components from EXT_texture_integer (e.g., RGBA8I_EXT, RGBA16UI_EXT), 546 and signed [-1,+1] normalized components from NV_texture_shader (e.g., 547 SIGNED_RGBA8_NV). 548 549 (3) How can arrays of three-component vectors be accessed by applications? 550 551 RESOLVED: Several approaches are possible. 552 553 First, the vectors can be padded out to four components (RGBA), with an 554 extra unused component for each texel. This has a couple undesirable 555 properties: it adds 33% to the required storage and adding the extra 556 component may require reformatting of original data generated by the 557 application. However, the data in this format can be retrieved with a 558 single 32-, 64-, or 128-bit lookup. 559 560 Alternately, the buffer texture can be defined using a single component, 561 and a shader can perform three lookups to separately fetch texels 3*N, 562 3*N+1, and 3*N+2, combining the result in a three-component vector 563 representing "RGB" texel N. This doesn't require extra storage or 564 reformatting and doesn't require additional bandwidth for texture 565 fetches. But it does require additional shader instructions to obtain 566 each texel. 567 568 (4) Does this extension support fixed-function fragment processing, 569 somehow allowing buffer textures to be accessed without programmable 570 shaders? 571 572 RESOLVED: No. We expect that it would be difficult to properly access 573 a buffer texture and combine the returned texel with other color or 574 texture data, given the extremely limited programming model provided by 575 fixed-function fragment processing. 576 577 Note also that the single-precision floating-point representation 578 commonly used by current graphics hardware is not sufficiently precise 579 to exactly represent all texels in a large buffer texture. For example, 580 it is not possible to represent 2^24+1 using the 32-bit IEEE 581 floating-point representation. 582 583 (5) What happens if a buffer object is deleted or respecified when bound 584 to a buffer texture? 585 586 RESOLVED: BufferData is allowed to be used to update a buffer object that 587 has already been bound to a texture with TexBuffer. The update to the data 588 is not guaranteed to affect the texture until next time it is bound to a 589 texture image unit. When DeleteBuffers is called, any buffer that is 590 bound to a texture is removed from the names array, but remains as long as 591 it is bound to a texture. The buffer is fully removed when the texture 592 unbinds it or when the texture buffer object is deleted. 593 594 (6) Should applications be able to modify the data store of a buffer 595 object while it is bound to a buffer texture? 596 597 RESOLVED: An application is allowed to update the data store for a buffer 598 object when the buffer object is bound to a texture. 599 600 (7) Do buffer textures support texture parameters (TexParameter) or 601 queries (GetTexParameter, GetTexLevelParameter, GetTexImage)? 602 603 RESOLVED: No. None of the existing parameters apply to buffer 604 textures, and this extension doesn't introduce the need for any new 605 ones. Buffer textures have no levels, and the size in texels is 606 implicit (based on the data store). Given that the texels themselves 607 are obtained from a buffer object, it seems more appropriate to retrieve 608 such data with buffer object queries. The only "parameter" of a buffer 609 texture is the internal format, which is specified at the same time the 610 buffer object is bound. 611 612 Note that the spec edits above don't add explicit error language for any 613 of these cases. That is because each of the functions enumerate the set 614 of valid <target> parameters. Not editing the spec to allow 615 TEXTURE_BUFFER_ARB in these cases means that target is not legal, and an 616 INVALID_ENUM error should be generated. 617 618 (8) What about indirect rendering with a mix of big- and little-endian 619 clients? If components are 16- or 32-bit, how are they interpreted? 620 621 RESOLVED: Buffer object data are interpreted according to the native 622 representation of the server. If the server and client have different 623 endianness, applications must perform byte swapping as needed to match 624 the server's representation. No mechanism is provided to perform this 625 byte swapping on buffer object updates or when texels are fetched. 626 627 The same problem also exists when buffer objects are used for vertex 628 arrays (VBO). For buffer objects used for pixel packing and unpacking 629 (ARB_pixel_buffer_object), the PixelStore byte swapping parameters 630 (PACK_SWAP_BYTES, UNPACK_SWAP_BYTES) would presumably apply and could be 631 used to perform the necessary byte swapping. 632 633 (9) Should the set of formats supported for buffer textures be enumerated, 634 or should the extension instead nominally support all formats, but 635 accept only an implementation-dependent subset? 636 637 RESOLVED: Provide a specified set of supported formats. This 638 extension simply enumerates all 8-, 16-, and 32-byte internal formats 639 with 1, 2, or 4 components, and specifies the mapping of unformatted 640 buffer object data to texture components. A follow-on extension could 641 be done to support 3-component texels when better native hardware 642 support is available. 643 644 Other than 3-component texels, the set of formats supported seems pretty 645 compehensive. We expect that buffer textures would be used for general 646 computational tasks, where there is little need for formats with smaller 647 components (e.g., RGBA4444). Such formats are generally not supported 648 natively on CPUs today. With the general computational model provided 649 by NV_gpu_program4 and EXT_gpu_shader4, it would be possible to treat 650 such "packed" formats as larger single-component formats and unpack them 651 with a small number of shader instructions. 652 653 If and when double-precision floats or 64-bit integers are supported as 654 basic types usable by shaders, we would expect that an extension would 655 add new texture internal formats with 64-bit components and that those 656 formats would also be supported for general-purpose textures and buffer 657 textures as well. 658 659 (10) How are buffer textures supported in GLSL? 660 661 RESOLVED: Create a new sampler type (samplerBuffer) for buffer textures 662 and add a new lookup function (texelFetchBuffer) to explicitly access 663 them using texture hardware. 664 665 Other possibilities considered included extending the notion of bindable 666 uniforms to support uniforms whose corresponding buffer objects can be 667 bound to texture resources (e.g., "texture bindable uniform" instead of 668 "bindable uniform"). We also considered automatically assigning 669 bindable uniforms to texture or shader resources as appropriate. Note 670 that the restrictions, size limits, and performance characterstics of 671 buffer textures and parameter buffers (NV_parameter_buffer_object) 672 differ. Automatic handling of uniforms adds driver complexity and may 673 tend to hide performance characteristics since it isn't clear what 674 resource would be used for what variable. Additionally, it could 675 require shader recompilation if the size of a uniform array is variable, 676 and the hardware resource used depended on the size. 677 678 In the end, the texture approach seemed the simplest, and we chose that. 679 It might be worth doing something more complex in the future. 680 681 (11) What is the TEXTURE_BUFFER_ARB buffer object binding point good for? 682 683 RESOLVED: It can be used for loading data into buffer objects, and for 684 mapping and unmapping buffers, both without disturbing other binding 685 points. Otherwise, it has no effect on GL operations, since buffer 686 objects are bound to textures using the TexBufferARB() command that does 687 not affect the buffer object binding point. 688 689 Buffer object binding points have mixed usage. In the 690 EXT_vertex_buffer_object extension (OpenGL 1.5), there are two binding 691 points. The ELEMENT_ARRAY_BUFFER has a direct effect on rendering, as 692 it modifies DrawElements() calls. The effect of ARRAY_BUFFER is much 693 more indirect; it is only used to affect subsequent vertex array calls 694 (e.g., VertexPointer) and has no direct effect on rendering. The reason 695 for this is that the API was retrofitted on top of existing vertex array 696 APIs. If a new vertex array API were created that emphasized or even 697 required the use of buffer objects, it seems likely that the buffer 698 object would be included in the calls equivalent to today's 699 VertexPointer() call. 700 701 (12) How is the various buffer texture-related state queried? 702 703 RESOLVED: There are three pieces of state that can be queried: (a) the 704 texture object bound to buffer texture binding point for the active 705 texture image unit, (b) the buffer object whose data store was used by 706 that texture object, and (c) the buffer object bound to the 707 TEXTURE_BUFFER_ARB binding point. 708 709 All three are queried with GetIntegerv, because it didn't seem worth the 710 trouble to add one or more new query functions. Note that for (a) and 711 (b), the texture queried is the one bound to TEXTURE_BUFFER_ARB on the 712 active texture image unit. 713 714 (13) Should we provide a new set of names for the signed normalized 715 textures introduced in NV_texture_shader that match the convention 716 used for floating-point and integer textures? 717 718 RESOLVED: No. 719 720 (14) Can a buffer object be attached to more than one buffer texture at 721 once? 722 723 RESOLVED: Multiple buffer textures may attach to the same buffer object 724 simultaneously. 725 726 (15) How does this extension interact with display lists? 727 728 RESOLVED: Buffer object commands can't be compiled into a display list. 729 The new command in this extension uses buffer objects, so we specify 730 that it also can't be compiled into a display list. 731 732Revision History 733 734 Rev. Date Author Changes 735 ---- -------- -------- ----------------------------------------- 736 8 06/04/15 srahman Add GLX protocol specification. 737 738 7 07/09/13 Jon Leech Correct suffix on 739 TEXTURE_BUFFER_DATA_STORE_BINDING_ARB 740 (was EXT). 741 742 6 6/30/08 js Trivial conversion to ARB from EXT 743 744 745 5 04/16/08 pbrown Clarify that either NV_gpu_program4 or 746 EXT_gpu_shader4 is required, not simply 747 NV_gpu_program4. 748 749 4 10/30/07 ewerness Add resolutions to various issues 750 751 3 -- Pre-release revisions. 752