xref: /third_party/openGLES/extensions/EXT/EXT_transform_feedback.txt

Name

    EXT_transform_feedback

Name Strings

    GL_EXT_transform_feedback

Contributors

    Nick Carter
    Charlie Lao
    Jeremy Sandmel
    Cliff Woolley
    Alex Eddy

Contact

    Barthold Lichtenbelt (blichtenbelt 'at' nvidia.com)
    Pat Brown (pbrown 'at' nvidia.com)
    Eric Werness (ewerness 'at' nvidia.com)

Status

    Shipping.

Version

    Last Modified Date:         08/09/2013
    NVIDIA Revision:            8

Number

    352

Dependencies

    The OpenGL Shading Language (GLSL) is required.  OpenGL 2.0 or the
    ARB_shader_objects extension is required.

    EXT_geometry_shader4 trivially interacts with this extension.

    NV_transform_feedback interacts with this extension.

    This extension is written against the OpenGL 2.0 specification.

Overview

    This extension provides a new mode to the GL, called transform feedback,
    which records selected vertex attributes for each primitive processed by
    the GL.  The selected attributes are written into buffer objects, and can
    be written with each attribute in a separate buffer object or with all
    attributes interleaved into a single buffer object.  If a geometry shader
    is active, the primitives recorded are those emitted by the geometry
    shader.  Otherwise, transform feedback captures primitives whose vertices
    are transformed by a vertex shader.  In either case, the primitives
    captured are those generated prior to clipping.  Transform feedback mode
    captures the values of specified varying variables emitted from GLSL
    vertex or geometry shaders.

    The vertex data recorded in transform feedback mode is stored into buffer
    objects as an array of vertex attributes.  The regular representation and
    the use of buffer objects allows the recorded data to be processed
    directly by the GL without requiring CPU intervention to copy data.  In
    particular, transform feedback data can be used for vertex arrays (via
    vertex buffer objects), as the source for pixel data (via pixel buffer
    objects), as shader constant data (via the NV_parameter_buffer_object or
    EXT_bindable_uniform extensions), or via any other extension that makes
    use of buffer objects.

    This extension introduces new query object support to allow transform
    feedback mode to operate asynchronously.  Query objects allow applications
    to determine when transform feedback results are complete, as well as the
    number of primitives processed and written back to buffer objects while in
    transform feedback mode.  This extension also provides a new rasterizer
    discard enable, which allows applications to use transform feedback to
    capture vertex attributes without rendering anything.

New Procedures and Functions

    void BindBufferRangeEXT(enum target, uint index, uint buffer,
                           intptr offset, sizeiptr size);
    void BindBufferOffsetEXT(enum target, uint index, uint buffer,
                            intptr offset);
    void BindBufferBaseEXT(enum target, uint index, uint buffer);

    void BeginTransformFeedbackEXT(enum primitiveMode);
    void EndTransformFeedbackEXT(void);

    void TransformFeedbackVaryingsEXT(uint program, sizei count,
                                      const char * const *varyings, 
                                      enum bufferMode);
    void GetTransformFeedbackVaryingEXT(uint program, uint index,
                                        sizei bufSize, sizei *length, 
                                        sizei *size, enum *type, char *name);

    void GetIntegerIndexedvEXT(enum param, uint index, int *values);
    void GetBooleanIndexedvEXT(enum param, uint index, boolean *values);

    (Note: These indexed query functions are provided in the EXT_draw_buffers2
    extension.  The boolean query is not useful for any queryable value in
    this extension, but is supported for completeness and consistency with
    base GL typed "Get" functions.)

New Tokens

    Accepted by the <target> parameters of BindBuffer, BufferData,
    BufferSubData, MapBuffer, UnmapBuffer, GetBufferSubData,
    GetBufferPointerv, BindBufferRangeEXT, BindBufferOffsetEXT and
    BindBufferBaseEXT:

      TRANSFORM_FEEDBACK_BUFFER_EXT                     0x8C8E

    Accepted by the <param> parameter of GetIntegerIndexedvEXT and
    GetBooleanIndexedvEXT:

      TRANSFORM_FEEDBACK_BUFFER_START_EXT               0x8C84
      TRANSFORM_FEEDBACK_BUFFER_SIZE_EXT                0x8C85

    Accepted by the <param> parameter of GetIntegerIndexedvEXT and
    GetBooleanIndexedvEXT, and by the <pname> parameter of GetBooleanv,
    GetDoublev, GetIntegerv, and GetFloatv:

      TRANSFORM_FEEDBACK_BUFFER_BINDING_EXT             0x8C8F

    Accepted by the <bufferMode> parameter of TransformFeedbackVaryingsEXT:

      INTERLEAVED_ATTRIBS_EXT                           0x8C8C
      SEPARATE_ATTRIBS_EXT                              0x8C8D

    Accepted by the <target> parameter of BeginQuery, EndQuery, and
    GetQueryiv:

      PRIMITIVES_GENERATED_EXT                          0x8C87
      TRANSFORM_FEEDBACK_PRIMITIVES_WRITTEN_EXT         0x8C88

    Accepted by the <cap> parameter of Enable, Disable, and IsEnabled, and by
    the <pname> parameter of GetBooleanv, GetIntegerv, GetFloatv, and
    GetDoublev:

      RASTERIZER_DISCARD_EXT                            0x8C89

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

      MAX_TRANSFORM_FEEDBACK_INTERLEAVED_COMPONENTS_EXT 0x8C8A
      MAX_TRANSFORM_FEEDBACK_SEPARATE_ATTRIBS_EXT       0x8C8B
      MAX_TRANSFORM_FEEDBACK_SEPARATE_COMPONENTS_EXT    0x8C80

   Accepted by the <pname> parameter of GetProgramiv:

      TRANSFORM_FEEDBACK_VARYINGS_EXT                   0x8C83
      TRANSFORM_FEEDBACK_BUFFER_MODE_EXT                0x8C7F
      TRANSFORM_FEEDBACK_VARYING_MAX_LENGTH_EXT         0x8C76


