NV_pixel_buffer_object

GL_NV_pixel_buffer_object

Contributors to ARB_pixel_buffer_object
Greg Roth, NVIDIA

Mathias Heyer, NVIDIA Corporation (mheyer 'at' nvidia.com) 

Complete.

Last Modified Date: April 27th, 2020
Revision: 3.0

OpenGL ES Extension #134

Written based on the wording of the OpenGL ES 2.0 specification.

OES_mapbuffer affects the definition of this specification
EXT_map_buffer_range affects the definition of this specification 

This extension permits buffer objects to be used not only with vertex
array data, but also with pixel data.  The intent is to provide more
acceleration opportunities for OpenGL pixel commands.

While a single buffer object can be bound for both vertex arrays and
pixel commands, we use the designations vertex buffer object (VBO)
and pixel buffer object (PBO) to indicate their particular usage in
a given situation.

This extension does not add any new functionality to buffer objects
themselves.  It simply adds two new targets to which buffer objects
can be bound: GL_PIXEL_PACK_BUFFER_NV and GL_PIXEL_UNPACK_BUFFER_NV.
When a buffer object is bound to the GL_PIXEL_PACK_BUFFER_NV target,
commands such as glReadPixels pack (write) their data into a buffer
object. When a buffer object is bound to the GL_PIXEL_UNPACK_BUFFER_NV
target, commands such as glTexImage2D unpack (read) their
data from a buffer object.

There are a several approaches to improve graphics performance
with PBOs.  Some of the most interesting approaches are:

- Streaming texture updates:  If the application uses
  glMapBufferOES/glMapBufferRangeEXT/glUnmapBufferOES to write
  its data for glTexSubImage into a buffer object, at least one of
  the data copies usually required to download a texture can be
  eliminated, significantly increasing texture download performance.

- Asynchronous glReadPixels:  If an application needs to read back a
  number of images and process them with the CPU, the existing GL
  interface makes it nearly impossible to pipeline this operation.
  The driver will typically send the hardware a readback command
  when glReadPixels is called, and then wait for all of the data to
  be available before returning control to the application.  Then,
  the application can either process the data immediately or call
  glReadPixels again; in neither case will the readback overlap with
  the processing.  If the application issues several readbacks
  into several buffer objects, however, and then maps each one to
  process its data, then the readbacks can proceed in parallel with
  the data processing.

- Render to vertex array:  The application can use a fragment
  program to render some image into one of its buffers, then read
  this image out into a buffer object via glReadPixels.  Then, it can
  use this buffer object as a source of vertex data.

None.

Accepted by the <target> parameters of BindBuffer, BufferData,
BufferSubData, MapBufferOES, MapBufferRangeEXT, UnmapBufferOES,
FlushMappedBufferRangeEXT, GetBufferParameteriv, and
GetBufferPointervOES:

    PIXEL_PACK_BUFFER_NV                        0x88EB
    PIXEL_UNPACK_BUFFER_NV                      0x88EC

Accepted by the <pname> parameter of GetBooleanv, GetIntegerv,
GetFloatv:

    PIXEL_PACK_BUFFER_BINDING_NV                0x88ED
    PIXEL_UNPACK_BUFFER_BINDING_NV              0x88EF

Replace the first two paragraphs with:

"The vertex data arrays described in section 2.8 are stored in
client memory.  It is sometimes desirable to store frequently accessed
client data, such as vertex array and pixel data, in high-performance
server memory.  GL buffer objects provide a mechanism for clients to
use to allocate, initialize, and access such memory."

The name space for buffer objects is the unsigned integer, with zero
reserved for the GL.  A buffer object is created by binding an unused
name to a buffer target.  The binding is effected by calling

   void BindBuffer(enum target, uint buffer);

