Name NV_transform_feedback Name Strings GL_NV_transform_feedback Contributors Cliff Woolley Nick Carter Contact Barthold Lichtenbelt (blichtenbelt 'at' nvidia.com) Pat Brown (pbrown 'at' nvidia.com) Eric Werness (ewerness 'at' nvidia.com) Status Shipping for GeForce 8 Series (November 2006) Version Last Modified Date: 03/09/2011 NVIDIA Revision: 18 Number 341 Dependencies OpenGL 1.5 is required. This extension interacts with EXT_timer_query. NV_vertex_program4, NV_geometry_program4 and NV_gpu_program4 affect this extension. EXT_geometry_shader4 trivially interacts with this extension. This extension has an OpenGL Shading Language component. As such it interacts with ARB_shader_objects and OpenGL 2.0. 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 vertex attributes of the primitives 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 program or shader is active, the primitives recorded are those emitted by the geometry program. Otherwise, transform feedback captures primitives whose vertex are transformed by a vertex program or shader, or by fixed-function vertex processing. In either case, the primitives captured are those generated prior to clipping. Transform feedback mode is capable of capturing transformed vertex data generated by fixed-function vertex processing, outputs from assembly vertex or geometry programs, or 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 program constant data (via the NV_parameter_buffer_object or EXT_bindable_uniform extension), 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 BindBufferRangeNV(enum target, uint index, uint buffer, intptr offset, sizeiptr size) void BindBufferOffsetNV(enum target, uint index, uint buffer, intptr offset) void BindBufferBaseNV(enum target, uint index, uint buffer) void TransformFeedbackAttribsNV(sizei count, const int *attribs, enum bufferMode) void TransformFeedbackVaryingsNV(uint program, sizei count, const int *locations, enum bufferMode) void BeginTransformFeedbackNV(enum primitiveMode) void EndTransformFeedbackNV() int GetVaryingLocationNV(uint program, const char *name) void GetActiveVaryingNV(uint program, uint index, sizei bufSize, sizei *length, sizei *size, enum *type, char *name) void ActiveVaryingNV(uint program, const char *name) void GetTransformFeedbackVaryingNV(uint program, uint index, int *location) 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 parameters of BindBuffer, BufferData, BufferSubData, MapBuffer, UnmapBuffer, GetBufferSubData, GetBufferPointerv, BindBufferRangeNV, BindBufferOffsetNV and BindBufferBaseNV: TRANSFORM_FEEDBACK_BUFFER_NV 0x8C8E Accepted by the parameter of GetIntegerIndexedvEXT and GetBooleanIndexedvEXT: TRANSFORM_FEEDBACK_BUFFER_START_NV 0x8C84 TRANSFORM_FEEDBACK_BUFFER_SIZE_NV 0x8C85 TRANSFORM_FEEDBACK_RECORD_NV 0x8C86 Accepted by the parameter of GetIntegerIndexedvEXT and GetBooleanIndexedvEXT, and by the parameter of GetBooleanv, GetDoublev, GetIntegerv, and GetFloatv: TRANSFORM_FEEDBACK_BUFFER_BINDING_NV 0x8C8F Accepted by the parameter of TransformFeedbackAttribsNV and TransformFeedbackVaryingsNV: INTERLEAVED_ATTRIBS_NV 0x8C8C SEPARATE_ATTRIBS_NV 0x8C8D Accepted by the parameter of BeginQuery, EndQuery, and GetQueryiv: PRIMITIVES_GENERATED_NV 0x8C87 TRANSFORM_FEEDBACK_PRIMITIVES_WRITTEN_NV 0x8C88 Accepted by the parameter of Enable, Disable, and IsEnabled, and by the parameter of GetBooleanv, GetIntegerv, GetFloatv, and GetDoublev: RASTERIZER_DISCARD_NV 0x8C89 Accepted by the parameter of GetBooleanv, GetDoublev, GetIntegerv, and GetFloatv: MAX_TRANSFORM_FEEDBACK_INTERLEAVED_COMPONENTS_NV 0x8C8A MAX_TRANSFORM_FEEDBACK_SEPARATE_ATTRIBS_NV 0x8C8B MAX_TRANSFORM_FEEDBACK_SEPARATE_COMPONENTS_NV 0x8C80 TRANSFORM_FEEDBACK_ATTRIBS_NV 0x8C7E Accepted by the parameter of GetProgramiv: ACTIVE_VARYINGS_NV 0x8C81 ACTIVE_VARYING_MAX_LENGTH_NV 0x8C82 TRANSFORM_FEEDBACK_VARYINGS_NV 0x8C83 Accepted by the parameter of GetBooleanv, GetDoublev, GetIntegerv, GetFloatv, and GetProgramiv: TRANSFORM_FEEDBACK_BUFFER_MODE_NV 0x8C7F Accepted by the parameter of TransformFeedbackAttribsNV: BACK_PRIMARY_COLOR_NV 0x8C77 BACK_SECONDARY_COLOR_NV 0x8C78 TEXTURE_COORD_NV 0x8C79 CLIP_DISTANCE_NV 0x8C7A VERTEX_ID_NV 0x8C7B PRIMITIVE_ID_NV 0x8C7C GENERIC_ATTRIB_NV 0x8C7D POINT_SIZE 0x0B11 FOG_COORDINATE 0x8451 SECONDARY_COLOR_NV 0x852D PRIMARY_COLOR 0x8577 POSITION 0x1203 LAYER_NV 0x8DAA (note: POINT_SIZE, FOG_COORDINATE, PRIMARY_COLOR, and POSITION are defined in the core OpenGL specification; SECONDARY_COLOR_NV is defined in NV_register_combiners.) Returned by the parameter of GetActiveVaryingNV: UNSIGNED_INT_VEC2_EXT 0x8DC6 UNSIGNED_INT_VEC3_EXT 0x8DC7 UNSIGNED_INT_VEC4_EXT 0x8DC8 (note: All three of these are defined in the EXT_gpu_shader4 extension.) 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) 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 . indicates the type of query to be performed; valid values of are defined in subsequent sections. When a query object is created, the name is marked as used and associated with a new query object. BeginQuery sets the active query object name for the query type given by to . If BeginQuery is called with an of zero, if the active query object name for is non-zero, or if 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 . The active query object for is updated to indicate that query results are not available, and the active query object name for 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 is zero when EndQuery is called, the error INVALID_OPERATION is generated. The command void GenQueries(sizei n, uint *ids); returns previously unused query object names in . 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); contains names of query objects to be deleted. After a query object is deleted, its name is again unused. Unused names in 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 the vertices of transformed primitives are written out to one or more buffer objects. The vertices are fed back after the geometry shader stage, if it exists, or otherwise after vertex processing right before clipping (section 2.12) but after color clamping. Optionally the transformed vertices can be discarded after being stored into one or more buffer objects, or they can be passed on down to the clipping stage for further processing. Transform feedback is started and finished by calling void BeginTransformFeedbackNV(enum primitiveMode) and void EndTransformFeedbackNV(), respectively. Transform feedback is said to be active after a call to BeginTransformFeedbackNV and inactive after a call to EndTransformFeedbackNV. Transform feedback is initially inactive. Transform feedback is performed after color clamping, but immediately before clipping in the OpenGL pipeline. 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). places a restriction on the primitive types that may be rendered during an instance of transform feedback. 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 BeginTransformFeedbackNV and the current primitive mode. If a geometry program or geometry shader is active, the output primitive type of the currently active program is used as the render primitive in table X.1, otherwise the Begin mode is used. Quads and polygons will be tessellated and recorded as triangles (the order of tessellation within a primitive is undefined); primitives specified in strips or fans will be assembled and recorded as individual primitives. Incomplete primitives are not recorded. Begin or any operation that implicitly calls Begin (such as DrawElements) will generate INVALID_OPERATION if the begin mode is not an allowed begin mode for the current transform feedback buffer state. If a geometry program or geometry shader is active, its output primitive mode is used for the error check instead of the begin mode. It is an invalid operation error to call BeginTransformFeedbackNV, TransformFeedbackVaryingsNV, TransformFeedbackAttribsNV, or UseProgram or LinkProgram on the currently active program object while transform feedback is active. It is an invalid operation error to call EndTransformFeedbackNV while transform feedback is inactive. Transform feedback can operate in either INTERLEAVED_ATTRIBS_NV or SEPARATE_ATTRIBS_NV mode. In the INTERLEAVED_ATTRIBS_NV mode, several vertex attributes can be written, interleaved, into a single buffer object. In the SEPARATE_ATTRIBS_NV mode, vertex attributes are recorded, non-interleaved, into several buffer objects simultaneously. It is an INVALID_OPERATION error to call BeginTransformFeedbackNV if there is no buffer object bound to index 0 (see the description of the BindBuffer* commands below) in INTERLEAVED_ATTRIBS_NV mode. It is also an INVALID_OPERATION error to call BeginTransformFeedbackNV if the number of buffer objects bound in SEPARATE_ATTRIBS_NV mode is less than the number of buffer objects required, as given by the current transform feedback state. It is also an INVALID_OPERATION error to call BeginTransformFeedbackNV if no attributes are specified to be captured in either separate or interleaved mode. Buffer objects are made to be targets of transform feedback by calling one of void BindBufferRangeNV(enum target, uint index, uint buffer, intptr offset, sizeiptr size) void BindBufferOffsetNV(enum target, uint index, uint buffer, intptr offset) void BindBufferBaseNV(enum target, uint index, uint buffer) where is set to TRANSFORM_FEEDBACK_BUFFER_NV. Any of the three BindBuffer* commands perform the equivalent of BindBuffer(target, buffer). specifies which buffer object to bind to the target at index number . exists for use with the SEPARATE_ATTRIBS_NV mode and must be less than the value of MAX_TRANSFORM_FEEDBACK_SEPARATE_ATTRIBS_NV. specifies a starting offset into the buffer object . specifies the number of elements that can be written during transform feedback mode. This is useful to prevent the GL from writing past a certain position in the buffer object. Both and are in basic machine units. The error INVALID_VALUE is generated if the value of is less than or equal to zero. The error INVALID_VALUE is generated if or are not word-aligned. The error INVALID_OPERATION is generated when any of the BindBuffer* commands is called while transform feedback is active. BindBufferBaseNV is equivalent to calling BindBufferOffsetNV with an of 0. BindBufferOffsetNV is the equivalent of calling BindBufferRangeNV with = sizeof(buffer) - and rounding down so that it is word-aligned. 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 + - 1, as set by BindBufferRangeNV, then no vertices of the primitive are recorded, and the counter corresponding to the asynchronous query target TRANSFORM_FEEDBACK_PRIMITIVES_WRITTEN_NV (see Section 2.Z) is not incremented. Two methods exist to specify which transformed vertex attributes are streamed to one, or more, buffer objects in transform feedback mode. If an OpenGL Shading Language vertex and/or geometry shader is active, then the state set with the TransformFeedbackVaryingsNV() command determines which attributes to record. If neither a vertex nor geometry shader is active, the state set with the TransformFeedbackAttribsNV() command determines which attributes to record. When a program object containing a vertex shader and/or geometry shader is active, the set of vertex attributes recorded in transform feedback mode is specified by void TransformFeedbackVaryingsNV(uint program, sizei count, const int *locations, enum bufferMode) This command sets the transform feedback state for and specifies which varying variables to record when transform feedback is active. The array contains locations of active varying variables, as queried with GetActiveVaryingNV(), to stream to a buffer object. See section 2.15.3. is one of INTERLEAVED_ATTRIBS_NV or SEPARATE_ATTRIBS_NV. The error INVALID_OPERATION is generated if any value in does not reference an active varying variable, or if any value in appears more than once in the array. The same error is generated if has not been linked successfully. The program object's state value TRANSFORM_FEEDBACK_BUFFER_MODE_NV will be set to and the program object's state value TRANSFORM_FEEDBACK_VARYINGS_NV set to . These values can be queried with GetProgramiv (see section 6.1.14). In the INTERLEAVED_ATTRIBS_NV mode, varying variables are written, interleaved, into one buffer object. This is the buffer object bound to index 0. Varying variables are written out to that buffer object in the order that they appear in the array . The error INVALID_OPERATION is generated if the total number of components of all varying variables specified in the array is greater than MAX_TRANSFORM_FEEDBACK_INTERLEAVED_COMPONENTS_NV. In the SEPARATE_ATTRIBS_NV mode, varying variables are recorded, non-interleaved, into several buffer objects simultaneously. The first varying variable in the array is written to the buffer bound to index 0. The last varying variable is written to the buffer object bound to index - 1. No more than MAX_TRANSFORM_FEEDBACK_SEPARATE_ATTRIBS_NV buffer objects can be written to simultaneously. The error INVALID_VALUE is generated if is greater than that limit. Furthermore, the number of components for each varying variable in the array cannot exceed MAX_TRANSFORM_FEEDBACK_SEPARATE_COMPONENTS_NV. The error INVALID_VALUE is generated if any varying variable in exceeds this limit. It is not necessary to (re-)link after calling TransformFeedbackVaryingsNV(). Changes to the transform feedback state will be picked up right away after calling TransformFeedbackVaryingsNV(). 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 neither a vertex nor geometry shader is active, the vertex attributes produced by fixed-function vertex processing or an assembly vertex or geometry program can be recorded in transform feedback mode. The set of attributes to record is specified by void TransformFeedbackAttribsNV(sizei count, const int *attribs, enum bufferMode) This command specifies which attributes to record into one, or more, buffer objects. The value TRANSFORM_FEEDBACK_BUFFER_MODE_NV will be set to and the value TRANSFORM_FEEDBACK_ATTRIBS_NV set to . The array contains an interleaved representation of the attributes desired to be fed back containing 3*count values. For attrib i, the value at 3*i+0 is the enum corresponding to the attrib, as given in table X.2. The value at 3*i+1 is the number of components of the provided attrib to be fed back and is between 1 and 4. The value at 3*i+2 is the index for attribute enumerants corresponding to more than one real attribute. For an attribute enumerant corresponding to only one attribute, the index is ignored. For an attribute enumerant corresponding to more than one attribute, the error INVALID_VALUE is generated if the index value is outside the allowable range for that attribute. permitted GPU_program_4 attrib sizes index? result name --------------------- -------- -------- -------------- POSITION 1,2,3,4 no position PRIMARY_COLOR 1,2,3,4 no color.front.primary SECONDARY_COLOR_NV 1,2,3,4 no color.front.secondary BACK_PRIMARY_COLOR_NV 1,2,3,4 no color.back.primary BACK_SECONDARY_COLOR_NV 1,2,3,4 no color.back.secondary FOG_COORDINATE 1 no fogcoord POINT_SIZE 1 no pointsize TEXTURE_COORD_NV 1,2,3,4 yes texcoord[index] CLIP_DISTANCE_NV 1 yes clip[index] VERTEX_ID_NV 1 no vertexid PRIMITIVE_ID_NV 1 no primid GENERIC_ATTRIB_NV 1,2,3,4 yes attrib[index] LAYER_NV 1 no layer Table X.2: Transform Feedback Attribute Specifiers.The 'attrib' column specifies which attribute to record. The 'permitted sizes' column indicates how many components of the attribute can be recorded. The 'index' column indicates if the attribute is indexed. The 'gpu program 4' column shows which result variable of a vertex or geometry program corresponds to the attribute to record. The TransformFeedbackAttribsNV() command sets transform feedback state which is used both when the GL is in fixed-function vertex processing mode, as well as when an assembly vertex and/or geometry program is active. The parameter has the same meaning as described for TransformFeedbackVaryingsNV(). Attributes are either written interleaved, or into separate buffer objects, in the same manner as described earlier for TransformFeedbackVaryingsNV(). In the INTERLEAVED_ATTRIBS_NV mode, the error INVALID_VALUE is generated if the sum of the values of elements 3*i+1 in the array is greater than MAX_TRANSFORM_FEEDBACK_INTERLEAVED_COMPONENTS_NV. In the SEPARATE_ATTRIBS_NV mode, no more than MAX_TRANSFORM_FEEDBACK_SEPARATE_ATTRIBS_NV buffer objects can be written to simultaneously. The error INVALID_VALUE is generated if is greater than that limit. The error INVALID_OPERATION is generated if any attribute appears more than once in the array . The value for any attribute specified to be streamed to a buffer object but not actually written by a vertex or geometry program is undefined. The values of PRIMITIVE_ID_NV or LAYER_NV for a vertex is defined if and only if a geometry program is active and that program writes to the result variables "result.primid" or "result.layer", respectively. The value of VERTEX_ID_NV is only defined if and only if a vertex program is active, no geometry program is active, and the vertex program writes to the output attribute "result.id". 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 of PRIMITIVES_GENERATED_NV, 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 of TRANSFORM_FEEDBACK_PRIMITIVES_WRITTEN_NV, 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", page 75. Change the second sentence in the first paragraph on p. 84 as follows: . . . or read by a fragment shader, will count against this limit. The transformed vertex position (gl_Position) does not count against this limit. Add the following paragraphs on p.84: A varying variable is considered active if it is determined by the linker that the varying will actually be used when the executable code in a program object is executed. The linker will make this determination regardless of the transform-feedback state set with the TransformFeedbackVaryingsNV() command. In cases where the linker cannot make a conclusive determination, the varying will be considered active. It is possible to override this determination and force the linker to consider a varying variable as active by calling ActiveVaryingNV(). This can be useful in transform feedback mode if there are varying variables to be recorded but not otherwise needed. To find the location of an active varying variable, call int GetVaryingLocationNV(uint program, const char *name) This command will return the location of varying variable . is a null-terminated string without whitespace. If is not the name of an active varying variable in , -1 is returned. Locations for both user-defined as well as built-in varying variables can be queried. If has not been successfully linked, the error INVALID_OPERATION is generated. After a program is linked, the location will not change, unless the program is re- linked. A valid name cannot be any portion of a single vector or matrix, but can be a single element of an array or the whole array. Note that varying variables cannot be structures. To determine the set of active varying variables used by a program object, and their data types, use the command: void GetActiveVaryingNV(uint program, uint index, sizei bufSize, sizei *length, sizei *size, enum *type, char *name); This command provides information about the varying selected by . An of 0 selects the first active varying variable, and an of ACTIVE_VARYINGS_NV-1 selects the last active varying variable. The value of ACTIVE_VARYINGS_NV can be queried with GetProgramiv (see section 6.1.14). If is greater than or equal to ACTIVE_VARYINGS_NV, the error INVALID_VALUE is generated. The parameter is the name of a program object for which the command LinkProgram has been issued in the past. It is not necessary for to have been linked successfully. The link could have failed because the number of active varying variables exceeded the limit. The name of the selected varying is returned as a null-terminated string in . The actual number of characters written into , excluding the null terminator, is returned in . If is NULL, no length is returned. The maximum number of characters that may be written into , including the null terminator, is specified by . 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 ACTIVE_VARYING_MAX_LENGTH_NV, which can be queried with GetProgramiv (see section 6.1.14). For the selected varying variable, its type is returned into . The size of the varying is returned into . The value in is in units of the type returned in . 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 , , and will be unmodified. This command will return as much information about active varying variables as possible. If no information is available, will be set to zero and will be an empty string. This situation could arise if GetActiveVaryingNV is issued after a failed link. To force the linker to mark a varying variable as active, call void ActiveVaryingNV(uint program, const char *name) to specify that the varying variable in should be marked as active when the program is next linked. In particular, it does not modify the list of active varying variables in a program object that has already been linked. For any varying variable in not passed to ActiveVaryingNV, the linker will determine their active status. must be a null-terminated string without whitespace. A valid name cannot be an element of an array, or any portion of a single vector or matrix. ActiveVaryingNV may be issued before any shader objects are attached to . Hence, can contain any string, including a name that is never used as a varying variable in any shader object. Such names are ignored by the GL. The application is advised to force any varying variable live that it needs for transform feedback purposes. The set of active varying variables are linker dependent. 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_NV. When enabled, primitives are discarded 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_NV 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 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: BindBufferRangeNV, BindBufferOffsetNV, BindBufferBaseNV, TransformFeedbackAttribsNV, TransformFeedbackVaryingsNV, and ActiveVaryingNV. 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: ... 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. is the name of the indexed state and is the index of the particular element being queried. 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 is the name of a query object. If is zero, or if 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); identifies the query target and can be SAMPLES_PASSED for occlusion queries or PRIMITIVES_GENERATED_NV and TRANSFORM_FEEDBACK_PRIMITIVES_WRITTEN_NV for primitive queries. If is CURRENT_QUERY, the name of the currently active query for , or zero if no query is active, will be placed in . If is QUERY_COUNTER_BITS, the implementation-dependent number of bits used to hold the query result for 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_NV and TRANSFORM_FEEDBACK_PRIMITIVES_WRITTEN_NV) 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 is not the name of a query object, or if the query object named by is currently active, then an INVALID_OPERATION error is generated. If is QUERY_RESULT, then the query object's result value is returned as a single integer in . 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 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 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 and . (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 the target(s) when transform feedback is active, call GetIntegerIndexedvEXT() with set to TRANSFORM_FEEDBACK_BUFFER_BINDING_NV. has to be in the range 0 to MAX_TRANSFORM_FEEDBACK_SEPARATE_ATTRIBS_NV - 1, otherwise the error INVALID_VALUE is generated. The name of the buffer object bound to is returned in . If no buffer object is bound for , zero is returned in . To query the starting offset or size of the range of each buffer object binding used for transform feedback, call GetIntegerIndexedvEXT() with set to TRANSFORM_FEEDBACK_BUFFER_START_NV or TRANSFORM_FEEDBACK_BUFFER_SIZE_NV respectively. The error INVALID_VALUE is generated if not in the range 0 to MAX_TRANSFORM_FEEDBACK_SEPARATE_ATTRIBS_NV - 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 , zero is returned. (Add a new Section 6.1.14 "Transform Feedback " and rename 6.1.14 to 6.1.15) To query the attributes to stream to a buffer object when neither an OpenGL Shading Language vertex nor geometry shader is active, call GetIntegerIndexedvEXT() with set to TRANSFORM_FEEDBACK_RECORD_NV. This will return three values in for each . The first value returned is the attribute. The second value the number of components of the attribute, and the third value the index of the attribute, if applicable. If the attribute is not indexed, the third component will return 0. The parameter has to be in the range 0 to TRANSFORM_FEEDBACK_ATTRIBS_NV - 1, otherwise the error INVALID_VALUE is generated. If no data exists for 0 is returned three times in . To query the attributes to stream to a buffer object when a vertex and/or geometry shader is active, use the command GetTransformFeedbackVaryingNV(), as explained in section 6.1.14. (add to Section 6.1.14, Shader and Program Queries, p. 256) Add the following paragraph to the bottom of page 257: If is TRANSFORM_FEEDBACK_BUFFER_MODE_NV, the buffer mode, used when transform feedback is active, is returned. It can be one of SEPARATE_ATTRIBS_NV or INTERLEAVED_ATTRIBS_NV. If is TRANSFORM_FEEDBACK_VARINGS_NV, the number of varying variables to stream to one, or more, buffer objects are returned. If is ACTIVE_VARYINGS_NV, the number of active varying variables is returned. If no active varyings exist, 0 is returned. If is ACTIVE_VARYINGS_MAX_LENGTH_NV, the length of the longest active varying name, including a null terminator, is returned. If no active varying variable exists, 0 is returned. The command void GetTransformFeedbackVaryingNV(uint program, uint index, int *location) returns, for each , the location of a varying variable to stream to a buffer object in . The element of the array , as passed to TransformFeedbackVaryingsNV, is returned. has to be in the program object specific range 0 to TRANSFORM_FEEDBACK_VARYINGS_NV - 1, otherwise the error INVALID_VALUE is generated. If no location exists for , -1 is returned. If is not the name of a program object, or if program object has not been linked successfully, the error INVALID_OPERATION is generated. 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 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 NV_geometry_program4 and EXT_geometry_shader4 If NV_geometry_program4 is not supported, delete the reference to the output primitive type in Section 2.Y. Delete the reference to PRIMITIVE_ID_NV and LAYER_NV. If EXT_geometry_shader4 is not supported, delete any reference to a geometry shader. Dependencies on NV_vertex_program4 and NV_gpu_program4 If NV_vertex_program4 is not supported, delete any reference to VERTEX_ID_NV. If NV_gpu_program4 is not supported, table X.2 needs to refer to the "result" variables defined in the ARB_vertex_program specification instead. Interactions with ARB_shader_objects and OpenGL 2.0 If neither ARB_shader_objects nor OpenGL 2.0 is supported, all references to shader and program objects, as well as varying variables, should be removed. This also means that functions including TransformFeedbackVaryingsNV, GetVaryingLocationNV, GetActiveVaryingNV, ActiveVaryingNV, and GetTransformFeedbackVaryingNV will not be supported, and enums that are relevant only in the context of shader and program objects will not be accepted. Errors The error INVALID_OPERATION is generated by BeginQuery if called with an of zero, if the active query object name for is non- zero, or if 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 is zero. The error INVALID_OPERATION is generated if Begin, or any command that performs an explicit Begin, is called when: * A geometry program or shader is not active AND the begin mode does not match the allowed begin modes for the current transform feedback state as given by table X.1. * A geometry program or shader is active AND the output primitive type (of the geometry program / 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 BeginTransformFeedbackNV if there is no buffer object bound to index 0 in INTERLEAVED_ATTRIBS_NV mode. The error INVALID_OPERATION is generated by BeginTransformFeedbackNV if the number of buffer objects bound in SEPARATE_ATTRIBS_NV mode is less than the number of buffer objects required, as given by the current transform feedback state. The error INVALID_OPERATION is generated by BeginTransformFeedbackNV if no attributes are specified to be captured. The error INVALID_OPERATION is generated by BeginTransformFeedbackNV, TransformFeedbackVaryingsNV, TransformFeedbackAttribsNV, or UseProgram or LinkProgram, called on the currently in use program object, while transform feedback is active. The error INVALID_OPERATION is generated by EndTransformFeedbackNV while transform feedback is inactive. The error INVALID_OPERATION is generated by BindBufferRangeNV, BindBufferOffsetNV or BindBufferBaseNV if is TRANSFORM_FEEDBACK_BUFFER_NV and is greater or equal than MAX_TRANSFORM_FEEDBACK_SEPARATE_ATTRIBS_NV. The error INVALID_VALUE is generated by BindBufferRangeNV if the value of <= 0. The error INVALID_VALUE is generated by BindBufferRangeNV or BindBufferOffsetNV if or are not word-aligned. The error INVALID_OPERATION is generated when any of the BindBuffer* commands is called while transform feedback is active. The error INVALID_OPERATION is generated by TransformFeedbackVaryingsNV commands if any location appears more than once in the array references a non-existing varying variable. The error INVALID_OPERATION is generated by TransformFeedbackVaryingsNV if has not been linked successfully. The error INVALID_OPERATION is generated by TransformFeedbackVaryingsNV in INTERLEAVED_ATTRIBS_NV mode if the total number of components of all varying variables specified in the array is greater than MAX_TRANSFORM_FEEDBACK_INTERLEAVED_COMPONENTS_NV. The error INVALID_VALUE is generated by TransformFeedbackVaryingsNV or TransformFeedbackAttribsNV in SEPARATE_ATTRIBS_NV mode if is greater than MAX_TRANSFORM_FEEDBACK_SEPARATE_ATTRIBS_NV. The error INVALID_VALUE is generated by TransformFeedbackVaryingsNV in SEPARATE_ATTRIBS_NV mode if the number of components for each varying variable in the array is greater than MAX_TRANSFORM_FEEDBACK_SEPARATE_COMPONENTS_NV. The error INVALID_VALUE is generated by TransformFeedbackAttribsNV in INTERLEAVED_ATTRIBS_NV mode if the sum of the values of the components of the attributes in the array is greater than MAX_TRANSFORM_FEEDBACK_INTERLEAVED_COMPONENTS_NV. The error INVALID_OPERATION is generated by TransformFeedbackAttribsNV if an enum value is specified more than once in the array . The error INVALID_OPERATION is generated by TransformFeedbackAttribsNV if the number of components for each attribute in the array is outside the range [0,4]. The error INVALID_VALUE is generated by TransformFeedbackAttribsNV if the index value is in the array is outside the allowable range for an attribute enumerant corresponding to more than one real attribute. The error INVALID_OPERATION is generated by GetVaryingLocationNV if is not the name of a program object or if has not been linked successfully. The error INVALID_OPERATION is generated by GetActiveVaryingNV or ActiveVaryingNV if is not the name of a program object. The error INVALID_VALUE is generated by GetActiveVaryingNV if is greater than or equal to ACTIVE_VARYINGS_NV. The error INVALID_VALUE is generated by GetIntegerIndexedvEXT() or GetBooleanIndexedv() with set to TRANSFORM_FEEDBACK_RECORD_NV if is greater than or equal to TRANSFORM_FEEDBACK_ATTRIBS_NV. The error INVALID_VALUE is generated by GetIntegerIndexedvEXT() or GetBooleanIndexedvEXT() with set to TRANSFORM_FEEDBACK_BUFFER_BINDING_NV if is greater than or equal to MAX_TRANSFORM_FEEDBACK_SEPARATE_ATTRIBS_NV. The error INVALID_VALUE is generated by GetTransformFeedbackVaryingsNV if is greater than the program object specific value TRANSFORM_FEEDBACK_VARYINGS_NV - 1. The error INVALID_OPERATION is generated by GetTransformFeedbackVaryingsNV if is not the name of a program object, or if program object has not been linked successfully. New State (Add a new table: Table 6.X, Transform Feedback State) Get Value Type Get Command Init. Value Description Sec Attrib ------------------ ------ -------------- ------------ ------------------------- ----- ------ TRANSFORM_FEEDBACK_ Z2 GetIntegerv INTERLEAVED_ Transform feedback mode 2.Y - BUFFER_MODE_NV ATTRIBS_NV TRANSFORM_FEEDBACK_ Z2 GetIntegerv 0 Number of attributes to 2.Y - ATTRIBS_NV capture in transform feedback mode TRANSFORM_FEEDBACK_ Z+ GetIntegerv 0 Buffer object bound to 6.1.13 - BUFFER_BINDING_NV generic bind point for transform feedback. TRANSFORM_FEEDBACK_ nx3*Z+ GetInteger- 0 Name, component count, 6.1.14 - RECORD_NV IndexedvEXT and index of each attribute captured TRANSFORM_FEEDBACK_ nxZ+ GetInteger- 0 Buffer object bound to 6.1.13 - BUFFER_BINDING_NV IndexedvEXT each transform feedback attribute stream. TRANSFORM_FEEDBACK_ nxZ+ GetInteger- 0 Start offset of binding 6.1.13 - BUFFER_START_NV IndexedvEXT range for each transform feedback attrib. stream TRANSFORM_FEEDBACK_ nxZ+ GetInteger- 0 Size of binding range 6.1.13 - BUFFER_SIZE_NV 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) QUERY_RESULT 3xZ+ GetQueryObjectiv 0 Query object result 2.X - (samples passed, Time elapsed, feedback data amount) QUERY_RESULT_AVAILABLE 3xZ+ GetQueryObjectiv TRUE Query object result 2.X - available? (Modify Table 6.29, p. 290, Program Object State. Add the following state.) Get Value Type Get Command Init. Value Description Sec Attribute ---------------- ---- ------------ ----------- ------------------------- ----- --------- ACTIVE_VARYINGS_NV Z+ GetProgramiv 0 Number of active varyings 2.15.3 - ACTIVE_VARYING_MAX_ Z+ GetProgramiv 0 Maximum active varying 2.15.3 - LENGTH_NV name length TRANSFORM_FEEDBACK_ Z2 GetProgramiv INTERLEAVED_ Transform feedback mode 6.1.14 - BUFFER_MODE_NV ATTRIBS_NV for the program TRANSFORM_FEEDBACK_ Z+ GetProgramiv 0 Number of varyings to 6.1.14 - VARYINGS_NV stream to buffer object(s) - nxZ+ GetVarying- - Location of each active 2.15.3 - LocationNV varying variable - Z+ GetActive- - Size of each active 2.15.3 - VaryingNV varying variable - Z+ GetActive- - Type of each active 2.15.3 - VaryingNV varying variable - 0+x- GetActive- - Name of each active 2.15.3 - char VaryingNV varying variable - Z+ GetTransform- - Varying location for one 6.1.14 - Feedback- of the multiple varyings VaryingNV to capture 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, transform 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_NV write to a single buffer in interleaved mode MXFB_SEPARATE_ Z+ GetIntegerv 4 Max number of separate 2.Y - ATTRIBS_NV attributes or varyings that can be captured in transform feedback MXFB_SEPARATE Z+ GetIntegerv 4 Max number of components 2.Y - COMPONENTS_NV 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? RESOLVED: The current name is "NV_transform_feedback", playing off the fact that it is transformed primitives that are handled and the similarities to GL feedback mode. 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_NV 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_NV. There are n internal bind points, selected with the 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: BindBufferOffsetNV(TRANSFORM_FEEDBACK_BUFFER_NV, 0, 1, 12); // XFB index 0 points at buffer 1 with offset 12 BindBuffer(TRANSFORM_FEEDBACK_BUFFER_NV, 2); // Buffer 2 is now bound to the external bind point. XFB index 0 still // points at buffer 1 MapBuffer(TRANSFORM_FEEDBACK_BUFFER_NV, ...); // Maps buffer 2 16. How are quads/quadstrips/polygons tessellated 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 raster. 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_NV have a TRANSFORM_FEEDBACK prefix but PRIMITIVES_GENERATED_NV 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. 21. When a GLSL vertex shader is active, what happens in transform feedback mode if non-active varying variables are specified? DISCUSSION: Active varying variables are varying variables, declared in the shader, that the linker determined are actually needed. As an optimization, the linker can discard the ones declared, but not needed. If non-active varying variables need to be fed into a buffer object, the linker should not perform this optimization. There are three suggested resolutions to this problem: 1. The set of varying variables that need to be streamed to a buffer object in transform feedback mode are set as a property of the program object, and are taken into account during the link step. This means that changing the set means the application will have to re-link the program object in order to have the change take effect. 2. The set of varying variables that need to be streamed to a buffer object in transform feedback mode are specified after the program object has been linked. This is the most flexible option from the applications perspective, but this might mean that a) specifying this set could force the GL to re-link 'under the covers', and b) could mean that the GL runs out of varying variable slots because the combined total of the set of active varyings and the varyings to stream in transform feedback mode is too large. 3. This solution is a hybrid of the above two approaches. The set of potential varying variables that need to be streamed to a buffer object are set as a property of the program object. These varying variables are marked as active by the application and therefore cannot be eliminated during the link step. However, a sub-set of varying variables to actually stream to a buffer object can be changed without the application having to re-link the program object. This approach gives the application flexibility to change the set of varying variables to stream, while it eliminates the need for the GL to compile 'under the covers'. RESOLUTION: Option 3 offers a good compromise, and therefore we'll go with that. 22. Given option 3 in the previous resolution, how to specify that a varying variable has to be considered active by the linker? DISCUSSION: There are two approaches to the application specifying which varying variables are active. We can either provide a simple flag that specifies that all varying variables are considered active, or we can provide a more complex mechanism where the application can specify an individual varying variable as being active. RESOLUTION: RESOLVED. The 'all or nothing' flag is a simple idea, but has a drawback when used with a 'uber-shader' that implements many paths to achieve an effect, but only one path is used during any run of the shader. In this case, a lot more varying variables might be flagged as active then really is necessary, running the risk of running out of resources. Therefore, we'll provide a mechanism for the application to specify on a per varying variable basis if it is active. 23. Given the discussion in the previous issues, should a GetActiveVarying() command be added, modeled after the existing getActiveUniform() command? DISCUSSION: Such a command will return the list of active uniforms, after the program object has been linked. As per issue 22's resolution, the complete set of varying variables that could be streamed to a buffer object needs to be specified before the program object is linked. It can be useful to an application to stream out a subset of the active varying variables or to find out the whole set of active varyings, especially since the set can be implementation dependent. RESOLUTION: YES. 24. What is proper use of the command ActiveVaryingNV()? RESOLVED: The application is well advised to force any varying variable live that it needs for transform feedback purposes. The set of active varying variables are linker dependent. For example, if a program object has no fragment shader, then the LinkProgram command cannot typically determine which built-in varying variables, output by a geometry or vertex shader, are active. This is because the fragment processing state can change, and therefore such a determination cannot be made until a render command is issued. Furthermore, any user-defined varyings are likely to be marked as non-active if there is no fragment shader because they are guaranteed to have no effect on fixed-function fragment processing. If there is both a vertex (or geometry) and fragment shader in a program object, the application can probably deduce what will be an active varying variable, or not. But beware of any (static) flow-control that the linker can use to do cross vertex- fragment optimization to cull any varying variables. 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_NV. 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: Yes, there is nothing that precludes this. The application is responsible for sending down the needed vertex attributes and setting the GL state, as desired, for the attributes it wants to stream to a buffer object. Note that VERTEX_ID_NV is not defined in fixed-function. 28. Is it possible to record hardware-generated primitive ID values that would be available to a pixel shader? RESOLVED: Transform feedback can only record the primitive ID values emitted per-vertex by a geometry shader or program. While each primitive recorded for transform-feedback has a well-defined primitive ID, transform feedback is only capable of recording the attributes of individual vertices. 29. Does transform feedback support the ability to capture per-vertex layer outputs, as provided by EXT_geometry_shader4 and NV_geometry_program4? RESOLVED: Yes. For GLSL shaders, it is sufficient to reference the built-in varying "gl_Layer". For assembly geometry programs, the original version of the spec did not provide an enum allowing you to name "result.layer" in TransformFeedbackAttribsNV. This was an oversight in the original spec, which was fixed by version 14. An updated driver will be required to take advantage of this capability; NVIDIA drivers supporting this extension published prior to February 2008 will not be able to capture "result.layer". The value captured for LAYER_NV will be undefined unless a geometry program that writes "result.layer" is active. Revision History Rev. Date Author Changes ---- -------- -------- ----------------------------------------- 18 03/09/11 mjk Minor typo fixes. 17 01/28/11 pbrown Change return value for start/size queries when no buffer bound from -1 to zero, to match state tables (Bug 7318), as done by Jon Leech in related EXT/ARB extensions and the core API specification. 16 08/17/08 pbrown Remove a non-existent function from the set of functions that can generate invalid operation errors while XFB is active. 15 02/20/08 pbrown Fix incorrect minimum for MAX_TRANSFORM_ FEEDBACK_SEPARATE_COMPONENTS_NV. Should be 4, not 16. 14 02/04/08 pbrown Fixed a problem with the spec where we were unable to record "result.layer" using the assembly interface. Added a new enum to address. 13 11/28/07 pbrown Specified the captured primitive ID to be undefined unless a geometry shader emits it as a vertex output. XFB can only record per-vertex data. 12 09/27/07 pbrown Removed incorrect error description from the errors section -- buffer objects don't need to be bound before calling Transform- Feedback{Attribs,Varyings}NV, just before BeginTransformFeedbackNV. 11 08/28/07 pbrown Added an error calling BeginTransformFeedback if no attributes would be captured (i.e., attribute count is 0 for ASM or no attributes specified in the active GLSL program). 10 02/09/07 pbrown Updated status section (now released). 9 10/23/06 pbrown Fixed prototype for GetIntegerIndexedEXT and GetBooleanIndexedEXT: is unsigned. 8 10/19/06 pbrown Removed stray addition of GetFloatIndexedvEXT and GetDoubleIndexedvEXT. Minor wording fixes. 7 10/17/06 pbrown Rename from EXT to NV while working on standardizing a functional subset extension that will be named EXT_transform_feedback. We expect that the EXT should be equivalent to the NV, except that it (a) removes support for non-GLSL usage, (b) removes the ability to change the set of varyings captured without relinking. NVIDIA expects to support both the NV and EXT forms of this extension going forward. Fix state table formatting. Removed GetFloatIndexedvEXT and GetDoubleIndexedvEXT, which are not needed by this and related extensions. 6 09/11/06 pbrown Fix bad prototype for GetActiveVaryingEXT and bad references to "GetActiveVaryingsEXT". Fix enum names for INTERLEAVED_ATTRIBS_EXT and SEPARATE_ATTRIBS_EXT (no TRANSFORM_ FEEDBACK prefix). Remove erroneous state table entries that were obsoleted by the introduction of the TRANSFORM_FEEDBACK_RECORD_EXT query. 5 08/31/06 pbrown Fix miscellaneous spec errata. Record enum values that weren't documented in previous spec versions. Use correct function names for indexed "Get" functions. Clarify that GLSL interactions mean that some functions and enums defined here aren't supported if GLSL isn't supported. Fixed the double-assignment of several TransformFeedbackAttribsEXT enums and re-packed that portion of the enum range. Clarify that several new functions are non-listable. Fix the query tokens for buffer object range bindings to match the API (start/size, not start/end). 4 08/30/06 pbrown Reformatting as a plaintext document instead of an exported MS Word document. 3 07/26/06 barthold Forgot a few changes w.r.t. version 2. 2 07/14/06 barthold Change BindBufferRangeEXT to take an offset and size parameter. Change BindBufferOffsetEXT to take an offset parameter. 1 barthold Internal spec development.