Additions to Chapter 2 of the OpenGL 2.0 Specification (OpenGL
Operation)

    Insert three new sections between Sections 2.11, Coordinate Transforms and
    2.12, Clipping:

    (Move the "Asynchronous Queries" language out of Section 4.1.7.  This
    section doesn't really introduce any new functionality, other than
    alluding to the transform feedback queries introduced below.)

    Section 2.X, Asynchronous Queries

    Asynchronous queries provide a mechanism to return information about the
    processing of a sequence of GL commands.  There are two query types
    supported by the GL.  Transform feedback queries (section 2.Y) returns
    information on the number of vertices and primitives processed by the GL
    and written to one or more buffer objects.  Occlusion queries (section
    4.1.7.1) count the number of fragments or samples that pass the depth
    test.

    The results of asynchronous queries are not returned by the GL immediately
    after the completion of the last command in the set; subsequent commands
    can be processed while the query results are not complete.  When
    available, the query results are stored in an associated query object.
    The commands described in section 6.1.12 provide mechanisms to determine
    when query results are available and return the actual results of the
    query.  The name space for query objects is the unsigned integers, with
    zero reserved by the GL.

    Each type of query supported by the GL has an active query object name. If
    the active query object name for a query type is non-zero, the GL is
    currently tracking the information corresponding to that query type and
    the query results will be written into the corresponding query object.  If
    the active query object for a query type name is zero, no such information
    is being tracked.

    A query object is created by calling

      void BeginQuery(enum target, uint id);

    with an unused name <id>.  <target> indicates the type of query to be
    performed; valid values of <target> are defined in subsequent
    sections. When a query object is created, the name <id> is marked as used
    and associated with a new query object.

    BeginQuery sets the active query object name for the query type given by
    <target> to <id>.  If BeginQuery is called with an <id> of zero, if the
    active query object name for <target> is non-zero, or if <id> is the
    active query object name for any query type, the error INVALID OPERATION
    is generated.

    The command

      void EndQuery(enum target);

    marks the end of the sequence of commands to be tracked for the query type
    given by <target>.  The active query object for <target> is updated to
    indicate that query results are not available, and the active query object
    name for <target> is reset to zero.  When the commands issued prior to
    EndQuery have completed and a final query result is available, the query
    object, active when EndQuery is, called is updated by the GL.  The query
    object is updated to indicate that the query results are available and to
    contain the query result.  If the active query object name for <target> is
    zero when EndQuery is called, the error INVALID_OPERATION is generated.

   The command

      void GenQueries(sizei n, uint *ids);

    returns <n> previously unused query object names in <ids>. These names are
    marked as used, but no object is associated with them until the first time
    they are used by BeginQuery.

    Query objects are deleted by calling

      void DeleteQueries(sizei n, const uint *ids);

    <ids> contains <n> names of query objects to be deleted. After a query
    object is deleted, its name is again unused.  Unused names in <ids> are
    silently ignored.

    Calling either GenQueries or DeleteQueries while any query of any target
    is active causes an INVALID_OPERATION error to be generated.

    Query objects contain two pieces of state:  a single bit indicating
    whether a query result is available, and an integer containing the query
    result value.  The number of bits used to represent the query result is
    implementation-dependent.  In the initial state of a query object, the
    result is available and its value is zero.

    The necessary state for each query type is an unsigned integer holding the
    active query object name (zero if no query object is active), and any
    state necessary to keep the current results of an asynchronous query in
    progress.

    Section 2.Y, Transform Feedback

    In transform feedback mode, attributes of the vertices of transformed
    primitives processed by a vertex or geometry shader are written out to one
    or more buffer objects.  The vertices are fed back after vertex color
    clamping, but before clipping.  If a geometry shader is active, the
    vertices recorded are those emitted from the geometry shader.  The
    transformed vertices may be optionally discarded after being stored into
    one or more buffer objects, or they can be passed on down to the clipping
    stage for further processing.  The set of attributes captured is
    determined when a program is linked.

    Transform feedback is started and finished by calling

      void BeginTransformFeedbackEXT(enum primitiveMode)

    and

      void EndTransformFeedbackEXT(void),

    respectively. Transform feedback is said to be active after a call to
    BeginTransformFeedbackEXT and inactive after a call to
    EndTransformFeedbackEXT.  <primitiveMode> is one of TRIANGLES, LINES, or
    POINTS, and specifies the output type of primitives that will be recorded
    into the buffer objects bound for transform feedback (see
    below). <primitiveMode> places a restriction on the primitive types that
    may be rendered while transform feedback is active -- see table X.1.

      Transform Feedback
      primitiveMode               allowed render primitive modes
      ----------------------      ---------------------------------
      POINTS                      POINTS
      LINES                       LINES, LINE_LOOP, and LINE_STRIP
      TRIANGLES                   TRIANGLES, TRIANGLE_STRIP,
                                  TRIANGLE_FAN, QUADS, QUAD_STRIP,
                                  and POLYGON

    Table X.1 Legal combinations between the transform feedback primitive
    mode, as passed to BeginTransformFeedbackEXT and the current primitive
    mode.

    Transform feedback commands must be paired; the error INVALID_OPERATION is
    generated by BeginTransformFeedbackEXT if transform feedback is active,
    and by EndTransformFeedbackEXT if transform feedback is inactive.

    Transform feedback mode captures the values of varying variables written
    by an active vertex or geometry shader.  The error INVALID_OPERATION is
    generated by BeginTransformFeedbackEXT if no vertex or geometry shader is
    not active.

    When transform feedback is active, all geometric primitives generated must
    be compatible with the value of <primitiveMode> passed to
    BeginTransformFeedbackEXT.  The error INVALID_OPERATION is generated by
    Begin or any operation that implicitly calls Begin (such as DrawElements)
    if <mode> is not one of the allowed modes in Table X.1.  If a geometry
    shader is active, its output primtive type is used instead of the <mode>
    parameter passed to Begin for the purposes of this error check.

    Buffer objects are made to be targets of transform feedback by calling one
    of the commands

      void BindBufferRangeEXT(enum target, uint index, uint buffer,
                              intptr offset, sizeiptr size)
      void BindBufferOffsetEXT(enum target, uint index, uint buffer,
                               intptr offset)
      void BindBufferBaseEXT(enum target, uint index, uint buffer)

    with <target> set to TRANSFORM_FEEDBACK_BUFFER_EXT.  There is an array of
    buffer object binding points that are used while transform feedback is
    active, plus a single general binding point that can be used by other
    buffer object manipulation functions (e.g., BindBuffer, MapBuffer).  All
    three commands bind the buffer object named by <buffer> to the general
    binding point, and additionally bind the buffer object to the binding
    point in the array given by <index>.  The error INVALID_VALUE is generated
    if <index> is greater than or equal to the value of
    MAX_TRANSFORM_FEEDBACK_SEPARATE_ATTRIBS_EXT.

    For BindBufferRangeEXT, <offset> specifies a starting offset into the
    buffer object <buffer> and <size> specifies the amount of data that can be
    written to the buffer object while transform feedback mode is active.
    Both <offset> and <size> are in basic machine units.  The error
    INVALID_VALUE is generated if the value of <size> is less than or equal to
    zero, or if either <offset> or <size> are not word-aligned.  Calling
    BindBufferOffsetEXT is equivalent of calling BindBufferRangeEXT with
    <size> = sizeof(buffer) - <offset>, and rounding <size> down so that it is
    word-aligned. BindBufferBaseEXT is equivalent to calling
    BindBufferOffsetEXT with an <offset> of 0.

    When an individual point, line, or triangle primitive reaches the
    transform feedback stage while transform feedback is active, the values of
    the specified varying variables of the vertex are appended to the buffer
    objects bound to the transform feedback binding points.  The attributes of
    the first vertex received after BeginTransformFeedbackEXT are written at
    the starting offsets of the bound buffer objects set by
    BindBufferRangeEXT, and subsequent vertex attributes are appended to the
    buffer object.  When capturing line and triangle primitives, all
    attributes of the first vertex are written first, followed by attributes
    of the subsequent vertices.  When writing varying variables that are
    arrays, individual array elements are written in order.  For
    multi-component varying variables or varying array elements, the
    individual components are written in order.  The value for any attribute
    specified to be streamed to a buffer object but not actually written by a
    vertex or geometry shader is undefined.

    When quads and polygons are provided to transform feedback with a
    primitive mode of TRIANGLES, they will be tessellated and recorded as
    triangles (the order of tessellation within a primitive is undefined).
    Individual lines or triangles of a strip or fan primitive will be
    extracted and recorded separately. Incomplete primitives are not recorded.

    Transform feedback can operate in either INTERLEAVED_ATTRIBS_EXT or
    SEPARATE_ATTRIBS_EXT mode.  In INTERLEAVED_ATTRIBS_EXT mode, the values of
    one or more varyings are written, interleaved, into the buffer object
    bound to the first transform feedback binding point (index = 0).  If more
    than one varying variable is written, they will be recorded in the order
    specified by TransformFeedbackVaryingsEXT (section 2.15.3).  In
    SEPARATE_ATTRIBS_EXT mode, the first varying variable specified by
    TransformFeedbackVaryingsEXT is written to the first transform feedback
    binding point; subsequent varying variables are written to the subsequent
    transform feedback binding points.  The total number of variables that may
    be captured in separate mode is given by
    MAX_TRANSFORM_FEEDBACK_SEPARATE_ATTRIBS_EXT.

    If recording the vertices of a primitive to the buffer objects being used
    for transform feedback purposes would result in either exceeding the
    limits of any buffer object's size, or in exceeding the end position
    <offset> + <size> - 1, as set by BindBufferRangeEXT, then no vertices of
    that primitive are recorded in any buffer object, and the counter
    corresponding to the asynchronous query target
    TRANSFORM_FEEDBACK_PRIMITIVES_WRITTEN_EXT (see Section 2.Z) is not
    incremented.

    In either separate or interleaved modes, all transform feedback binding
    points that will be written to must have buffer objects bound when
    BeginTransformFeedbackEXT is called.  The error INVALID_OPERATION is
    generated by BeginTransformFeedbackEXT if any binding point used in
    transform feedback mode does not have a buffer object bound.  In
    interleaved mode, only the first buffer object binding point is ever
    written to.  The error INVALID_OPERATION is also generated by
    BeginTransformFeedbackEXT if no binding points would be used, either
    because no program object is active or because the active program object
    has specified no varying variables to record.

    While transform feedback is active, the set of attached buffer objects and
    the set of varying variables captured may not be changed.  If transform
    feedback is active, the error INVALID_OPERATION is generated by
    UseProgram, by LinkProgram if <program> is the currently active program
    object, and by BindBufferRangeEXT, BindBufferOffsetEXT, or
    BindBufferBaseEXT if <target> is TRANSFORM_FEEDBACK_BUFFER_EXT.


    Section 2.Z, Primitive Queries
 
    Primitive queries use query objects to track the number of primitives
    generated by the GL and to track the number of primitives written to
    transform feedback buffers.

    When BeginQuery is called with a <target> of PRIMITIVES_GENERATED_EXT, the
    primitives-generated count maintained by the GL is set to zero. When the
    generated primitive query is active, the primitives-generated count is
    incremented every time a primitive reaches the Discarding Rasterization
    stage (see Section 3.x) right before rasterization. This counter counts
    the number of primitives emitted by a geometry shader, if active, possibly
    further tessellated into separate primitives during the transform-feedback
    stage, if active.

    When BeginQuery is called with a <target> of
    TRANSFORM_FEEDBACK_PRIMITIVES_WRITTEN_EXT, the transform-feedback-
    primitives-written count maintained by the GL is set to zero. When the
    transform feedback primitive written query is active, the
    transform-feedback-primitives-written count is incremented every time a
    primitive is recorded into a buffer object. If transform feedback is not
    active, this counter is not incremented. If the primitive does not fit in
    the buffer object, the counter is not incremented.

    These two queries can be used together to determine if all primitives have
    been written to the bound feedback buffers; if both queries are run
    simultaneously and the query results are equal, all primitives have been
    written to the buffer(s). If the number of primitives written is less than
    the number of primitives generated, the buffer is full.


    Modify Section 2.15.3 "Shader Variables", p. 75.

    Change the second sentence in the first paragraph on p. 84 as follows:

    . . . written by a vertex shader, read by a fragment shader, or used for
    transform feedback will count against this limit.  The transformed vertex
    position (gl_Position) does not count against this limit. ...

    Add the following language to the end of section 2.15.3 (p.84):

    Each program object can specify one or more varying variables to be
    recorded in transform feedback mode.  This set is specified by the command

      void TransformFeedbackVaryingsEXT(uint program, sizei count,
                                        const char * const *varyings, 
                                        enum bufferMode)

    <program> specifies the program object.  <count> specifies the number of
    varying variables used for transform feedback.  <varyings> is an array of
    <count> zero-terminated strings specifying the names of the varying
    variables to use for transform feedback.  The varying variables specified
    in <varyings> can be either built-in varying variables (beginning with
    "gl_") or user-defined ones. varying variables are written out in the
    order they appear in the array <varyings>. <bufferMode> is either
    INTERLEAVED_ATTRIBS_EXT or SEPARATE_ATTRIBS_EXT, and identifies the mode
    used to capture the varying variables when transform feedback is active.
    The error INVALID_VALUE is generated if <program> is not the name of a
    program object, or if <bufferMode> is SEPARATE_ATTRIBS_EXT and <count> is
    greater than the implement-dependent limit
    MAX_TRANSFORM_FEEDBACK_SEPARATE_ATTRIBS_EXT.

    The state set by TransformFeedbackVaryingsEXT has no effect on the
    execution of the program until <program> is subsequently linked.  When
    LinkProgram is called, the program is linked so that the values of the
    specified varying variables for the vertices of each primitive generated
    by the GL are written to a single buffer object (if the buffer mode is
    INTERLEAVED_ATTRIBS_EXT) or multiple buffer objects (if the buffer mode is
    SEPARATE_ATTRIBS_EXT).  A program will fail to link if:

      * the <count> specified by TransformFeedbackVaryingsEXT is non-zero, but
        the program object has no vertex or geometry shader;

      * any variable name specified in the <varyings> array is not declared as
        an output in the geometry shader (if present) or the vertex shader (if
        no geometry shader is present);

      * any two entries in the <varyings> array specify the same varying
        variable;

      * the total number of components to capture in any varying variable in
        <varyings> is greater than the constant
        MAX_TRANSFORM_FEEDBACK_SEPARATE_COMPONENTS_EXT and the buffer mode is
        SEPARATE_ATTRIBS_EXT; or

      * the total number of components to capture is greater than the constant
        MAX_TRANSFORM_FEEDBACK_INTERLEAVED_COMPONENTS_EXT and the buffer mode
        is INTERLEAVED_ATTRIBS_EXT.

    To determine the set of varying variables in a linked program object that
    will be captured in transform feedback mode, use the command:

      void GetTransformFeedbackVaryingEXT(uint program, uint index,
                                          sizei bufSize, sizei *length, 
                                          sizei *size, enum *type, 
                                          char *name);

    This command provides information about the varying variable selected by
    <index>.  An <index> of 0 selects the first varying variable specified in
    the <varyings> array of TransformFeedbackVaryingsEXT, and an <index> of
    TRANSFORM_FEEDBACK_VARYINGS_EXT-1 selects the last such varying variable.
    The value of TRANSFORM_FEEDBACK_VARYINGS_EXT can be queried with
    GetProgramiv (see section 6.1.14).  If <index> is greater than or equal to
    TRANSFORM_FEEDBACK_VARYINGS_EXT, the error INVALID_VALUE is generated.
    The parameter <program> is the name of a program object for which the
    command LinkProgram has been issued in the past.  If a new set of varying
    variables is specified by TransformFeedbackVaryingsEXT after a program
    object has been linked, the information returned by
    GetTransformFeedbackVaryingEXT will not reflect those variables until the
    program is re-linked.

    The name of the selected varying is returned as a null-terminated string
    in <name>. The actual number of characters written into <name>, excluding
    the null terminator, is returned in <length>. If <length> is NULL, no
    length is returned. The maximum number of characters that may be written
    into <name>, including the null terminator, is specified by <bufSize>. The
    returned varying name can be the name of a user defined varying variable
    or the name of a built- in varying (which begin with the prefix "gl_", see
    the OpenGL Shading Language specification for a complete list). The length
    of the longest varying name in program is given by
    TRANSFORM_FEEDBACK_VARYING_MAX_LENGTH_EXT, which can be queried with
    GetProgramiv (see section 6.1.14).

    For the selected varying variable, its type is returned into <type>.  The
    size of the varying is returned into <size>. The value in <size> is in
    units of the type returned in <type>. The type returned can be any of
    FLOAT, FLOAT_VEC2, FLOAT_VEC3, FLOAT_VEC4, INT, INT_VEC2, INT_VEC3,
    INT_VEC4, UNSIGNED_INT, UNSIGNED_INT_VEC2_EXT, UNSIGNED_INT_VEC3_EXT,
    UNSIGNED_INT_VEC4_EXT, FLOAT_MAT2, FLOAT_MAT3, or FLOAT_MAT4.  If an error
    occurred, the return parameters <length>, <size>, <type> and <name> will
    be unmodified.  This command will return as much information about the
    varying variables as possible.  If no information is available, <length>
    will be set to zero and <name> will be an empty string. This situation
    could arise if GetTransformFeedbackVaryingEXT is called after a failed
    link.