<target> must be one of ARRAY_BUFFER, ELEMENT_ARRAY_BUFFER,
PIXEL_UNPACK_BUFFER_NV, or PIXEL_PACK_BUFFER_NV.  The ARRAY_BUFFER
target is discussed in section 2.9.1  The ELEMENT_ARRAY_BUFFER target
is discussed in section 2.9.2.  The PIXEL_UNPACK_BUFFER_NV and
PIXEL_PACK_BUFFER_NV targets are discussed later in sections 3.7.1 and
4.3.  If the buffer object named <buffer> has not been
previously bound or has been deleted since the last binding, the
GL creates a new state vector, initialized with a zero-sized memory
buffer and comprising the state values listed in table 2.5."

Replace the 5th paragraph with:

"Initially, each buffer object target is bound to zero.  There is
no buffer object corresponding to the name zero so client attempts
to modify or query buffer object state for a target bound to zero
generate an INVALID_OPERATION error."

Replace the phrase listing the valid targets for BufferData in the
9th paragraph with:

"with <target> set to one of ARRAY_BUFFER, ELEMENT_ARRAY_BUFFER,
PIXEL_UNPACK_BUFFER_NV, or PIXEL_PACK_BUFFER_NV,"

In the 10th paragraph describing buffer object usage modes, replace
the phrase "specified once" with "specified once per repetition of
the usage pattern" for the STREAM_* and STATIC_* usage values.

Also in the 10th paragraph describing buffer object usage modes,
replace the phrases "of a GL drawing command." and "for GL drawing
commands." with "for GL drawing and image specification commands." for
the *_DRAW usage values.

Replace the phrase listing the valid targets for BufferSubData with:

"with <target> set to one of ARRAY_BUFFER, ELEMENT_ARRAY_BUFFER,
PIXEL_UNPACK_BUFFER_NV, or PIXEL_PACK_BUFFER_NV."

Replace the phrase listing the valid targets for MapBufferOES with:

"with <target> set to one of ARRAY_BUFFER, ELEMENT_ARRAY_BUFFER,
PIXEL_UNPACK_BUFFER_NV, or PIXEL_PACK_BUFFER_NV."

Replace the phrase listing the valid targets for UnmapBufferOES with:

"with <target> set to one of ARRAY_BUFFER, ELEMENT_ARRAY_BUFFER,
PIXEL_UNPACK_BUFFER_NV, or PIXEL_PACK_BUFFER_NV."

Replace the phrase listing the valid targets for MapBufferRangeEXT
with:

"with <target> set to one of ARRAY_BUFFER, ELEMENT_ARRAY_BUFFER,
PIXEL_UNPACK_BUFFER_NV, or PIXEL_PACK_BUFFER_NV."

Replace the phrase listing the valid targets for
FlushMappedBufferRangeEXT with:

"with <target> set to one of ARRAY_BUFFER, ELEMENT_ARRAY_BUFFER,
PIXEL_UNPACK_BUFFER_NV, or PIXEL_PACK_BUFFER_NV."

Delete the 3rd paragraph that explains how the ELEMENT_ARRAY_BUFFER
target is acceptable for the commands specified in section 2.9.
The updated section 2.9 language already says this.

Replace the last two paragraphs with:

"This section describes only how these rectangles are defined in
 buffer object and client memory, and the steps involved in
 transferring pixel rectangles from buffer object or client memory
 to the GL or vice-versa.
 Parameters controlling the encoding of pixels in buffer object or
 client memory (for reading and writing) are set with the command
 PixelStorei."

Add to the end of the section:

"In addition to storing pixel data in client memory, pixel data
may also be stored in buffer objects (described in section 2.9).
The current pixel unpack and pack buffer objects are designated
by the PIXEL_UNPACK_BUFFER_NV and PIXEL_PACK_BUFFER_NV targets
respectively.

Initially, zero is bound for the PIXEL_UNPACK_BUFFER_NV, indicating
that image specification commands such as TexImage*D source their
pixels from client memory pointer parameters.  However, if a non-zero
buffer object is bound as the current pixel unpack buffer, then
the pointer parameter is treated as an offset into the designated
buffer object."

Change the 1st sentence of the 1st paragraph to read:

"The process of transferring pixels encoded in buffer object
 or client memory is diagrammed in figure 3.5."

Change the 4th sentence of the 2nd paragraph to read:

"<data> refers to the data to be transferred."

[data is no longer necessarily a pointer.]

