blob: cc5eae772e41d43d21bb5936ad710fda257a1229 [file] [log] [blame]
Name Strings
Pat Brown, NVIDIA Corporation (pbrown 'at'
Copyright (c) 2008-2013 The Khronos Group Inc. Copyright terms at
Specification Update Policy
Khronos-approved extension specifications are updated in response to
issues and bugs prioritized by the Khronos OpenGL Working Group. For
extensions which have been promoted to a core Specification, fixes will
first appear in the latest version of that core Specification, and will
eventually be backported to the extension document. This policy is
described in more detail at
Approved by the ARB on July 11, 2008
Last Modified Date: 06/04/2015
Revision: 8
ARB Extension #51
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.
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
Accepted by the <pname> parameters of GetBooleanv, GetDoublev,
GetFloatv, and GetIntegerv:
Additions to Chapter 2 of the OpenGL 2.0 Specification (OpenGL Operation)
Additions to Chapter 3 of the OpenGL 2.0 Specification (Rasterization)
(Insert new Section 3.8.4, Buffer Textures. Renumber subsequent
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
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.
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 . .
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,
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,
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_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,
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,
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
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)
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,
(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
void GetBufferPointerv( enum target, enum pname, void **params );
Additions to Appendix A of the OpenGL 2.0 Specification (Invariance)
Additions to the AGL/GLX/WGL Specifications
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:
2 16 rendering command length
2 367 rendering command opcode
4 ENUM target
4 ENUM internalformat
4 CARD32 buffer
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)
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
(add to table 6.16, Texture State Per Texture Object, p. 276)
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_BUFFER_FORMAT_ARB nxZ+ GetIntegerv LUMIN- Internal format for the 3.8.12 texture
ANCE8 active image unit's buffer
(add to table 6.37, Miscellaneous State, p. 298)
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)
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
(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.,
(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
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?
(14) Can a buffer object be attached to more than one buffer texture at
RESOLVED: Multiple buffer textures may attach to the same buffer object
(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
(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
4 10/30/07 ewerness Add resolutions to various issues
3 -- Pre-release revisions.