Additions to Chapter 3 of the OpenGL 2.0 Specification (Rasterization)

   (Add new section 3.X, Discarding Rasterization)

    Primitives can be optionally discarded before rasterization by calling
    Enable and Disable with RASTERIZER_DISCARD_EXT. When enabled, primitives
    are discared right before the rasterization stage, but after the optional
    transform feedback stage. When disabled, primitives are passed through to
    the rasterization stage to be processed normally. RASTERIZER_DISCARD_EXT
    applies to the DrawPixels, CopyPixels, Bitmap, Clear and Accum commands as
    well.


Additions to Chapter 4 of the OpenGL 2.0 Specification (Per-Fragment
Operations and the Frame Buffer)

    (Replace section 4.1.7, "Occlusion Queries", p. 204, with the following)

    Occlusion queries use query objects to track the number of fragments or
    samples that pass the depth test.  An occlusion query can be started and
    finished by calling BeginQuery and EndQuery, respectively, with a <target>
    of SAMPLES_PASSED.

    When an occlusion query starts, the samples-passed count maintained by the
    GL is set to zero.  When an occlusion query is active, the samples-passed
    count is incremented for each fragment that passes the depth test.  If the
    value of SAMPLE BUFFERS is 0, then the samples- passed count is
    incremented by 1 for each fragment. If the value of SAMPLE BUFFERS is 1,
    then the samples-passed count is incremented by the number of samples
    whose coverage bit is set. However, implementations, at their discretion,
    may instead increase the samples-passed count by the value of SAMPLES if
    any sample in the fragment is covered.  When an occlusion query finishes
    and all fragments generated by the commands issued prior to EndQuery have
    been generated, the samples-passed count is written to the corresponding
    query object as the query result value, and the query result for that
    object is marked as available.

    If the samples-passed count overflows, (i.e., exceeds the value 2^n - 1,
    where n is the number of bits in the samples-passed count), its value
    becomes undefined.  It is recommended, but not required, that
    implementations handle this overflow case by saturating at 2^n - 1 and
    incrementing no further.