Change the initial phrase in the 1st sentence of the 1st paragraph
in subsection "Unpacking" to read:

"Data are taken from the currently bound pixel unpack buffer or
client memory as a sequence of..."

Insert this paragraph after the 1st paragraph in subsection 
"Unpacking":

"If a pixel unpack buffer is bound (as indicated by a non-zero
value of PIXEL_UNPACK_BUFFER_BINDING_NV), <data> is an offset
into the pixel unpack buffer and the pixels are unpacked from the
buffer relative to this offset; otherwise, <data> is a pointer to
a block client memory and the pixels are unpacked from the client
memory relative to the pointer.  If a pixel unpack buffer object
is bound and unpacking the pixel data according to the process
described below would access memory beyond the size of the pixel
unpack buffer's memory size, INVALID_OPERATION results.  If a pixel
unpack buffer object is bound and <data> is not evenly divisible
into the number of basic machine units needed to store in memory the
corresponding GL data type from table 3.4 for the <type> parameter,
INVALID_OPERATION results."

Replace the last phrase in the 2nd to last sentence in the 1st
paragraph with:

"and a reference to the image data in the currently bound pixel unpack
buffer or client memory, as described in section 3.6.2."

Replace the 1st sentence in the 9th paragraph with:

"The image itself (referred to by <data>) is a sequence of groups
of values."

Replace the last paragraph with:

"If the data argument of TexImage2D is a NULL pointer, and the
 pixel unpack buffer object is zero, a two- or three-dimensional
 texel array is created with the specified target, level, internalformat,
 border, width, height, and depth, but with unspecified image contents.
 In this case no pixel values are accessed in client memory, and no pixel
 processing is performed. Errors are generated, however, exactly as though
 the data pointer were valid. Otherwise if the pixel unpack buffer object
 is non-zero, the data argument is treatedly normally to refer to the
 beginning of the pixel unpack buffer object's data."

Replace the 3rd sentence of the 2nd paragraph with:

"<data> refers to compressed image data stored in the compressed
image format corresponding to internalformat.  If a pixel
unpack buffer is bound (as indicated by a non-zero value of
PIXEL_UNPACK_BUFFER_BINDING_NV), <data> is an offset into the
pixel unpack buffer and the compressed data is read from the buffer
relative to this offset; otherwise, <data> is a pointer to a block
client memory and the compressed data is read from the client memory
relative to the pointer."

Replace the 2nd sentence in the 3rd paragraph with:

"Compressed texture images are treated as an array of <imageSize>
ubytes relative to <data>.  If a pixel unpack buffer object is bound
and data+imageSize is greater than the size of the pixel buffer,
INVALID_OPERATION results."

Replace the first paragraph with:

"Pixels may be read from the framebuffer to pixel pack buffer or 
 client memory using the ReadPixels commands, as described below.
 Pixels may also be copied from pixel unpack buffer, client memory or
 the framebuffer to texture images in the GL using the TexImage2D and
 CopyTexImage2D commands, as described in section 3.7.1.

Replace 1st sentence of the 1st paragraph with:

"The method for reading pixels from the framebuffer and placing them in
pixel pack buffer or client memory is diagrammed in figure 4.2."

Add this paragraph after the 1st paragraph:

"Initially, zero is bound for the PIXEL_PACK_BUFFER_NV, indicating
that image read and query commands such as ReadPixels return
pixels results into client memory pointer parameters.  However, if
a non-zero buffer object is bound as the current pixel pack buffer,
then the pointer parameter is treated as an offset into the designated
buffer object."

Rename "Placement in Client Memory" to "Placement in Pixel Pack
Buffer or Client Memory".

Insert this paragraph at the start of the newly renamed
subsection "Placement in Pixel Pack Buffer or Client Memory":

