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.