Additions to Chapter 5 of the OpenGL 2.0 Specification (Special Functions)

    (Add to section 5.4, Display Lists p. 237)

    On p. 241, add the following to the list of vertex buffer object commands
    not compiled into a display list: BindBufferRangeEXT, BindBufferOffsetEXT,
    BindBufferBaseEXT, and TransformFeedbackVaryingsEXT.


Additions to Chapter 6 of the OpenGL 2.0 Specification (State and State
Requests)

    Modify the second paragraph of section 6.1.1 (Simple Queries) p244 to read
    as follows:

    ...<data> is a pointer to a scalar or array of the indicated type in which
    to place the returned data. The commands

      void GetIntegerIndexedvEXT(enum param, uint index, int *values);
      void GetBooleanIndexedvEXT(enum param, uint index, boolean *values);

    are used to query indexed state.  <target> is the name of the indexed
    state and <index> is the index of the particular element being queried.
    <data> is a pointer to a scalar or array of the indicated type in which to
    place the returned data. In addition ...

   (Replace Section 6.1.12, Occlusion Queries, p. 254)

    Section 6.1.12, Asynchronous Queries

    The command

      boolean IsQuery(uint id);

    returns TRUE if <id> is the name of a query object. If <id> is zero, or if
    <id> is a non-zero value that is not the name of a query object, IsQuery
    returns FALSE.

    Information about a query target can be queried with the command

      void GetQueryiv(enum target, enum pname, int *params);

    <target> identifies the query target and can be SAMPLES_PASSED for
    occlusion queries or PRIMITIVES_GENERATED_EXT and
    TRANSFORM_FEEDBACK_PRIMITIVES_WRITTEN_EXT for primitive queries.

    If <pname> is CURRENT_QUERY, the name of the currently active query for
    <target>, or zero if no query is active, will be placed in <params>.

    If <pname> is QUERY_COUNTER_BITS, the implementation-dependent number of
    bits used to hold the query result for <target> will be placed in
    params. The number of query counter bits may be zero, in which case the
    counter contains no useful information.

    For primitive queries (PRIMITIVES_GENERATED_EXT and
    TRANSFORM_FEEDBACK_PRIMITIVES_WRITTEN_EXT) if the number of bits is
    non-zero, the minimum number of bits allowed is 32.

    For occlusion queries (SAMPLES_PASSED), if the number of bits is non-
    zero, the minimum number of bits allowed is a function of the
    implementation's maximum viewport dimensions (MAX_VIEWPORT_DIMS).  The
    counter must be able to represent at least two overdraws for every pixel
    in the viewport. The formula to compute the allowable minimum value (where
    n is the minimum number of bits) is:

      n = min(32, ceil(log_2(maxViewportWidth *
                             maxViewportHeight * 2))).

    The state of a query object can be queried with the commands

      void GetQueryObjectiv(uint id, enum pname, int *params);
      void GetQueryObjectuiv(uint id, enum pname, uint *params);

    If <id> is not the name of a query object, or if the query object named by
    <id> is currently active, then an INVALID_OPERATION error is generated.

    If <pname> is QUERY_RESULT, then the query object's result value is
    returned as a single integer in <params>.  If the value is so large in
    magnitude that it cannot be represented with the requested type, then the
    nearest value representable using the requested type is returned.  If the
    number of query counter bits for any <target> is zero, then the result is
    returned as a single integer with a value of 0.

    There may be an indeterminate delay before the above query returns.  If
    <pname> is QUERY_RESULT_AVAILABLE, FALSE is returned if such a delay would
    be required, TRUE is returned otherwise. It must always be true that if
    any query object returns a result available of TRUE, all queries of the
    same type issued prior to that query must also return TRUE.

    Querying the state for any given query object forces the corresponding
    query to complete within a finite amount of time.

    If multiple queries are issued using the same object name prior to calling
    GetQueryObject[u]iv, the result and availability information returned will
    always be from the last query issued.  The results from any queries before
    the last one will be lost if they are not retrieved before starting a new
    query on the same <target> and <id>.


    (Add to Section 6.1.13, Buffer Objects, p. 255)

    Add the following paragraph to the bottom of this section, p. 256.

    To query which buffer objects are bound to the array of transform feedback
    binding points and will be used when transform feedback is active, call
    GetIntegerIndexedvEXT() with <param> set to
    TRANSFORM_FEEDBACK_BUFFER_BINDING_EXT.  <index> has to be in the range 0
    to MAX_TRANSFORM_FEEDBACK_SEPARATE_ATTRIBS_EXT - 1, otherwise the error
    INVALID_VALUE is generated. The name of the buffer object bound to <index>
    is returned in <values>. If no buffer object is bound for <index>, zero is
    returned in <values>.

    To query the starting offset or size of the range of each buffer object
    binding used for transform feedback, call GetIntegerIndexedvEXT() with
    <param> set to TRANSFORM_FEEDBACK_BUFFER_START_EXT or
    TRANSFORM_FEEDBACK_BUFFER_SIZE_EXT respectively.  The error INVALID_VALUE
    is generated if <index> not in the range 0 to
    MAX_TRANSFORM_FEEDBACK_SEPARATE_ATTRIBS_EXT - 1.  If the parameter
    (starting offset or size) was not specified when the buffer object was
    bound, or if no buffer object is bound to <index>, zero is returned.

    (add to Section 6.1.14, Shader and Program Queries, p. 256)

    Add the following paragraph to the bottom of page 257:

    If <pname> is TRANSFORM_FEEDBACK_BUFFER_MODE_EXT, the buffer mode, used
    when transform feedback is active, is returned. It can be one of
    SEPARATE_ATTRIBS_EXT or INTERLEAVED_ATTRIBS_EXT.  If <pname> is
    TRANSFORM_FEEDBACK_VARINGS_EXT, the number of varying variables to capture
    in transform feedback mode for the program is returned.  If <pname> is
    TRANSFORM_FEEDBACK_VARYING_MAX_LENGTH, the length of the longest varying
    name specified to be used for transform feedback, including a null
    terminator, is returned. If no varyings are used for transform feedback,
    zero is returned.