"If a pixel pack buffer is bound (as indicated by a non-zero value
of PIXEL_PACK_BUFFER_BINDING_NV), <data> is an offset into the
pixel pack buffer and the pixels are packed into the
buffer relative to this offset; otherwise, <data> is a pointer to a
block client memory and the pixels are packed into the client memory
relative to the pointer.  If a pixel pack buffer object is bound and
packing the pixel data according to the pixel pack storage state
would access memory beyond the size of the pixel pack buffer's
memory size, INVALID_OPERATION results.  If a pixel pack buffer object
is bound and <data> is not evenly divisible into the number of basic
machine units needed to store in memory the corresponding GL data type
from table 3.5 for the <type> parameter, INVALID_OPERATION results."

None

Change the 1st sentence of the 3rd paragraph to read:
"The command
    void GetBufferParameteriv( enum target, enum value, T data );
returns information about <target>, which may be one of ARRAY_BUFFER,
ELEMENT_ARRAY_BUFFER, PIXEL_PACK_BUFFER_NV, PIXEL_UNPACK_BUFFER_NV
indicating the currently bound vertex array, element array, pixel pack
and pixel unpack buffer object."

(description of glGetBufferPointervOES)  
Change the 2nd sentence of the 2nd paragraph to read:
"<target> is ARRAY_BUFFER, ELEMENT_ARRAY_BUFFER, PIXEL_PACK_BUFFER_NV,
or PIXEL_UNPACK_BUFFER_NV."

INVALID_ENUM is generated if the <target> parameter of
BindBuffer, BufferData, BufferSubData, MapBufferOES, UnmapBufferOES,
GetBufferParameteriv or GetBufferPointervOES is not
one of ARRAY_BUFFER, ELEMENT_ARRAY_BUFFER, PIXEL_PACK_BUFFER_NV,
or PIXEL_UNPACK_BUFFER_NV.

INVALID_OPERATION is generated if CompressedTexImage2D, 
CompressedTexSubImage2D, TexImage2D or TexSubImage2D would unpack
(read) data from the currently bound PIXEL_UNPACK_BUFFER_NV buffer
object such that the memory reads required for the command would exceed
the memory (data store) size of the buffer object.

INVALID_OPERATION is generated if ReadPixels or ReadnPixelsEXT 
would pack (write) data to the currently bound PIXEL_PACK_BUFFER_NV
buffer object such that the memory writes required for the command would
exceed the memory (data store) size of the buffer object.

INVALID_OPERATION is generated by ReadPixels or ReadnPixelsEXT
if the current PIXEL_PACK_BUFFER_BINDING_NV value is non-zero and the
table/image/values/span/img/data parameter is not evenly divisible
into the number of basic machine units needed to store in memory a
datum indicated by the type parameter.

INVALID_OPERATION is generated by TexImage2D or TexSubImage2D
if current PIXEL_UNPACK_BUFFER_BINDING_NV value is non-zero and the data
parameter is not evenly divisible into the number of basic machine
units needed to store in memory a datum indicated by the type
parameter.

If OES_mapbuffer is not present, references to MapBufferOES and
UnmapBufferOES should be ignored and language referring to mapped
buffer objects should be removed.

If EXT_map_buffer_range is not present, references to
MapBufferRangeEXT anf FlushMappedBufferRangeEXT should be ignored.

                                                     Initial
Get Value                        Type   Get Command  Value    Sec    
-------------------------------  ----   -----------  -------  ------ 
PIXEL_PACK_BUFFER_BINDING_NV    Z+     GetIntegerv  0        4.3.1  
PIXEL_UNPACK_BUFFER_BINDING_NV  Z+     GetIntegerv  0        3.6.1  

Convenient macro definition for specifying buffer offsets:

    #define BUFFER_OFFSET(i) ((char *)NULL + (i))

