back  Return to list

homeprevnext Name
homeprevnext Name Strings
homeprevnext Contact
    Pat Brown, NVIDIA Corporation (pbrown 'at'  
homeprevnext Status
    Shipping for GeForce 8 Series (November 2006, Release 95)  
homeprevnext Version
    Last Modified Date:         10/30/2007  
    NVIDIA Revision:            4  
homeprevnext Number
homeprevnext Dependencies
    OpenGL 2.0 is required.  
    NV_gpu_program4 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.  
homeprevnext 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, 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.  
homeprevnext New Procedures and Functions
    void TexBufferEXT(enum target, enum internalformat, uint buffer);  
homeprevnext New Tokens
    Accepted by the <target> parameter of BindBuffer, BufferData,  
    BufferSubData, MapBuffer, BindTexture, UnmapBuffer, GetBufferSubData,  
    GetBufferParameteriv, GetBufferPointerv, and TexBufferEXT, and  
    the <pname> parameter of GetBooleanv, GetDoublev, GetFloatv, and  
        TEXTURE_BUFFER_EXT                              0x8C2A  
    Accepted by the <pname> parameters of GetBooleanv, GetDoublev,  
    GetFloatv, and GetIntegerv:  
        MAX_TEXTURE_BUFFER_SIZE_EXT                     0x8C2B  
        TEXTURE_BINDING_BUFFER_EXT                      0x8C2C  
        TEXTURE_BUFFER_FORMAT_EXT                       0x8C2E  
homeprevnext Additions to Chapter 2 of the OpenGL 2.0 Specification (OpenGL Operation)
homeprevnext 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 TexBufferEXT(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_EXT.  <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_EXT.  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 . .  
      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_EXT, in order to  
    specify, modify, or read the buffer object's data store.  The buffer  
    object bound to TEXTURE_BUFFER_EXT has no effect on rendering.  A buffer  
    object is bound to TEXTURE_BUFFER_EXT by calling BindBuffer with <target>  
    set to TEXTURE_BUFFER_EXT.  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_EXT.  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_EXT 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_EXT, 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_EXT. 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_EXT 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_EXT 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  
    TEXTURE_BUFFER_EXT 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.  
homeprevnext Additions to Chapter 4 of the OpenGL 2.0 Specification (Per-Fragment Operations and the Frame Buffer)
homeprevnext 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 TexBufferEXT.  
homeprevnext 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 );  
    with target set to ARRAY_BUFFER, ELEMENT_ARRAY_BUFFER, or  
homeprevnext Additions to Appendix A of the OpenGL 2.0 Specification (Invariance)
homeprevnext Additions to the AGL/GLX/WGL Specifications
homeprevnext 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.  
homeprevnext 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 TexBufferEXT.  
homeprevnext 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 TexBufferEXT.  
homeprevnext 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 TexBufferEXT.  
homeprevnext 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 TexBufferEXT.  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.  
homeprevnext Errors
    INVALID_OPERATION is generated by TexBufferEXT if <buffer> is non-zero and  
    is not the name of an existing buffer object.  
homeprevnext 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_EXT          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_EXT                                                   the data store for the   
                                                                    active image unit's buffer  
    TEXTURE_BUFFER_FORMAT_EXT           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_EXT                   Z+     GetIntegerv    0    Buffer object bound to      3.8.12  texture  
                                                                    the generic buffer texture  
                                                                    binding point  
homeprevnext New Implementation Dependent State
    (modify Table 6.32, p. 293)  
    Get Value                    Type  Get Command   Value   Description            Sec.   Attribute  
    ---------------------------  ----  -----------  -------  ---------------------  -----  ---------  
    MAX_TEXTURE_BUFFER_SIZE_EXT   Z+   GetIntegerv   65536   number of addressable  3.8.4      -  
                                                             texels for buffer  
homeprevnext 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.  
        EXT_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_EXT 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_EXT 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 TexBufferEXT() 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_EXT 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_EXT 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  
      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.  
homeprevnext Revision History
    Rev.    Date    Author    Changes  
    ----  --------  --------  -----------------------------------------  
      4   10/30/07  ewerness  Add resolutions to various issues  
      3      --               Pre-release revisions.  
      3      --               Pre-release revisions.  
Valid XHTML 1.1! Valid CSS! Last update: November 14, 2006.
Cette page doit être lue avec un navigateur récent respectant le standard XHTML 1.1.