Additions to Appendix A of the OpenGL 2.0 Specification (Invariance)

    None.

Additions to the AGL/GLX/WGL Specifications

    None.

GLX Protocol

    UNDER DEVELOPMENT

Interactions with NV_transform_feedback

    NV_transform_feedback is the initial version of this extension, which
    includes three capabilities not provided here:

      * support for transform feedback with assembly vertex/geometry programs
        and fixed-function vertex processing;

      * the ability to change the set of GLSL varying variables to capture in
        transform feedback mode without re-linking; and 

      * the "active varying" API that enumerates all varying variables in a
        program object that are considered active.

    This extension provides one capability not provided by
    NV_transform_feedback -- the ability and requirement to specify the set of
    varying variables used for transform feedback prior to linking.

    If both extensions are supported, the following happens:

      * When a program is linked, the active varying state defined in the NV
        extension is updated.  For the purposes of this API, any variables
        enabled for transform feedback via TransformFeedbackVaryingsEXT() are
        considered active.

      * When a program is linked, the transform feedback configuration is
        built from the state provided by TransformFeedbackVaryingsEXT() as in
        the current extension.  In terms of the NV extension, it is as though
        the linker had queried the locations of each varying specified in
        TransformFeedbackVaryingsEXT() and then called the
        TransformFeedbackVaryingsNV() to update the transform feedback
        configuration post-link.  If no varying variables were specified by
        TransformFeedbackVaryingsEXT(), the transform feedback configuration
        is reset to an empty default state after linking, just as is always
        the case when using the NV extension alone.

      * Calling TransformFeedbackVaryingsNV() after linking allows an
        application to update the transform feedback state post-link.  Any
        transform feedback state set when a program is linked is replaced with
        the state specified by TransformFeedbackVaryingsNV().

      * Calling TransformFeedbackVaryingsEXT() after linking continues to have
        no effect.

      * The EXT and NV versions of all functions defined in both extension,
        other than TransformFeedbackVaryings*(), operate identically.

      * BeginTransformFeedbackEXT() does not require the use of a GLSL program
        object if both extensions are supported.  If no GLSL program object is
        active, transform feedback is still enabled and captures the
        attributes specified by TransformFeedbackAttribsNV().