Example 1: Render to vertex array:

    const int numberVertices = 100;

    // Create a buffer object for a number of vertices consisting of
    // 4 float values per vertex
    glGenBuffers(1, vertexBuffer);
    glBindBuffer(GL_PIXEL_PACK_BUFFER_NV, vertexBuffer);
    glBufferData(GL_PIXEL_PACK_BUFFER_NV, numberVertices*4,
                 NULL, GL_DYNAMIC_DRAW);

    // Render vertex data into 100x1 strip of framebuffer using a
    // shader program
    glUseProgram(program);
    renderVertexData();
    glBindProgramARB(FRAGMENT_PROGRAM_ARB, 0);

    // Read the vertex data back from framebuffer
    glReadPixels(0, 0, numberVertices, 1, GL_BGRA, GL_UNSIGNED_BYTE,
                 BUFFER_OFFSET(0));

    // Change the binding point of the buffer object to
    // the vertex array binding point
    glBindBuffer(GL_ARRAY_BUFFER, vertexBuffer);

    glEnableVertexAttribArray(0);
    glVertexAttribPointer(0, 4, GL_UNSIGNED_BYTE, GL_TRUE, 0, BUFFER_OFFSET(0));
    glDrawArrays(TRIANGLE_STRIP, 0, numberVertices);


Example 2: Streaming textures

Streaming textures using pixel buffer objects:

    const int texWidth = 256;
    const int texHeight = 256;
    const int texsize = texWidth * texHeight * 4;
    void *pboMemory, *texData;

    // Define texture level zero (without an image); notice the
    // explicit bind to the zero pixel unpack buffer object so that
    // pass NULL for the image data leaves the texture image
    // unspecified.
    glBindBuffer(GL_PIXEL_UNPACK_BUFFER_NV, 0);
    glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA, texWidth, texHeight, 0,
                 GL_RGBA, GL_UNSIGNED_BYTE, NULL);

    // Create and bind texture image buffer object
    glGenBuffers(1, &texBuffer);
    glBindBuffer(GL_PIXEL_UNPACK_BUFFER_NV, texBuffer);

    // Setup texture environment
    ...

    texData = getNextImage();

    while (texData) {

        // Reset the contents of the texSize-sized buffer object
        glBufferData(GL_PIXEL_UNPACK_BUFFER_NV, texSize, NULL,
                     GL_STREAM_DRAW);

        // Map the texture image buffer (the contents of which
        // are undefined due to the previous glBufferData)
        pboMemory = glMapBufferOES(GL_PIXEL_UNPACK_BUFFER_NV,
                                GL_WRITE_ONLY);

        // Modify (sub-)buffer data
        memcpy(pboMemory, texData, texsize);

        // Unmap the texture image buffer
        glUnmapBufferOES(GL_PIXEL_UNPACK_BUFFER_NV);

        // Update (sub-)teximage from texture image buffer
        glTexSubImage2D(GL_TEXTURE_2D, 0, 0, 0, texWidth, texHeight,
                        GL_RGBA, GL_UNSIGNED_BYTE, BUFFER_OFFSET(0));

        // Draw textured geometry
        ...

        texData = getNextImage();
    }

    glBindBuffer(GL_PIXEL_UNPACK_BUFFER_NV, 0);


Example 3: Asynchronous glReadPixels

Traditional glReadPixels:

    const int imagewidth = 640;
    const int imageheight = 480;
    GLubyte readBuffer[imagewidth*imageheight*4];

    // Render to framebuffer
    renderScene()

    // Read image from framebuffer
    glReadPixels(0, 0, imagewidth, imageheight, GL_RGBA,
                 GL_UNSIGNED_BYTE, readBuffer);

    // Process image when glReadPixels returns after reading the
    // whole buffer
    processImage(readBuffer);


