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