Interactions with EXT_timer_query

    EXT_timer_query is the first extension to generalize the BeginQuery and
    EndQuery mechanism introduced by ARB_occlusion_query and OpenGL 1.5 to
    cover an additional query type.  This extension is the second.  This
    extension is written against the OpenGL 2.0 specification and uses most of
    the modifications in the EXT_timer_query specification.  If
    EXT_timer_query is supported, timer queries need to be added as a third
    query type.


Dependencies on EXT_geometry_shader4

    If EXT_geometry_shader4 is not supported, delete all references to
    geometry shaders.


Errors

    The error INVALID_OPERATION is generated by BeginQuery if called with an
    <id> of zero, if the active query object name for <target> is non- zero,
    or if <id> is the active query object name for any query type.

    The error INVALID_OPERATION is generated by EndQuery if the active query
    object name for <target> is zero.

    The error INVALID_OPERATION is generated if Begin, or any command that
    performs an explicit Begin, is called when:

      * a geometry shader is not active and <mode> does not match the allowed
        begin modes for the current transform feedback state as given by table
        X.1.

      * a geometry shader is active and the output primitive type of the
        geometry shader does not match the allowed begin modes for the current
        transform feedback state as given by table X.1.

    The error INVALID_OPERATION is generated by BeginTransformFeedbackEXT if
    any transform feedback buffer object binding point used in transform
    feedback mode does not have a buffer object bound.

    The error INVALID_OPERATION is also generated by BeginTransformFeedbackEXT
    if no binding points would be used, either because no program object is
    active or because the active program object has specified no varying
    variables to record.

    If transform feedback is active, the error INVALID_OPERATION is generated
    by BeginTransformFeedbackEXT; UseProgram; LinkProgram if called on the
    currently in use program object; and BindBufferRangeEXT,
    BindBufferOffsetEXT, or BindBufferBaseEXT if <target> is
    TRANSFORM_FEEDBACK_BUFFER_EXT.

    If transform feedback is inactive, the error INVALID_OPERATION is
    generated by EndTransformFeedbackEXT.

    The error INVALID_VALUE is generated by BindBufferRangeEXT,
    BindBufferOffsetEXT, or BindBufferBaseEXT if <index> is greater or equal
    than MAX_TRANSFORM_FEEDBACK_SEPARATE_ATTRIBS_EXT.

    The error INVALID_VALUE is generated by BindBufferRangeEXT if the value of
    <size> is less than or equal to zero, or not word-aligned.

    The error INVALID_VALUE is generated by BindBufferRangeEXT or
    BindBufferOffsetEXT if <offset> is not word-aligned.

    The error INVALID_VALUE is generated by TransformFeedbackVaryingsEXT
    commands if <program> is not the name of a program object, or if
    <bufferMode> is SEPARATE_ATTRIBS_EXT and <count> is greater than
    MAX_TRANSFORM_FEEDBACK_SEPARATE_ATTRIBS_EXT.

    The error INVALID_VALUE is generated by GetTransformFeedbackVaryingEXT if
    <index> is greater than or equal to the value of
    TRANSFORM_FEEDBACK_VARYINGS_EXT.

    The error INVALID_VALUE is generated by GetIntegerIndexedvEXT() or
    GetBooleanIndexedvEXT() with <param> set to
    TRANSFORM_FEEDBACK_BUFFER_BINDING_EXT if <index> is greater than or equal
    to MAX_TRANSFORM_FEEDBACK_SEPARATE_ATTRIBS_EXT.


New State

    (Add a new table:  Table 6.X,  Transform Feedback State)

    Get Value             Type    Get Command     Init. Value  Description                Sec    Attrib
    ------------------    ------  --------------  ------------ -------------------------  -----  ------
    TRANSFORM_FEEDBACK_   Z+      GetIntegerv          0        Buffer object bound to    6.1.13   -
      BUFFER_BINDING_EXT                                        generic bind point for
                                                                transform feedback.
    TRANSFORM_FEEDBACK_   nxZ+    GetInteger-          0        Buffer object bound to    6.1.13   -
      BUFFER_BINDING_EXT          IndexedvEXT                   each transform feedback
                                                                attribute stream.
    TRANSFORM_FEEDBACK_   nxZ+    GetInteger-          0        Start offset of binding   6.1.13   -
      BUFFER_START_EXT            IndexedvEXT                   range for each transform
                                                                feedback attrib. stream
    TRANSFORM_FEEDBACK_   nxZ+    GetInteger-          0        Size of binding range     6.1.13   -
      BUFFER_SIZE_EXT             IndexedvEXT                   for each transform
                                                                feedback attrib. stream

   (Modify Table 6.37, p 298, updating the query object state to cover
   transform feedback.)

    Get Value         Type  Get Command       Init. Value  Description                Sec    Attribute
    ----------------  ----  ----------------  -----------  -------------------------  -----  ---------
    CURRENT_QUERY     3xZ+  GetQueryiv        0            Active query object name   2.X        -
                                                           (occlusion, timer, xform
                                                            feedback)

   (Modify Table 6.29, p. 290, Program Object State. Add the following state.)

    Get Value           Type  Get Command   Init. Value  Description                 Sec    Attribute
    ----------------    ----  ------------  -----------  -------------------------   -----  ---------
   TRANSFORM_FEEDBACK_  Z2    GetProgramiv  INTERLEAVED_ Transform feedback mode     6.1.14     -
     BUFFER_MODE_EXT                        ATTRIBS_EXT   for the program
   TRANSFORM_FEEDBACK_  Z+    GetProgramiv       0       Number of varyings to       6.1.14     -
     VARYINGS_EXT                                        stream to buffer object(s)
   TRANSFORM_FEEDBACK_  Z+    GetProgramiv       0       Maximum transform feedback  6.1.14     -
     VARYING_MAX_                                        varying name length
     LENGTH_EXT
        -               Z+    GetTransform-      -       Size of each transform      2.15.3     -
                               Feedback-                 feedback varying variable
                               VaryingEXT
        -               Z+    GetTransform-       -      Type of each transform      2.15.3     -
                               Feedback-                 feedback varying variable
                               VaryingEXT
        -               0+x-  GetTransform-       -      Name of each transform      2.15.3     -
                        char   Feedback-                 feedback varying variable
                               VaryingEXT

   (Add new Table, Query Object State.  Note:  There is nothing transform 
    feedback-specific here; this table should be in the core specification.)

    Get Value           Type  Get Command   Init. Value  Description                 Sec     Attribute
    ----------------    ----  ------------  -----------  -------------------------   ------  ---------
    QUERY_RESULT        Z+    GetQuery-          0       Query object result         6.1.12     -
                               Objectiv                   (query type-dependent)
    QUERY_RESULT_       Z+    GetQuery-        TRUE      Is the query object         6.1.12     -
      AVAILABLE                Objectiv                    result available?