Asynchronous glReadPixels:

    const int imagewidth = 640;
    const int imageheight = 480;
    const int imageSize = imagewidth*imageheight*4;

    glGenBuffers(2, imageBuffers);

    glBindBuffer(GL_PIXEL_PACK_BUFFER_NV, imageBuffers[0]);
    glBufferData(GL_PIXEL_PACK_BUFFER_NV, imageSize / 2, NULL,
                 GL_STREAM_DRAW);

    glBindBuffer(GL_PIXEL_PACK_BUFFER_NV, imageBuffers[1]);
    glBufferData(GL_PIXEL_PACK_BUFFER_NV, imageSize / 2, NULL,
                 GL_STREAM_DRAW);

    // Render to framebuffer
    glDrawBuffer(GL_BACK);
    renderScene();

    // Bind two different buffer objects and start the glReadPixels
    // asynchronously. Each call will return directly after
    // starting the DMA transfer.
    glBindBuffer(GL_PIXEL_PACK_BUFFER_NV, imageBuffers[0]);
    glReadPixels(0, 0, imagewidth, imageheight/2, GL_RGBA,
                 GL_UNSIGNED_BYTE, BUFFER_OFFSET(0));

    glBindBuffer(GL_PIXEL_PACK_BUFFER_NV, imageBuffers[1]);
    glReadPixels(0, imageheight/2, imagewidth, imageheight/2, GL_RGBA,
                 GL_UNSIGNED_BYTE, BUFFER_OFFSET(0));

    // Process partial images.  Mapping the buffer waits for
    // outstanding DMA transfers into the buffer to finish.
    glBindBuffer(GL_PIXEL_PACK_BUFFER_NV, imageBuffers[0]);
    pboMemory1 = glMapBufferRangeEXT(GL_PIXEL_PACK_BUFFER_NV, 0,
                                     imageSize/2, GL_MAP_READ_BIT_EXT);
    processImage(pboMemory1);
    glBindBuffer(GL_PIXEL_PACK_BUFFER_NV, imageBuffers[1]);
    pboMemory2 = glMapBufferRangeEXT(GL_PIXEL_PACK_BUFFER_NV, 0,
                                     imageSize/2, GL_MAP_READ_BIT_EXT);
    processImage(pboMemory2);

    // Unmap the image buffers
    glBindBuffer(GL_PIXEL_PACK_BUFFER_NV, imageBuffers[0]);
    glUnmapBuffer(GL_PIXEL_PACK_BUFFER_NV);
    glBindBuffer(GL_PIXEL_PACK_BUFFER_NV, imageBuffers[1]);
    glUnmapBuffer(GL_PIXEL_PACK_BUFFER_NV);

1)  Can a given buffer be used for both vertex and pixel data?

    RESOLVED: YES.  All buffers can be used with all buffer bindings,
    in whatever combinations the application finds useful.  Consider
    yourself warned, however, by the following issue.

2)  May implementations make use of the target as a hint to select
    an appropriate memory space for the buffer?

    RESOLVED: YES, as long as such behavior is transparent to the
    application. Some implementations may choose different memory 
    spaces for different targets.
    In fact, one can imagine arbitrarily complicated heuristics for
    selecting the memory space, based on factors such as the target,
    the "usage" argument, and the application's observed behavior.

    While it is entirely legal to create a buffer object by binding
    it to GL_ARRAY_BUFFER and loading it with data, then using it
    with the GL_PIXEL_UNPACK_BUFFER_NV or GL_PIXEL_PACK_BUFFER_NV
    binding, such behavior is liable to confuse the driver and may
    hurt performance.  If the driver implemented the hypothetical
    heuristic described earlier, such a buffer might have already
    been located in AGP memory, and so the driver would have to choose
    between two bad options: relocate the buffer into video memory, or
    accept lower performance caused by streaming pixel data from AGP.

