| Name |
| |
| ARB_texture_buffer_object |
| |
| Name Strings |
| |
| GL_ARB_texture_buffer_object |
| |
| Contact |
| |
| Pat Brown, NVIDIA Corporation (pbrown 'at' nvidia.com) |
| |
| Notice |
| |
| Copyright (c) 2008-2013 The Khronos Group Inc. Copyright terms at |
| http://www.khronos.org/registry/speccopyright.html |
| |
| Status |
| |
| Approved by the ARB on July 11, 2008 |
| |
| Version |
| |
| Last Modified Date: 06/04/2015 |
| Revision: 8 |
| |
| Number |
| |
| ARB Extension #51 |
| |
| Dependencies |
| |
| OpenGL 2.0 is required. |
| |
| NV_gpu_program4 or EXT_gpu_shader4 is required. |
| |
| This extension is written against the OpenGL 2.0 specification. |
| |
| This extension depends trivially on EXT_texture_array. |
| |
| This extension depends trivially on NV_texture_shader. |
| |
| This extension depends trivially on EXT_texture_integer. |
| |
| This extension depends trivially on ARB_texture_float. |
| |
| This extension depends trivially on ARB_half_float_pixel. |
| |
| This extension interacts with ARB_map_buffer_range. |
| |
| Overview |
| |
| This extension provides a new texture type, called a buffer texture. |
| Buffer textures are one-dimensional arrays of texels whose storage comes |
| from an attached buffer object. When a buffer object is bound to a buffer |
| texture, a format is specified, and the data in the buffer object is |
| treated as an array of texels of the specified format. |
| |
| The use of a buffer object to provide storage allows the texture data to |
| be specified in a number of different ways: via buffer object loads |
| (BufferData), direct CPU writes (MapBuffer), framebuffer readbacks |
| (EXT_pixel_buffer_object extension). A buffer object can also be loaded |
| by transform feedback (NV_transform_feedback extension), which captures |
| selected transformed attributes of vertices processed by the GL. Several |
| of these mechanisms do not require an extra data copy, which would be |
| required when using conventional TexImage-like entry points. |
| |
| Buffer textures do not support mipmapping, texture lookups with normalized |
| floating-point texture coordinates, and texture filtering of any sort, and |
| may not be used in fixed-function fragment processing. They can be |
| accessed via single texel fetch operations in programmable shaders. For |
| assembly shaders (NV_gpu_program4), the TXF instruction is used. For GLSL |
| (EXT_gpu_shader4), a new sampler type and texel fetch function are used. |
| |
| While buffer textures can be substantially larger than equivalent |
| one-dimensional textures; the maximum texture size supported for buffer |
| textures in the initial implementation of this extension is 2^27 texels, |
| versus 2^13 (8192) texels for otherwise equivalent one-dimensional |
| textures. When a buffer object is attached to a buffer texture, a size is |
| not specified; rather, the number of texels in the texture is taken by |
| dividing the size of the buffer object by the size of each texel. |
| |
| New Procedures and Functions |
| |
| void TexBufferARB(enum target, enum internalformat, uint buffer); |
| |
| New Tokens |
| |
| Accepted by the <target> parameter of BindBuffer, BufferData, |
| BufferSubData, MapBuffer, MapBufferRangeARB, BindTexture, UnmapBuffer, |
| GetBufferSubData, GetBufferParameteriv, GetBufferPointerv, and TexBufferARB, |
| and the <pname> parameter of GetBooleanv, GetDoublev, GetFloatv, and |
| GetIntegerv: |
| |
| TEXTURE_BUFFER_ARB 0x8C2A |
| |
| Accepted by the <pname> parameters of GetBooleanv, GetDoublev, |
| GetFloatv, and GetIntegerv: |
| |
| MAX_TEXTURE_BUFFER_SIZE_ARB 0x8C2B |
| TEXTURE_BINDING_BUFFER_ARB 0x8C2C |
| TEXTURE_BUFFER_DATA_STORE_BINDING_ARB 0x8C2D |
| TEXTURE_BUFFER_FORMAT_ARB 0x8C2E |
| |
| Additions to Chapter 2 of the OpenGL 2.0 Specification (OpenGL Operation) |
| |
| None. |
| |
| Additions to Chapter 3 of the OpenGL 2.0 Specification (Rasterization) |
| |
| (Insert new Section 3.8.4, Buffer Textures. Renumber subsequent |
| sections.) |
| |
| In addition to one-, two-, and three-dimensional and cube map textures |
| described in previous sections, one additional type of texture is |
| supported. A buffer texture is similar to a one-dimensional texture. |
| However, unlike other texture types, the texel array is not stored as part |
| of the texture. Instead, a buffer object is attached to a buffer texture |
| and the texel array is taken from the data store of an attached buffer |
| object. When the contents of a buffer object's data store are modified, |
| those changes are reflected in the contents of any buffer texture to which |
| the buffer object is attached. Also unlike other textures, buffer |
| textures do not have multiple image levels; only a single data store is |
| available. |
| |
| The command |
| |
| void TexBufferARB(enum target, enum internalformat, uint buffer); |
| |
| attaches the storage for the buffer object named <buffer> to the active |
| buffer texture, and specifies an internal format for the texel array found |
| in the attached buffer object. If <buffer> is zero, any buffer object |
| attached to the buffer texture is detached, and no new buffer object is |
| attached. If <buffer> is non-zero, but is not the name of an existing |
| buffer object, the error INVALID_OPERATION is generated. <target> must be |
| TEXTURE_BUFFER_ARB. <internalformat> specifies the storage format, and |
| must be one of the sized internal formats found in Table X.1. |
| |
| When a buffer object is attached to a buffer texture, the buffer object's |
| data store is taken as the texture's texel array. The number of texels in |
| the buffer texture's texel array is given by |
| |
| floor(<buffer_size> / (<components> * sizeof(<base_type>)), |
| |
| where <buffer_size> is the size of the buffer object, in basic machine |
| units and <components> and <base_type> are the element count and base data |
| type for elements, as specified in Table X.1. The number of texels in the |
| texel array is then clamped to the implementation-dependent limit |
| MAX_TEXTURE_BUFFER_SIZE_ARB. When a buffer texture is accessed in a |
| shader, the results of a texel fetch are undefined if the specified texel |
| number is greater than or equal to the clamped number of texels in the |
| texel array. |
| |
| When a buffer texture is accessed in a shader, an integer is provided to |
| indicate the texel number being accessed. If no buffer object is bound to |
| the buffer texture, the results of the texel access are undefined. |
| Otherwise, the attached buffer object's data store is interpreted as an |
| array of elements of the GL data type corresponding to <internalformat>. |
| Each texel consists of one to four elements that are mapped to texture |
| components (R, G, B, A, L, and I). Element <m> of the texel numbered <n> |
| is taken from element <n> * <components> + <m> of the attached buffer |
| object's data store. Elements and texels are both numbered starting with |
| zero. For texture formats with normalized components, the extracted |
| values are converted to floating-point values according to Table 2.9. The |
| components of the texture are then converted to an (R,G,B,A) vector |
| according to Table X.21, and returned to the shader as a four-component |
| result vector with components of the appropriate data type for the |
| texture's internal format. The base data type, component count, |
| normalized component information, and mapping of data store elements to |
| texture components is specified in Table X.1. |
| |
| Component |
| Sized Internal Format Base Type Components Norm 0 1 2 3 |
| ------------------------ --------- ---------- ---- ------- |
| ALPHA8 ubyte 1 Y A . . . |
| ALPHA16 ushort 1 Y A . . . |
| ALPHA16F_ARB half 1 N A . . . |
| ALPHA32F_ARB float 1 N A . . . |
| ALPHA8I_EXT byte 1 N A . . . |
| ALPHA16I_EXT short 1 N A . . . |
| ALPHA32I_EXT int 1 N A . . . |
| ALPHA8UI_EXT ubyte 1 N A . . . |
| ALPHA16UI_EXT ushort 1 N A . . . |
| ALPHA32UI_EXT uint 1 N A . . . |
| |
| LUMINANCE8 ubyte 1 Y L . . . |
| LUMINANCE16 ushort 1 Y L . . . |
| LUMINANCE16F_ARB half 1 N L . . . |
| LUMINANCE32F_ARB float 1 N L . . . |
| LUMINANCE8I_EXT byte 1 N L . . . |
| LUMINANCE16I_EXT short 1 N L . . . |
| LUMINANCE32I_EXT int 1 N L . . . |
| LUMINANCE8UI_EXT ubyte 1 N L . . . |
| LUMINANCE16UI_EXT ushort 1 N L . . . |
| LUMINANCE32UI_EXT uint 1 N L . . . |
| |
| LUMINANCE8_ALPHA8 ubyte 2 Y L A . . |
| LUMINANCE16_ALPHA16 ushort 2 Y L A . . |
| LUMINANCE_ALPHA16F_ARB half 2 N L A . . |
| LUMINANCE_ALPHA32F_ARB float 2 N L A . . |
| LUMINANCE_ALPHA8I_EXT byte 2 N L A . . |
| LUMINANCE_ALPHA16I_EXT short 2 N L A . . |
| LUMINANCE_ALPHA32I_EXT int 2 N L A . . |
| LUMINANCE_ALPHA8UI_EXT ubyte 2 N L A . . |
| LUMINANCE_ALPHA16UI_EXT ushort 2 N L A . . |
| LUMINANCE_ALPHA32UI_EXT uint 2 N L A . . |
| |
| INTENSITY8 ubyte 1 Y I . . . |
| INTENSITY16 ushort 1 Y I . . . |
| INTENSITY16F_ARB half 1 N I . . . |
| INTENSITY32F_ARB float 1 N I . . . |
| INTENSITY8I_EXT byte 1 N I . . . |
| INTENSITY16I_EXT short 1 N A . . . |
| INTENSITY32I_EXT int 1 N A . . . |
| INTENSITY8UI_EXT ubyte 1 N A . . . |
| INTENSITY16UI_EXT ushort 1 N A . . . |
| INTENSITY32UI_EXT uint 1 N A . . . |
| |
| RGBA8 ubyte 4 Y R G B A |
| RGBA16 ushort 4 Y R G B A |
| RGBA16F_ARB half 4 N R G B A |
| RGBA32F_ARB float 4 N R G B A |
| RGBA8I_EXT byte 4 N R G B A |
| RGBA16I_EXT short 4 N R G B A |
| RGBA32I_EXT int 4 N R G B A |
| RGBA8UI_EXT ubyte 4 N R G B A |
| RGBA16UI_EXT ushort 4 N R G B A |
| RGBA32UI_EXT uint 4 N R G B A |
| |
| Table X.1, Internal Formats for Buffer Textures. For each format, the |
| data type of each element is indicated in the "Base Type" column and the |
| element count is in the "Components" column. The "Norm" column |
| indicates whether components should be treated as normalized |
| floating-point values. The "Component 0, 1, 2, and 3" columns indicate |
| the mapping of each element of a texel to texture components. |
| |
| In addition to attaching buffer objects to textures, buffer objects can be |
| bound to the buffer object target named TEXTURE_BUFFER_ARB, in order to |
| specify, modify, or read the buffer object's data store. The buffer |
| object bound to TEXTURE_BUFFER_ARB has no effect on rendering. A buffer |
| object is bound to TEXTURE_BUFFER_ARB by calling BindBuffer with <target> |
| set to TEXTURE_BUFFER_ARB. If no corresponding buffer object exists, one |
| is initialized as defined in section 2.9. |
| |
| The commands BufferData, BufferSubData, MapBuffer, and UnmapBuffer may all |
| be used with <target> set to TEXTURE_BUFFER_ARB. In this case, these |
| commands operate in the same fashion as described in section 2.9, but on |
| the buffer currently bound to the TEXTURE_BUFFER_ARB target. |
| |
| Modify Section 3.8.11, Texture State and Proxy State (p. 178) |
| |
| (insert into the first paragraph of the section, p. 178) ... a zero |
| compressed size, and zero-sized components). The buffer texture target |
| contains an integer identifying the buffer object that buffer that |
| provided the data store for the texture, initially zero, and an integer |
| identifying the internal format of the texture, initially LUMINANCE8. |
| Next, there are the two sets of texture properties; ... |
| |
| Modify Section 3.8.12, Texture Objects (p. 180) |
| |
| (modify first paragraphs of section, p. 180, simply adding references to |
| buffer textures, which are treated as texture objects) |
| |
| In addition to the default textures TEXTURE_1D, TEXTURE_2D, TEXTURE_3D, |
| TEXTURE_CUBE_MAP, and TEXTURE_BUFFER_ARB, named one-, two-, and |
| three-dimensional, cube map, and buffer texture objects can be created and |
| operated upon. The name space for texture objects is the unsigned |
| integers, with zero reserved by the GL. |
| |
| A texture object is created by binding an unused name to TEXTURE_1D, |
| TEXTURE_2D, TEXTURE_3D, TEXTURE_CUBE_MAP, or TEXTURE_BUFFER_ARB. The |
| binding is effected by calling |
| |
| void BindTexture( enum target, uint texture ); |
| |
| with target set to the desired texture target and texture set to the |
| unused name. The resulting texture object is a new state vector, |
| comprising all the state values listed in section 3.8.11, set to the same |
| initial values. If the new texture object is bound to TEXTURE_1D, |
| TEXTURE_2D, TEXTURE_3D, TEXTURE_CUBE_MAP, or TEXTURE_BUFFER_ARB, it is and |
| remains a one-, two-, three-dimensional, cube map, or buffer texture |
| respectively until it is deleted. |
| |
| BindTexture may also be used to bind an existing texture object to either |
| TEXTURE_1D, TEXTURE_2D, TEXTURE_3D, TEXTURE_CUBE_MAP, or |
| TEXTURE_BUFFER_ARB. The error INVALID_OPERATION is generated if an attempt |
| is made to bind a texture object of different dimensionality than the |
| specified target. If the bind is successful no change is made to the state |
| of the bound texture object, and any previous binding to target is broken. |
| |
| ... |
| |
| In the initial state, TEXTURE_1D, TEXTURE_2D, TEXTURE_3D, |
| TEXTURE_CUBE_MAP, and TEXTURE_BUFFER_ARB have one-, two-, |
| three-dimensional, cube map, and buffer texture state vectors respectively |
| associated with them. In order that access to these initial textures not |
| be lost, they are treated as texture objects all of whose names are 0. The |
| initial one-, two-, three-dimensional, cube map, and buffer texture is |
| therefore operated upon, queried, and applied as TEXTURE_1D, TEXTURE_2D, |
| TEXTURE_3D, TEXTURE_CUBE_MAP, or TEXTURE_BUFFER_ARB respectively while 0 |
| is bound to the corresponding targets. |
| |
| Texture objects are deleted by calling |
| |
| void DeleteTextures( sizei n, uint *textures ); |
| |
| textures contains n names of texture objects to be deleted. After a |
| texture object is deleted, it has no contents or dimensionality, and its |
| name is again unused. If a texture that is currently bound to one of the |
| targets TEXTURE_1D, TEXTURE_2D, TEXTURE_3D, TEXTURE_CUBE_MAP, or |
| TEXTURE_BUFFER_ARB is deleted, it is as though BindTexture had been |
| executed with the same target and texture zero. Unused names in textures |
| are silently ignored, as is the value zero. |
| |
| (modify second paragraph, p. 182, adding buffer textures, plus cube map |
| textures, which is an oversight in the core specification) |
| |
| The texture object name space, including the initial one-, two-, and |
| three-dimensional, cube map, and buffer texture objects, is shared among |
| all texture units. A texture object may be bound to more than one texture |
| unit simultaneously. After a texture object is bound, any GL operations on |
| that target object affect any other texture units to which the same |
| texture object is bound. |
| |
| Additions to Chapter 4 of the OpenGL 2.0 Specification (Per-Fragment |
| Operations and the Frame Buffer) |
| |
| None. |
| |
| Additions to Chapter 5 of the OpenGL 2.0 Specification (Special Functions) |
| |
| Modify Section 5.4, Display Lists (p. 237) |
| |
| (modify "Vertex buffer objects" portion of the list of non-listable |
| commands, p. 241) |
| |
| Buffer objects: GenBuffers, DeleteBuffers, BindBuffer, BufferData, |
| BufferSubData, MapBuffer, UnmapBuffer, and TexBufferARB. |
| |
| Additions to Chapter 6 of the OpenGL 2.0 Specification (State and |
| State Requests) |
| |
| Modify Section 6.1.13, Buffer Object Queries (p. 255) |
| |
| (modify the first paragraph on p. 256) The command |
| |
| void GetBufferSubData( enum target, intptr offset, |
| sizeiptr size, void *data ); |
| |
| queries the data contents of a buffer object. target is ARRAY_BUFFER, |
| ELEMENT_ARRAY_BUFFER, or TEXTURE_BUFFER_ARB. ... |
| |
| (modify the last paragraph of the section, p. 256) While the data store of |
| a buffer object is mapped, the pointer to the data store can be queried by |
| calling |
| |
| void GetBufferPointerv( enum target, enum pname, void **params ); |
| |
| with target set to ARRAY_BUFFER, ELEMENT_ARRAY_BUFFER, or |
| TEXTURE_BUFFER_ARB, and pname set to BUFFER MAP POINTER. |
| |
| Additions to Appendix A of the OpenGL 2.0 Specification (Invariance) |
| |
| None. |
| |
| Additions to the AGL/GLX/WGL Specifications |
| |
| None. |
| |
| Dependencies on EXT_texture_array |
| |
| If EXT_texture_array is supported, the introductory language describing |
| buffer textures should acknowledge the existence of array textures. Other |
| than that, there are no dependencies between the two extensions. |
| |
| Dependencies on NV_texture_shader |
| |
| If NV_texture_shader is not supported, references to the signed normalized |
| internal formats provided by that extension should be removed, and such |
| formats may not be passed to TexBufferARB. |
| |
| Dependencies on EXT_texture_integer |
| |
| If EXT_texture_integer is not supported, references to the signed and |
| unsigned integer internal formats provided by that extension should be |
| removed, and such formats may not be passed to TexBufferARB. |
| |
| Dependencies on ARB_texture_float |
| |
| If ARB_texture_float is not supported, references to the floating-point |
| internal formats provided by that extension should be removed, and such |
| formats may not be passed to TexBufferARB. |
| |
| Dependencies on ARB_half_float_pixel |
| |
| If ARB_texture_float is not supported, references to the 16-bit |
| floating-point internal formats provided by ARB_texture_float should be |
| removed, and such formats may not be passed to TexBufferARB. If an |
| implementation supports ARB_texture_float, but does not support |
| ARB_half_float_pixel, 16-bit floating-point texture formats may be |
| available using normal texture mechanisms, but not with buffer textures. |
| |
| GLX Protocol |
| |
| The following rendering command is sent to the server as |
| a part of glXRender request: |
| |
| TexBufferARB |
| |
| 2 16 rendering command length |
| 2 367 rendering command opcode |
| 4 ENUM target |
| 4 ENUM internalformat |
| 4 CARD32 buffer |
| |
| Errors |
| |
| INVALID_OPERATION is generated by TexBufferARB if <buffer> is non-zero and |
| is not the name of an existing buffer object. |
| |
| New State |
| |
| (add to table 6.15, Texture State Per Texture Unit/Binding Point p. 276) |
| |
| Initial |
| Get Value Type Get Command Value Description Sec. Attribute |
| --------------------------------- ---- ----------- ------- --------------------------- ------ --------- |
| TEXTURE_BINDING_BUFFER_ARB 2*xZ+ GetIntegerv 0 Texture object bound to 3.8.12 texture |
| TEXTURE_BUFFER_ARB |
| |
| (add to table 6.16, Texture State Per Texture Object, p. 276) |
| |
| Initial |
| Get Value Type Get Command Value Description Sec. Attribute |
| --------------------------------- ---- ----------- ------- --------------------------- ------ --------- |
| TEXTURE_BUFFER_DATA_STORE_ nxZ+ GetIntegerv 0 Buffer object bound as 3.8.12 texture |
| BINDING_ARB the data store for the |
| active image unit's buffer |
| texture |
| TEXTURE_BUFFER_FORMAT_ARB nxZ+ GetIntegerv LUMIN- Internal format for the 3.8.12 texture |
| ANCE8 active image unit's buffer |
| texture |
| |
| (add to table 6.37, Miscellaneous State, p. 298) |
| |
| Initial |
| Get Value Type Get Command Value Description Sec. Attribute |
| --------------------------------- ---- ----------- ------- --------------------------- ------ --------- |
| TEXTURE_BUFFER_ARB Z+ GetIntegerv 0 Buffer object bound to 3.8.12 texture |
| the generic buffer texture |
| binding point |
| |
| New Implementation Dependent State |
| |
| (modify Table 6.32, p. 293) |
| Minimum |
| Get Value Type Get Command Value Description Sec. Attribute |
| --------------------------- ---- ----------- ------- --------------------- ----- --------- |
| MAX_TEXTURE_BUFFER_SIZE_ARB Z+ GetIntegerv 65536 number of addressable 3.8.4 - |
| texels for buffer |
| textures |
| |
| Issues |
| |
| (1) Buffer textures are potentially large one-dimensional arrays that can |
| be accessed with single-texel fetches. How should this functionality |
| be exposed? |
| |
| RESOLVED: Several options were considered. The final approach creates |
| a new type of texture object, called a buffer texture, whose texel array |
| is taken from the data store from a buffer object. The combined set of |
| extensions using buffer objects provides numerous locations where the GL |
| can read and write data to a buffer object: |
| |
| EXT_vertex_buffer_object allows vertex attributes to be pulled from a |
| buffer object. |
| |
| EXT_pixel_buffer_object allows pixel operations (DrawPixels, |
| ReadPixels, TexImage) to read or write data to a buffer object. |
| |
| EXT_parameter_buffer_object and EXT_bindable_uniform allows assembly |
| vertex, fragment, and geometry programs, and all GLSL shaders to read |
| program parameter / uniform data from a buffer object. |
| |
| ARB_texture_buffer_object allows programs to read texture data from a |
| buffer object. |
| |
| NV_transform_feedback allows programs to write transformed vertex |
| attributes to a buffer object. |
| |
| When combined, interesting feedback paths are possible, where large |
| arrays of data can be generated by the GPU and the consumed by it in |
| multi-pass algorithms, using the buffer object's storage to hold |
| intermediate data. This allows applications to run complicated |
| algorithms on the GPU without necessarily pulling data back to host CPU |
| for additional processing. |
| |
| Given that buffer object memory is visible to users as raw memory, all |
| uses of the memory must have well-defined data formats. For VBO and |
| PBO, those formats are explicitly given by calls such as VertexPointer, |
| TexImage2D, or ReadPixels. When used as a buffer texture, it is |
| necessary to specify an internal format with which the bytes of the |
| buffer object's data store are interpreted. |
| |
| Another option considered was to greatly increase the maximum texture |
| size for 1D texture. This has the advantage of not requiring new |
| mechanisms. However, there are a couple limitations of this approach. |
| First, conventional textures have their own storage that is not |
| accessible elsewhere, which limits some of the sharing opportunities |
| described above. Second, buffer textures do have slightly different |
| hardware implementations than 1D textures. In the hardware of interest, |
| "normal" 1D textures can be mipmapped and filtered, but have a maximum |
| size that is considerably smaller than that supported for buffer |
| textures. If both texture types used the same API mechanism, it might |
| be necessary to reprogram texture hardware and/or shaders depending on |
| the size of the textures used. This will incur CPU overhead to |
| determine if such reprogramming is necessary and to perform the |
| reprogramming if so. |
| |
| (2) Since buffer textures borrow storage from buffer objects, whose |
| storage is visible to applications, a format must be imposed on the |
| bytes of the buffer object. What texture formats are supported for |
| buffer objects? |
| |
| RESOLVED: All sized one-, two-, and four-component internal formats |
| with 8-, 16-, and 32-bit components are supported. Unsized internal |
| formats, and sized formats with other component sizes are also not |
| supported. Three-component (RGB) formats are not supported due to |
| hardware limitations. |
| |
| All component data types supported for normal textures are also |
| supported for buffer textures. This includes unsigned [0,1] normalized |
| components (e.g., RGBA8), floating-point components from |
| ARB_texture_float (e.g., RGBA32F_ARB), signed and unsigned integer |
| components from EXT_texture_integer (e.g., RGBA8I_EXT, RGBA16UI_EXT), |
| and signed [-1,+1] normalized components from NV_texture_shader (e.g., |
| SIGNED_RGBA8_NV). |
| |
| (3) How can arrays of three-component vectors be accessed by applications? |
| |
| RESOLVED: Several approaches are possible. |
| |
| First, the vectors can be padded out to four components (RGBA), with an |
| extra unused component for each texel. This has a couple undesirable |
| properties: it adds 33% to the required storage and adding the extra |
| component may require reformatting of original data generated by the |
| application. However, the data in this format can be retrieved with a |
| single 32-, 64-, or 128-bit lookup. |
| |
| Alternately, the buffer texture can be defined using a single component, |
| and a shader can perform three lookups to separately fetch texels 3*N, |
| 3*N+1, and 3*N+2, combining the result in a three-component vector |
| representing "RGB" texel N. This doesn't require extra storage or |
| reformatting and doesn't require additional bandwidth for texture |
| fetches. But it does require additional shader instructions to obtain |
| each texel. |
| |
| (4) Does this extension support fixed-function fragment processing, |
| somehow allowing buffer textures to be accessed without programmable |
| shaders? |
| |
| RESOLVED: No. We expect that it would be difficult to properly access |
| a buffer texture and combine the returned texel with other color or |
| texture data, given the extremely limited programming model provided by |
| fixed-function fragment processing. |
| |
| Note also that the single-precision floating-point representation |
| commonly used by current graphics hardware is not sufficiently precise |
| to exactly represent all texels in a large buffer texture. For example, |
| it is not possible to represent 2^24+1 using the 32-bit IEEE |
| floating-point representation. |
| |
| (5) What happens if a buffer object is deleted or respecified when bound |
| to a buffer texture? |
| |
| RESOLVED: BufferData is allowed to be used to update a buffer object that |
| has already been bound to a texture with TexBuffer. The update to the data |
| is not guaranteed to affect the texture until next time it is bound to a |
| texture image unit. When DeleteBuffers is called, any buffer that is |
| bound to a texture is removed from the names array, but remains as long as |
| it is bound to a texture. The buffer is fully removed when the texture |
| unbinds it or when the texture buffer object is deleted. |
| |
| (6) Should applications be able to modify the data store of a buffer |
| object while it is bound to a buffer texture? |
| |
| RESOLVED: An application is allowed to update the data store for a buffer |
| object when the buffer object is bound to a texture. |
| |
| (7) Do buffer textures support texture parameters (TexParameter) or |
| queries (GetTexParameter, GetTexLevelParameter, GetTexImage)? |
| |
| RESOLVED: No. None of the existing parameters apply to buffer |
| textures, and this extension doesn't introduce the need for any new |
| ones. Buffer textures have no levels, and the size in texels is |
| implicit (based on the data store). Given that the texels themselves |
| are obtained from a buffer object, it seems more appropriate to retrieve |
| such data with buffer object queries. The only "parameter" of a buffer |
| texture is the internal format, which is specified at the same time the |
| buffer object is bound. |
| |
| Note that the spec edits above don't add explicit error language for any |
| of these cases. That is because each of the functions enumerate the set |
| of valid <target> parameters. Not editing the spec to allow |
| TEXTURE_BUFFER_ARB in these cases means that target is not legal, and an |
| INVALID_ENUM error should be generated. |
| |
| (8) What about indirect rendering with a mix of big- and little-endian |
| clients? If components are 16- or 32-bit, how are they interpreted? |
| |
| RESOLVED: Buffer object data are interpreted according to the native |
| representation of the server. If the server and client have different |
| endianness, applications must perform byte swapping as needed to match |
| the server's representation. No mechanism is provided to perform this |
| byte swapping on buffer object updates or when texels are fetched. |
| |
| The same problem also exists when buffer objects are used for vertex |
| arrays (VBO). For buffer objects used for pixel packing and unpacking |
| (ARB_pixel_buffer_object), the PixelStore byte swapping parameters |
| (PACK_SWAP_BYTES, UNPACK_SWAP_BYTES) would presumably apply and could be |
| used to perform the necessary byte swapping. |
| |
| (9) Should the set of formats supported for buffer textures be enumerated, |
| or should the extension instead nominally support all formats, but |
| accept only an implementation-dependent subset? |
| |
| RESOLVED: Provide a specified set of supported formats. This |
| extension simply enumerates all 8-, 16-, and 32-byte internal formats |
| with 1, 2, or 4 components, and specifies the mapping of unformatted |
| buffer object data to texture components. A follow-on extension could |
| be done to support 3-component texels when better native hardware |
| support is available. |
| |
| Other than 3-component texels, the set of formats supported seems pretty |
| compehensive. We expect that buffer textures would be used for general |
| computational tasks, where there is little need for formats with smaller |
| components (e.g., RGBA4444). Such formats are generally not supported |
| natively on CPUs today. With the general computational model provided |
| by NV_gpu_program4 and EXT_gpu_shader4, it would be possible to treat |
| such "packed" formats as larger single-component formats and unpack them |
| with a small number of shader instructions. |
| |
| If and when double-precision floats or 64-bit integers are supported as |
| basic types usable by shaders, we would expect that an extension would |
| add new texture internal formats with 64-bit components and that those |
| formats would also be supported for general-purpose textures and buffer |
| textures as well. |
| |
| (10) How are buffer textures supported in GLSL? |
| |
| RESOLVED: Create a new sampler type (samplerBuffer) for buffer textures |
| and add a new lookup function (texelFetchBuffer) to explicitly access |
| them using texture hardware. |
| |
| Other possibilities considered included extending the notion of bindable |
| uniforms to support uniforms whose corresponding buffer objects can be |
| bound to texture resources (e.g., "texture bindable uniform" instead of |
| "bindable uniform"). We also considered automatically assigning |
| bindable uniforms to texture or shader resources as appropriate. Note |
| that the restrictions, size limits, and performance characterstics of |
| buffer textures and parameter buffers (NV_parameter_buffer_object) |
| differ. Automatic handling of uniforms adds driver complexity and may |
| tend to hide performance characteristics since it isn't clear what |
| resource would be used for what variable. Additionally, it could |
| require shader recompilation if the size of a uniform array is variable, |
| and the hardware resource used depended on the size. |
| |
| In the end, the texture approach seemed the simplest, and we chose that. |
| It might be worth doing something more complex in the future. |
| |
| (11) What is the TEXTURE_BUFFER_ARB buffer object binding point good for? |
| |
| RESOLVED: It can be used for loading data into buffer objects, and for |
| mapping and unmapping buffers, both without disturbing other binding |
| points. Otherwise, it has no effect on GL operations, since buffer |
| objects are bound to textures using the TexBufferARB() command that does |
| not affect the buffer object binding point. |
| |
| Buffer object binding points have mixed usage. In the |
| EXT_vertex_buffer_object extension (OpenGL 1.5), there are two binding |
| points. The ELEMENT_ARRAY_BUFFER has a direct effect on rendering, as |
| it modifies DrawElements() calls. The effect of ARRAY_BUFFER is much |
| more indirect; it is only used to affect subsequent vertex array calls |
| (e.g., VertexPointer) and has no direct effect on rendering. The reason |
| for this is that the API was retrofitted on top of existing vertex array |
| APIs. If a new vertex array API were created that emphasized or even |
| required the use of buffer objects, it seems likely that the buffer |
| object would be included in the calls equivalent to today's |
| VertexPointer() call. |
| |
| (12) How is the various buffer texture-related state queried? |
| |
| RESOLVED: There are three pieces of state that can be queried: (a) the |
| texture object bound to buffer texture binding point for the active |
| texture image unit, (b) the buffer object whose data store was used by |
| that texture object, and (c) the buffer object bound to the |
| TEXTURE_BUFFER_ARB binding point. |
| |
| All three are queried with GetIntegerv, because it didn't seem worth the |
| trouble to add one or more new query functions. Note that for (a) and |
| (b), the texture queried is the one bound to TEXTURE_BUFFER_ARB on the |
| active texture image unit. |
| |
| (13) Should we provide a new set of names for the signed normalized |
| textures introduced in NV_texture_shader that match the convention |
| used for floating-point and integer textures? |
| |
| RESOLVED: No. |
| |
| (14) Can a buffer object be attached to more than one buffer texture at |
| once? |
| |
| RESOLVED: Multiple buffer textures may attach to the same buffer object |
| simultaneously. |
| |
| (15) How does this extension interact with display lists? |
| |
| RESOLVED: Buffer object commands can't be compiled into a display list. |
| The new command in this extension uses buffer objects, so we specify |
| that it also can't be compiled into a display list. |
| |
| Revision History |
| |
| Rev. Date Author Changes |
| ---- -------- -------- ----------------------------------------- |
| 8 06/04/15 srahman Add GLX protocol specification. |
| |
| 7 07/09/13 Jon Leech Correct suffix on |
| TEXTURE_BUFFER_DATA_STORE_BINDING_ARB |
| (was EXT). |
| |
| 6 6/30/08 js Trivial conversion to ARB from EXT |
| |
| |
| 5 04/16/08 pbrown Clarify that either NV_gpu_program4 or |
| EXT_gpu_shader4 is required, not simply |
| NV_gpu_program4. |
| |
| 4 10/30/07 ewerness Add resolutions to various issues |
| |
| 3 -- Pre-release revisions. |