New Implementation Dependent State

   (Modify Table 6.34, p. 295.  Update the query object state to cover
   transform feedback.)

    Get Value               Type Get Command  Minimum Value  Description                  Sec     Attribute
    --------------------    ---- -----------  -------------  --------------------------   ------  ---------
    QUERY_COUNTER_BITS      2xZ+ GetQueryiv   see 6.1.12     Asynchronous query counter   6.1.12    -
                                                             bits (occlusion, timer, 
                                                             tranform feedback queries)

   (Add a new table, Table 6.X. Transform Feedback State.)

   NOTE:  In the "GetValue" columns below, MXFB stands for
   "MAX_TRANSFORM_FEEDBACK".

    Get Value               Type Get Command  Minimum Value  Description                  Sec     Attribute
    --------------------    ---- -----------  -------------  --------------------------   ------  ---------
    MXFB_INTERLEAVED_       Z+   GetIntegerv  64             Max number of components to  2.Y       -
    COMPONENTS_EXT                                           write to a single buffer in
                                                             interleaved mode
    MXFB_SEPARATE_          Z+   GetIntegerv  4              Max number of separate       2.Y       -
    ATTRIBS_EXT                                              attributes or vayings that
                                                             can be captured in transform
                                                             feedback
    MXFB_SEPARATE_          Z+   GetIntegerv  4              Max number of components     2.Y       -
    COMPONENTS_EXT                                           per attribute or varying 
                                                             in separate mode