3)  Should the INVALID_OPERATION error be generated if a pixel
    command would access data outside the range of the bound PBO?

    RESOLVED:  YES.  This requires considering the command parameters
    (such as width/height/depth/format/type/pointer), the current
    pixel store (pack/unpack) state, and the command operation itself
    to determine the maximum addressed byte for the pixel command.

    This behavior should increase the reliability of using PBO and
    guard against programmer mistakes.

    This is particularly important for glReadPixels where returning
    data into a region outside the PBO could cause corruption of
    application memory.

    Such bounds checking is substantially more expensive for VBO
    accesses because bounds checking on a per-vertex element basis
    for each of multiple enabled vertex arrays prior to performing
    the command compromises the performance justification of VBO.

 4) If a pixel command with a bound PBO accesses data outside the
    range of the PBO, thereby generating a GL_INVALID_OPERATION error,
    can the pixel command end up being partially processed?

    RESOLVED:  NO.  As for all GL errors excepting GL_OUT_OF_MEMORY
    situations, "the command generating the error is ignored so that
    it has no effect on GL state or framebuffer contents."

    This means implementations must determine before the pixel command
    is performed whether the resulting read or write operations on
    the bound PBO will exceed the size of the PBO.

    This means an implementation is NOT allowed to detect out of
    bounds accesses in the middle of performing the command.
  
 5) Should an INVALID_OPERATION error be generated if the offset
    within a pixel buffer to a datum comprising of N basic machine
    units is not a multiple of N?

    RESOLVED:  YES.  This was stated for VBOs but no error was
    defined if the rule was violated.  Perhaps this needs to be
    better specified for VBO.

    For PBO, it is reasonable and cheap to enforce the alignment rule.
    For pixel commands it means making sure the offset is evenly
    divisible by the component or group size in basic machine units.

    This check is independent of the pixel store state because the
    pixel store state is specified in terms of pixels (not basic
    machine units) so pixel store addressing cannot create an
    unaligned access as long as the base offset is aligned.

    Certain commands (specifically,
    glCompressedTexImage2D, glCompressedTexSubImage2D) are not
    affected by this error because the data accessed is addressed
    at the granularity of basic machine units.

 6) Various commands do not make explicit reference to supporting
    packing or unpacking from a pixel buffer object but rather specify
    that parameters are handled in the same manner as glReadPixels,
    or the glCompressedTexImage commands.  So do such
    commands (example: glCompressedTexSubImage2D) use pixel buffers?

    RESOLVED:  YES.  Commands that have their behavior defined based
    on commands that read or write from pixel buffers will themselves
    read or write from pixel buffers.  Relying on this reduces the
    amount of specification language to be updated.

 7) What is the complete list of commands that can unpack (read)
    pixels from the current pixel unpack buffer object?

        glCompressedTexImage2D
        glCompressedTexSubImage2D
        glTexImage2D
        glTexSubImage2D

 8) What is the complete list of commands that can pack (write)
    pixels into the current pixel pack buffer object?

        glReadPixels

 9) Prior to this extension, passing zero for the data argument of
    glTexImage2D defined a texture image level without supplying an image.
    How does this behavior change with this extension?

    RESOLVED:  The "unspecified image" behavior of the glTexImage
    calls only applies when bound to a zero pixel unpack buffer
    object.

    When bound to a non-zero pixel unpack buffer object, the data
    argument to these calls is treated as an offset rather than
    a pointer so zero is a reasonable and even likely value that
    corresponds to the very beginning of the buffer object's data.

    So to create a texture image level with unspecified image data,
    you MUST bind to the zero pixel unpack buffer object.

    See the ammended language at the end of section 3.7.1.

10) How does this extension support video frame grabbers?

    RESOLVED:  This extension extends buffer objects so they can
    operate with pixel commands, rather than just vertex array
    commands.

    We anticipate that a future extension may provide a mechanism
    for transferring video frames from video frame grabber hardware
    or vertices from motion capture hardware (or any other source
    of aquired real-time data) directly into a buffer object to
    eliminate a copy.  Ideally, such transfers would be possible
    without requiring mapping of the buffer object.  But this
    extension does not provide such functionality.

    We anticipate such functionality to involve binding a buffer
    object to a new target type, configuring a source (or sink) for
    data (video frames, motion capture vertex sets, etc.), and then
    commands to initiate data transfers to the bound buffer object.
    
11) Is this the "right" way to expose render-to-vertex-array?

    DISCUSSION:  You can use this extension to render an image
    into a framebuffer, copy the pixels into a buffer object with
    glReadPixels, and then configure vertex arrays to source the pixel
    data as vertex attributes.  This necessarily involves a copy
    from the framebuffer to the buffer object.  Future extensions
    may provide mechanisms for copy-free render-to-vertex-array
    capabilities but that is not a design goal of this extension.

3   04/27/2020 fix example code: GL_STREAM_READ is not available in ES2.0
               glMapBufferOES does not allow reading from the mapped pointer.
2   10/23/2012 more cleanup, interaction with EXT_map_buffer_range
1   04/19/2012 initial revision
    - took ARB_pixel_buffer_object, stripped everything not applicable to 
      ES, changed references to tables and sections; changed all wording
      to fit ES' language.