Issues

    1. How does transform feedback differ from core GL feedback?

      * Transform feedback writes vertex data to buffer objects, which allows
        the data returned to be used directly by vertex pulling.  GL feedback
        mode writes vertex data to a buffer in system memory.

      * Transform feedback is done after transformation, but prior to
        clipping.  The primitives returned contain the original transformed
        vertices produced by vertex or geometry program execution, and does
        not contain any primitives inserted by clipping.

      * Transform feedback supports only a single basic output primitive type
        (points, lines, or triangles), while core GL feedback mode supports
        all primitive types.  Since only one primitive type is supported, the
        data returned does not contain tokens describing each primitive being
        fed back.  Primitive tokens make the data returned by GL feedback mode
        irregular and unsuitable for vertex pulling.

    2. What should this extension be called, and how does it differ from
       previous extensions?

      RESOLVED:  The current name is "EXT_transform_feedback", playing off the
      fact that it is transformed primitives that are handled and the
      similarities to GL feedback mode.  

      This extension is new version of the shipping NV_transform_feedback
      extension with some capabilities removed to ease multi-vendor adoption.
      See the "Interactions with NV_transform_feedback" section for more
      information on the functional differences.

    3. What happens if you bind a buffer for transform feedback that is
       currently bound for other purposes?  Should we somehow detect this case
       and produce an error?

      !!! NBC I feel strongly that we should follow the precedent for
      Map/Unmap. The reason that MapBuffer and UnmapBuffer are a precedent
      here is because while a buffer object is in the mapped state, no GL
      commands are allowed to operate on the buffer object's data.  So by
      analogy, while a buffer is being used for transform feedback, no other
      GL commands should be allowed to operate on the buffer object's data.
      This includes initiating any rendering which would cause the GL to
      source data from an active transform feedback buffer object.

      UNRESOLVED

    4. Should this extension include any new buffer object binding targets, or
       should it overload ARRAY_BUFFER, or should we skip the binding target
       altogether in favor of a buffer object name accepted directly by the
       new GL commands?

      RESOLVED: There are new binding points for XFB along with a new API
      (BindBufferBase etc) to set the internal binding points. A new binding
      point, TRANSFORM_FEEDBACK_BUFFER_EXT is also introduced.

    5. Previous buffer object extensions provided a way to have existing GL
       commands reference a buffer object instead of a user-supplied buffer.
       Should the new commands introduced here allow referencing a
       user-supplied buffer in addition to a buffer object?

      RESOLVED: No. A program can get the contents of the feedback buffer back
      to the CPU using MapBuffer and GetBufferSubData.

    6. Is BeginTransformFeedback really necessary? Could the query just
       initiate the transform feedback mode?

      RESOLUTION: Using BeginTransformFeedback and EndTransformFeedback gives
      a clean place to spec all of the transform-feedback-specific issues
      without cluttering up the query language. Also, the queries don't have
      to be done at the same time as beginning and ending the feedback
      process.

    7. What usage enums should be provided to glBufferData for use in
       conjunction with transform feedback?

      RESOLVED: STREAM_COPY or STREAM_READ are expected to be the most common
      usages. If a buffer object is being written by the GL through transform
      feedback, and the contents of the buffer object are subsequently being
      consumed by the GL (e.g. by being used as a vertex buffer object), then
      this is a *_COPY usage. If the buffer object is being written by the GL
      through transform feedback, but is being consumed by the application
      (e.g. being mapped for read), this is a *_READ usage.  The temporal
      (STREAM, STATIC, or DYNAMIC) component of the usage enum is determined
      by the ratio between how often the contents of the buffer object are
      modified and how often operations that source data from the buffer
      object occur.

    8. What should the behavior be when a buffer object is the active target
       of transform feedback, and it is deleted via DeleteBuffers?

      RESOLVED: Deletion is deferred until the EndTransformFeedback if
      transform feedback is active.

    9. Should we allow more buffers to be bound than are used?

      RESOLVED: Yes. The extra buffers are not in the way and can stay bound.

    10. Should we allow feedback to buffer lists with holes (i.e. 0 and 2
        bound)?

      RESOLVED: No. This makes for an ugly API with the potential for bugs,
      without any real benefit. The application can as well bind all buffers
      needed to incremented indices. It is an invalid operation to not have a
      buffer bound where one is required.

    11. Why only one feedback primitive mode per feedback invocation?

      RESOLVED: Having primitive tokens breaks up the stream and makes it less
      amenable to being read back in as a vertex buffer. Also, mixing multiple
      primitive types makes the counting of primitives less clear for the
      application.

    12. Is RasterPos fed back?

      RESOLVED: No.

    13. Is DrawPixels/CopyPixels/Bitmap fed back?

      RESOLVED: No. Rasterization occurs as normal, but there is no
      output to the feedback buffer. This is consistent with taking a
      tap out of the pipe before clipping.

    14. Why do we need new BindBuffer* functions?

      RESOLVED: All previous buffer object extensions have been retrofits of
      existing pointer-based APIs. New extensions built assuming buffer
      objects don't have that history, so need a new API. The functionality of
      these new functions combines the functionality of BindBuffer, to set the
      external bind point used by calls like MapBuffer and BufferSubData, with
      the functionality to set an internal bind point like VertexAttribPointer
      does.

    15. How do the transform feedback indices, passed to the BindBuffer*
        commands, work with multiple bindings?

      RESOLVED:  The same way that they work with vertex arrays.  There is one
      external bind point, TRANSFORM_FEEDBACK_BUFFER_EXT.  There are n
      internal bind points, selected with the <index> parameter to the
      BindBuffer* commands, where n is some implementation dependent limit.
      The BindBuffer* commands take the buffer passed and bind it to the
      external bind point, as well as to the selected internal bind point.

      For example:

        BindBufferOffsetEXT(TRANSFORM_FEEDBACK_BUFFER_EXT, 0, 1, 12); 
        // XFB index 0 points at buffer 1 with offset 12

        BindBuffer(TRANSFORM_FEEDBACK_BUFFER_EXT, 2); 
        // Buffer 2 is now bound to the external bind point. XFB index 0 still
        // points at buffer 1

        MapBuffer(TRANSFORM_FEEDBACK_BUFFER_EXT, ...); 
        // Maps buffer 2

    16. How are quads/quadstrips/polygons tesselated into triangles?

      RESOLVED: In an implementation-dependent manner. OpenGL doesn't define
      quads or polygons in terms of triangles, so there is no one correct way
      to do it, and different gpus may implement the behavior differently. A
      quad may be split into two triangles in several different ways, and an
      application may not rely on this behavior.

    17. How does this extension interact with display lists?

      RESOLVED: Just like the VBO extension, none of the BindBuffer* commands
      are compiled into a display list.

    18. Does polygon mode state affect the logic that determines if the
        transform feed back primitive mode and the render mode states are
        valid at the start of transform feedback mode?

      RESOLVED: PolygonMode has no influence on the BeginTransFormFeedback
      primitiveMode check since it is performed later in the pipeline.

    19. What to do with incomplete primitives?

      RESOLVED: If there is no room to store one or more vertices of a
      primitive in a buffer object, none of the vertices in that primitive are
      written to the buffer. If a partial primitive enters transform feedback
      (i.e. only two vertices sent in triangles mode), none of the vertices in
      that primitive are written to the buffer object.

    20. Why does TRANSFORM_FEEDBACK_PRIMITIVES_WRITTEN_EXT have a
        TRANSFORM_FEEDBACK prefix but PRIMITIVES_GENERATED_EXT doesn't?

      RESOLVED: The number of primitives generated is independent of any
      feedback that is active. The number of primitives that are written is
      only valid for transform feedback - another extension could conceivably
      have a different way of writing out primitives that would require a
      similar but distinct token.

    25. Are primitives sent down the pipeline after transform feedback, or
        discarded?

      RESOLVED: Primitives can be optionally discarded before rasterization by
      calling Enable and Disable with RASTERIZER_DISCARD_EXT. When enabled,
      primitives are discarded after vertex attributes are recorded into the
      buffer objects bound to transform feedback.  When disabled, primitives
      are passed through to the rasterization stage to be clipped and
      rasterized normally. All rasterization operations are discarded, not
      just those that are fed back into the buffer.

      This applies to DrawPixels, CopyPixels, Bitmap, Clear, Accum as well.

    26. If a varying is declared as an array, is the whole array streamed out?

      RESOLVED: No, the application has to specify which elements of an array
      it wants to stream out. Implementations might not be able to stream out
      a large number of components to a single buffer object.  If that is the
      case, the application can stream each element of an array to a different
      buffer object in TRANSFORM_FEEDBACK_SEPARATE_ATTRIBS mode.

    27. Is it possible to capture attributes when using the fixed-function
        pipeline?

      RESOLVED:  Not in this extension, which requires the use of a GLSL
      vertex or geometry shader.  The NV_transform_feedback extension does
      provide this capability.

    28. Should we provide queries to determine the set of varying variables to
        be captured for a program object in transform feedback mode -- i.e.,
        the values in the array of strings <varyings> given to
        TransformFeedbackVaryingsEXT?

      RESOLVED:  Yes; the command GetTransformFeedbackVaryingEXT is provided
      to query the name, size, and type of each varying captured for a linked
      program object in transform feedback mode.  

      Transform feedback-related queries operate only on a linked program
      object.  There is no API available to query transform feedback varying
      state set by TransformFeedbackVaryingsEXT until a program is linked.

    29. What happens if a variable is specified in the array of names passed
        to TransformFeedbackVaryingsEXT, but not needed by the fragment
        shader?  The linker may normally eliminate such variables.

      RESOLVED:  Varying variables specified by TransformFeedbackVaryingsEXT
      are always considered active and count against the total limit on the
      number of active varying components, regardless of the needs of the
      fragment shader.  If such a program object is executed with transform
      feedback active, the values of these variables are computed by the
      vertex or geometry shader and stored in the appropriate buffer object.
      If transform feedback is inactive, the values of such varyings may be
      calculated even though they are only needed for transform feedback.


Revision History

      Rev.    Date    Author    Changes
      ----  --------  --------  ---------------------------------------------
       8    08/09/13  pbrown    Remove extra <varyings> parameter in
                                TransformFeedbackVaryingsEXT.

       7    07/01/13  Jon Leech Change type of TransformFeedbackVaryingsEXT
                                parameter from 'const char **varyings' to
                                'const char * const *varyings' (Bug 10231). 

       6    01/27/11  Jon Leech Change return value for start/size queries
                                when no buffer bound from -1 to zero, to
                                match state tables (Bug 7318).

       5    02/28/08  pbrown    Merged in edits from Apple.  Update status to
                                shipping.  Moved per-object query results into
                                a separate table.

       4    02/20/08  pbrown    Fix incorrect minimum for MAX_TRANSFORM_
                                FEEDBACK_SEPARATE_COMPONENTS_EXT.  Should be
                                4, not 16.

       3    12/13/07  pbrown    Clean up a number of places where "NV" 
                                suffixes were incorrectly carried over from
                                the NV_transform_feedback spec.

       2    08/28/07  pbrown    Document that BeginTransformFeedbackEXT
                                results in an error if no program object is
                                active or if the active program isn't
                                capturing any varyings.

       1    11/30/06  pbrown    Created an initial EXT_transform_feedback 
                                spec by forking off the existing
                                NV_transform_feedback spec.