1Name 2 3 EXT_transform_feedback 4 5Name Strings 6 7 GL_EXT_transform_feedback 8 9Contributors 10 11 Nick Carter 12 Charlie Lao 13 Jeremy Sandmel 14 Cliff Woolley 15 Alex Eddy 16 17Contact 18 19 Barthold Lichtenbelt (blichtenbelt 'at' nvidia.com) 20 Pat Brown (pbrown 'at' nvidia.com) 21 Eric Werness (ewerness 'at' nvidia.com) 22 23Status 24 25 Shipping. 26 27Version 28 29 Last Modified Date: 08/09/2013 30 NVIDIA Revision: 8 31 32Number 33 34 352 35 36Dependencies 37 38 The OpenGL Shading Language (GLSL) is required. OpenGL 2.0 or the 39 ARB_shader_objects extension is required. 40 41 EXT_geometry_shader4 trivially interacts with this extension. 42 43 NV_transform_feedback interacts with this extension. 44 45 This extension is written against the OpenGL 2.0 specification. 46 47Overview 48 49 This extension provides a new mode to the GL, called transform feedback, 50 which records selected vertex attributes for each primitive processed by 51 the GL. The selected attributes are written into buffer objects, and can 52 be written with each attribute in a separate buffer object or with all 53 attributes interleaved into a single buffer object. If a geometry shader 54 is active, the primitives recorded are those emitted by the geometry 55 shader. Otherwise, transform feedback captures primitives whose vertices 56 are transformed by a vertex shader. In either case, the primitives 57 captured are those generated prior to clipping. Transform feedback mode 58 captures the values of specified varying variables emitted from GLSL 59 vertex or geometry shaders. 60 61 The vertex data recorded in transform feedback mode is stored into buffer 62 objects as an array of vertex attributes. The regular representation and 63 the use of buffer objects allows the recorded data to be processed 64 directly by the GL without requiring CPU intervention to copy data. In 65 particular, transform feedback data can be used for vertex arrays (via 66 vertex buffer objects), as the source for pixel data (via pixel buffer 67 objects), as shader constant data (via the NV_parameter_buffer_object or 68 EXT_bindable_uniform extensions), or via any other extension that makes 69 use of buffer objects. 70 71 This extension introduces new query object support to allow transform 72 feedback mode to operate asynchronously. Query objects allow applications 73 to determine when transform feedback results are complete, as well as the 74 number of primitives processed and written back to buffer objects while in 75 transform feedback mode. This extension also provides a new rasterizer 76 discard enable, which allows applications to use transform feedback to 77 capture vertex attributes without rendering anything. 78 79New Procedures and Functions 80 81 void BindBufferRangeEXT(enum target, uint index, uint buffer, 82 intptr offset, sizeiptr size); 83 void BindBufferOffsetEXT(enum target, uint index, uint buffer, 84 intptr offset); 85 void BindBufferBaseEXT(enum target, uint index, uint buffer); 86 87 void BeginTransformFeedbackEXT(enum primitiveMode); 88 void EndTransformFeedbackEXT(void); 89 90 void TransformFeedbackVaryingsEXT(uint program, sizei count, 91 const char * const *varyings, 92 enum bufferMode); 93 void GetTransformFeedbackVaryingEXT(uint program, uint index, 94 sizei bufSize, sizei *length, 95 sizei *size, enum *type, char *name); 96 97 void GetIntegerIndexedvEXT(enum param, uint index, int *values); 98 void GetBooleanIndexedvEXT(enum param, uint index, boolean *values); 99 100 (Note: These indexed query functions are provided in the EXT_draw_buffers2 101 extension. The boolean query is not useful for any queryable value in 102 this extension, but is supported for completeness and consistency with 103 base GL typed "Get" functions.) 104 105New Tokens 106 107 Accepted by the <target> parameters of BindBuffer, BufferData, 108 BufferSubData, MapBuffer, UnmapBuffer, GetBufferSubData, 109 GetBufferPointerv, BindBufferRangeEXT, BindBufferOffsetEXT and 110 BindBufferBaseEXT: 111 112 TRANSFORM_FEEDBACK_BUFFER_EXT 0x8C8E 113 114 Accepted by the <param> parameter of GetIntegerIndexedvEXT and 115 GetBooleanIndexedvEXT: 116 117 TRANSFORM_FEEDBACK_BUFFER_START_EXT 0x8C84 118 TRANSFORM_FEEDBACK_BUFFER_SIZE_EXT 0x8C85 119 120 Accepted by the <param> parameter of GetIntegerIndexedvEXT and 121 GetBooleanIndexedvEXT, and by the <pname> parameter of GetBooleanv, 122 GetDoublev, GetIntegerv, and GetFloatv: 123 124 TRANSFORM_FEEDBACK_BUFFER_BINDING_EXT 0x8C8F 125 126 Accepted by the <bufferMode> parameter of TransformFeedbackVaryingsEXT: 127 128 INTERLEAVED_ATTRIBS_EXT 0x8C8C 129 SEPARATE_ATTRIBS_EXT 0x8C8D 130 131 Accepted by the <target> parameter of BeginQuery, EndQuery, and 132 GetQueryiv: 133 134 PRIMITIVES_GENERATED_EXT 0x8C87 135 TRANSFORM_FEEDBACK_PRIMITIVES_WRITTEN_EXT 0x8C88 136 137 Accepted by the <cap> parameter of Enable, Disable, and IsEnabled, and by 138 the <pname> parameter of GetBooleanv, GetIntegerv, GetFloatv, and 139 GetDoublev: 140 141 RASTERIZER_DISCARD_EXT 0x8C89 142 143 Accepted by the <pname> parameter of GetBooleanv, GetDoublev, GetIntegerv, 144 and GetFloatv: 145 146 MAX_TRANSFORM_FEEDBACK_INTERLEAVED_COMPONENTS_EXT 0x8C8A 147 MAX_TRANSFORM_FEEDBACK_SEPARATE_ATTRIBS_EXT 0x8C8B 148 MAX_TRANSFORM_FEEDBACK_SEPARATE_COMPONENTS_EXT 0x8C80 149 150 Accepted by the <pname> parameter of GetProgramiv: 151 152 TRANSFORM_FEEDBACK_VARYINGS_EXT 0x8C83 153 TRANSFORM_FEEDBACK_BUFFER_MODE_EXT 0x8C7F 154 TRANSFORM_FEEDBACK_VARYING_MAX_LENGTH_EXT 0x8C76 155 156 157Additions to Chapter 2 of the OpenGL 2.0 Specification (OpenGL 158Operation) 159 160 Insert three new sections between Sections 2.11, Coordinate Transforms and 161 2.12, Clipping: 162 163 (Move the "Asynchronous Queries" language out of Section 4.1.7. This 164 section doesn't really introduce any new functionality, other than 165 alluding to the transform feedback queries introduced below.) 166 167 Section 2.X, Asynchronous Queries 168 169 Asynchronous queries provide a mechanism to return information about the 170 processing of a sequence of GL commands. There are two query types 171 supported by the GL. Transform feedback queries (section 2.Y) returns 172 information on the number of vertices and primitives processed by the GL 173 and written to one or more buffer objects. Occlusion queries (section 174 4.1.7.1) count the number of fragments or samples that pass the depth 175 test. 176 177 The results of asynchronous queries are not returned by the GL immediately 178 after the completion of the last command in the set; subsequent commands 179 can be processed while the query results are not complete. When 180 available, the query results are stored in an associated query object. 181 The commands described in section 6.1.12 provide mechanisms to determine 182 when query results are available and return the actual results of the 183 query. The name space for query objects is the unsigned integers, with 184 zero reserved by the GL. 185 186 Each type of query supported by the GL has an active query object name. If 187 the active query object name for a query type is non-zero, the GL is 188 currently tracking the information corresponding to that query type and 189 the query results will be written into the corresponding query object. If 190 the active query object for a query type name is zero, no such information 191 is being tracked. 192 193 A query object is created by calling 194 195 void BeginQuery(enum target, uint id); 196 197 with an unused name <id>. <target> indicates the type of query to be 198 performed; valid values of <target> are defined in subsequent 199 sections. When a query object is created, the name <id> is marked as used 200 and associated with a new query object. 201 202 BeginQuery sets the active query object name for the query type given by 203 <target> to <id>. If BeginQuery is called with an <id> of zero, if the 204 active query object name for <target> is non-zero, or if <id> is the 205 active query object name for any query type, the error INVALID OPERATION 206 is generated. 207 208 The command 209 210 void EndQuery(enum target); 211 212 marks the end of the sequence of commands to be tracked for the query type 213 given by <target>. The active query object for <target> is updated to 214 indicate that query results are not available, and the active query object 215 name for <target> is reset to zero. When the commands issued prior to 216 EndQuery have completed and a final query result is available, the query 217 object, active when EndQuery is, called is updated by the GL. The query 218 object is updated to indicate that the query results are available and to 219 contain the query result. If the active query object name for <target> is 220 zero when EndQuery is called, the error INVALID_OPERATION is generated. 221 222 The command 223 224 void GenQueries(sizei n, uint *ids); 225 226 returns <n> previously unused query object names in <ids>. These names are 227 marked as used, but no object is associated with them until the first time 228 they are used by BeginQuery. 229 230 Query objects are deleted by calling 231 232 void DeleteQueries(sizei n, const uint *ids); 233 234 <ids> contains <n> names of query objects to be deleted. After a query 235 object is deleted, its name is again unused. Unused names in <ids> are 236 silently ignored. 237 238 Calling either GenQueries or DeleteQueries while any query of any target 239 is active causes an INVALID_OPERATION error to be generated. 240 241 Query objects contain two pieces of state: a single bit indicating 242 whether a query result is available, and an integer containing the query 243 result value. The number of bits used to represent the query result is 244 implementation-dependent. In the initial state of a query object, the 245 result is available and its value is zero. 246 247 The necessary state for each query type is an unsigned integer holding the 248 active query object name (zero if no query object is active), and any 249 state necessary to keep the current results of an asynchronous query in 250 progress. 251 252 Section 2.Y, Transform Feedback 253 254 In transform feedback mode, attributes of the vertices of transformed 255 primitives processed by a vertex or geometry shader are written out to one 256 or more buffer objects. The vertices are fed back after vertex color 257 clamping, but before clipping. If a geometry shader is active, the 258 vertices recorded are those emitted from the geometry shader. The 259 transformed vertices may be optionally discarded after being stored into 260 one or more buffer objects, or they can be passed on down to the clipping 261 stage for further processing. The set of attributes captured is 262 determined when a program is linked. 263 264 Transform feedback is started and finished by calling 265 266 void BeginTransformFeedbackEXT(enum primitiveMode) 267 268 and 269 270 void EndTransformFeedbackEXT(void), 271 272 respectively. Transform feedback is said to be active after a call to 273 BeginTransformFeedbackEXT and inactive after a call to 274 EndTransformFeedbackEXT. <primitiveMode> is one of TRIANGLES, LINES, or 275 POINTS, and specifies the output type of primitives that will be recorded 276 into the buffer objects bound for transform feedback (see 277 below). <primitiveMode> places a restriction on the primitive types that 278 may be rendered while transform feedback is active -- see table X.1. 279 280 Transform Feedback 281 primitiveMode allowed render primitive modes 282 ---------------------- --------------------------------- 283 POINTS POINTS 284 LINES LINES, LINE_LOOP, and LINE_STRIP 285 TRIANGLES TRIANGLES, TRIANGLE_STRIP, 286 TRIANGLE_FAN, QUADS, QUAD_STRIP, 287 and POLYGON 288 289 Table X.1 Legal combinations between the transform feedback primitive 290 mode, as passed to BeginTransformFeedbackEXT and the current primitive 291 mode. 292 293 Transform feedback commands must be paired; the error INVALID_OPERATION is 294 generated by BeginTransformFeedbackEXT if transform feedback is active, 295 and by EndTransformFeedbackEXT if transform feedback is inactive. 296 297 Transform feedback mode captures the values of varying variables written 298 by an active vertex or geometry shader. The error INVALID_OPERATION is 299 generated by BeginTransformFeedbackEXT if no vertex or geometry shader is 300 not active. 301 302 When transform feedback is active, all geometric primitives generated must 303 be compatible with the value of <primitiveMode> passed to 304 BeginTransformFeedbackEXT. The error INVALID_OPERATION is generated by 305 Begin or any operation that implicitly calls Begin (such as DrawElements) 306 if <mode> is not one of the allowed modes in Table X.1. If a geometry 307 shader is active, its output primtive type is used instead of the <mode> 308 parameter passed to Begin for the purposes of this error check. 309 310 Buffer objects are made to be targets of transform feedback by calling one 311 of the commands 312 313 void BindBufferRangeEXT(enum target, uint index, uint buffer, 314 intptr offset, sizeiptr size) 315 void BindBufferOffsetEXT(enum target, uint index, uint buffer, 316 intptr offset) 317 void BindBufferBaseEXT(enum target, uint index, uint buffer) 318 319 with <target> set to TRANSFORM_FEEDBACK_BUFFER_EXT. There is an array of 320 buffer object binding points that are used while transform feedback is 321 active, plus a single general binding point that can be used by other 322 buffer object manipulation functions (e.g., BindBuffer, MapBuffer). All 323 three commands bind the buffer object named by <buffer> to the general 324 binding point, and additionally bind the buffer object to the binding 325 point in the array given by <index>. The error INVALID_VALUE is generated 326 if <index> is greater than or equal to the value of 327 MAX_TRANSFORM_FEEDBACK_SEPARATE_ATTRIBS_EXT. 328 329 For BindBufferRangeEXT, <offset> specifies a starting offset into the 330 buffer object <buffer> and <size> specifies the amount of data that can be 331 written to the buffer object while transform feedback mode is active. 332 Both <offset> and <size> are in basic machine units. The error 333 INVALID_VALUE is generated if the value of <size> is less than or equal to 334 zero, or if either <offset> or <size> are not word-aligned. Calling 335 BindBufferOffsetEXT is equivalent of calling BindBufferRangeEXT with 336 <size> = sizeof(buffer) - <offset>, and rounding <size> down so that it is 337 word-aligned. BindBufferBaseEXT is equivalent to calling 338 BindBufferOffsetEXT with an <offset> of 0. 339 340 When an individual point, line, or triangle primitive reaches the 341 transform feedback stage while transform feedback is active, the values of 342 the specified varying variables of the vertex are appended to the buffer 343 objects bound to the transform feedback binding points. The attributes of 344 the first vertex received after BeginTransformFeedbackEXT are written at 345 the starting offsets of the bound buffer objects set by 346 BindBufferRangeEXT, and subsequent vertex attributes are appended to the 347 buffer object. When capturing line and triangle primitives, all 348 attributes of the first vertex are written first, followed by attributes 349 of the subsequent vertices. When writing varying variables that are 350 arrays, individual array elements are written in order. For 351 multi-component varying variables or varying array elements, the 352 individual components are written in order. The value for any attribute 353 specified to be streamed to a buffer object but not actually written by a 354 vertex or geometry shader is undefined. 355 356 When quads and polygons are provided to transform feedback with a 357 primitive mode of TRIANGLES, they will be tessellated and recorded as 358 triangles (the order of tessellation within a primitive is undefined). 359 Individual lines or triangles of a strip or fan primitive will be 360 extracted and recorded separately. Incomplete primitives are not recorded. 361 362 Transform feedback can operate in either INTERLEAVED_ATTRIBS_EXT or 363 SEPARATE_ATTRIBS_EXT mode. In INTERLEAVED_ATTRIBS_EXT mode, the values of 364 one or more varyings are written, interleaved, into the buffer object 365 bound to the first transform feedback binding point (index = 0). If more 366 than one varying variable is written, they will be recorded in the order 367 specified by TransformFeedbackVaryingsEXT (section 2.15.3). In 368 SEPARATE_ATTRIBS_EXT mode, the first varying variable specified by 369 TransformFeedbackVaryingsEXT is written to the first transform feedback 370 binding point; subsequent varying variables are written to the subsequent 371 transform feedback binding points. The total number of variables that may 372 be captured in separate mode is given by 373 MAX_TRANSFORM_FEEDBACK_SEPARATE_ATTRIBS_EXT. 374 375 If recording the vertices of a primitive to the buffer objects being used 376 for transform feedback purposes would result in either exceeding the 377 limits of any buffer object's size, or in exceeding the end position 378 <offset> + <size> - 1, as set by BindBufferRangeEXT, then no vertices of 379 that primitive are recorded in any buffer object, and the counter 380 corresponding to the asynchronous query target 381 TRANSFORM_FEEDBACK_PRIMITIVES_WRITTEN_EXT (see Section 2.Z) is not 382 incremented. 383 384 In either separate or interleaved modes, all transform feedback binding 385 points that will be written to must have buffer objects bound when 386 BeginTransformFeedbackEXT is called. The error INVALID_OPERATION is 387 generated by BeginTransformFeedbackEXT if any binding point used in 388 transform feedback mode does not have a buffer object bound. In 389 interleaved mode, only the first buffer object binding point is ever 390 written to. The error INVALID_OPERATION is also generated by 391 BeginTransformFeedbackEXT if no binding points would be used, either 392 because no program object is active or because the active program object 393 has specified no varying variables to record. 394 395 While transform feedback is active, the set of attached buffer objects and 396 the set of varying variables captured may not be changed. If transform 397 feedback is active, the error INVALID_OPERATION is generated by 398 UseProgram, by LinkProgram if <program> is the currently active program 399 object, and by BindBufferRangeEXT, BindBufferOffsetEXT, or 400 BindBufferBaseEXT if <target> is TRANSFORM_FEEDBACK_BUFFER_EXT. 401 402 403 Section 2.Z, Primitive Queries 404 405 Primitive queries use query objects to track the number of primitives 406 generated by the GL and to track the number of primitives written to 407 transform feedback buffers. 408 409 When BeginQuery is called with a <target> of PRIMITIVES_GENERATED_EXT, the 410 primitives-generated count maintained by the GL is set to zero. When the 411 generated primitive query is active, the primitives-generated count is 412 incremented every time a primitive reaches the Discarding Rasterization 413 stage (see Section 3.x) right before rasterization. This counter counts 414 the number of primitives emitted by a geometry shader, if active, possibly 415 further tessellated into separate primitives during the transform-feedback 416 stage, if active. 417 418 When BeginQuery is called with a <target> of 419 TRANSFORM_FEEDBACK_PRIMITIVES_WRITTEN_EXT, the transform-feedback- 420 primitives-written count maintained by the GL is set to zero. When the 421 transform feedback primitive written query is active, the 422 transform-feedback-primitives-written count is incremented every time a 423 primitive is recorded into a buffer object. If transform feedback is not 424 active, this counter is not incremented. If the primitive does not fit in 425 the buffer object, the counter is not incremented. 426 427 These two queries can be used together to determine if all primitives have 428 been written to the bound feedback buffers; if both queries are run 429 simultaneously and the query results are equal, all primitives have been 430 written to the buffer(s). If the number of primitives written is less than 431 the number of primitives generated, the buffer is full. 432 433 434 Modify Section 2.15.3 "Shader Variables", p. 75. 435 436 Change the second sentence in the first paragraph on p. 84 as follows: 437 438 . . . written by a vertex shader, read by a fragment shader, or used for 439 transform feedback will count against this limit. The transformed vertex 440 position (gl_Position) does not count against this limit. ... 441 442 Add the following language to the end of section 2.15.3 (p.84): 443 444 Each program object can specify one or more varying variables to be 445 recorded in transform feedback mode. This set is specified by the command 446 447 void TransformFeedbackVaryingsEXT(uint program, sizei count, 448 const char * const *varyings, 449 enum bufferMode) 450 451 <program> specifies the program object. <count> specifies the number of 452 varying variables used for transform feedback. <varyings> is an array of 453 <count> zero-terminated strings specifying the names of the varying 454 variables to use for transform feedback. The varying variables specified 455 in <varyings> can be either built-in varying variables (beginning with 456 "gl_") or user-defined ones. varying variables are written out in the 457 order they appear in the array <varyings>. <bufferMode> is either 458 INTERLEAVED_ATTRIBS_EXT or SEPARATE_ATTRIBS_EXT, and identifies the mode 459 used to capture the varying variables when transform feedback is active. 460 The error INVALID_VALUE is generated if <program> is not the name of a 461 program object, or if <bufferMode> is SEPARATE_ATTRIBS_EXT and <count> is 462 greater than the implement-dependent limit 463 MAX_TRANSFORM_FEEDBACK_SEPARATE_ATTRIBS_EXT. 464 465 The state set by TransformFeedbackVaryingsEXT has no effect on the 466 execution of the program until <program> is subsequently linked. When 467 LinkProgram is called, the program is linked so that the values of the 468 specified varying variables for the vertices of each primitive generated 469 by the GL are written to a single buffer object (if the buffer mode is 470 INTERLEAVED_ATTRIBS_EXT) or multiple buffer objects (if the buffer mode is 471 SEPARATE_ATTRIBS_EXT). A program will fail to link if: 472 473 * the <count> specified by TransformFeedbackVaryingsEXT is non-zero, but 474 the program object has no vertex or geometry shader; 475 476 * any variable name specified in the <varyings> array is not declared as 477 an output in the geometry shader (if present) or the vertex shader (if 478 no geometry shader is present); 479 480 * any two entries in the <varyings> array specify the same varying 481 variable; 482 483 * the total number of components to capture in any varying variable in 484 <varyings> is greater than the constant 485 MAX_TRANSFORM_FEEDBACK_SEPARATE_COMPONENTS_EXT and the buffer mode is 486 SEPARATE_ATTRIBS_EXT; or 487 488 * the total number of components to capture is greater than the constant 489 MAX_TRANSFORM_FEEDBACK_INTERLEAVED_COMPONENTS_EXT and the buffer mode 490 is INTERLEAVED_ATTRIBS_EXT. 491 492 To determine the set of varying variables in a linked program object that 493 will be captured in transform feedback mode, use the command: 494 495 void GetTransformFeedbackVaryingEXT(uint program, uint index, 496 sizei bufSize, sizei *length, 497 sizei *size, enum *type, 498 char *name); 499 500 This command provides information about the varying variable selected by 501 <index>. An <index> of 0 selects the first varying variable specified in 502 the <varyings> array of TransformFeedbackVaryingsEXT, and an <index> of 503 TRANSFORM_FEEDBACK_VARYINGS_EXT-1 selects the last such varying variable. 504 The value of TRANSFORM_FEEDBACK_VARYINGS_EXT can be queried with 505 GetProgramiv (see section 6.1.14). If <index> is greater than or equal to 506 TRANSFORM_FEEDBACK_VARYINGS_EXT, the error INVALID_VALUE is generated. 507 The parameter <program> is the name of a program object for which the 508 command LinkProgram has been issued in the past. If a new set of varying 509 variables is specified by TransformFeedbackVaryingsEXT after a program 510 object has been linked, the information returned by 511 GetTransformFeedbackVaryingEXT will not reflect those variables until the 512 program is re-linked. 513 514 The name of the selected varying is returned as a null-terminated string 515 in <name>. The actual number of characters written into <name>, excluding 516 the null terminator, is returned in <length>. If <length> is NULL, no 517 length is returned. The maximum number of characters that may be written 518 into <name>, including the null terminator, is specified by <bufSize>. The 519 returned varying name can be the name of a user defined varying variable 520 or the name of a built- in varying (which begin with the prefix "gl_", see 521 the OpenGL Shading Language specification for a complete list). The length 522 of the longest varying name in program is given by 523 TRANSFORM_FEEDBACK_VARYING_MAX_LENGTH_EXT, which can be queried with 524 GetProgramiv (see section 6.1.14). 525 526 For the selected varying variable, its type is returned into <type>. The 527 size of the varying is returned into <size>. The value in <size> is in 528 units of the type returned in <type>. The type returned can be any of 529 FLOAT, FLOAT_VEC2, FLOAT_VEC3, FLOAT_VEC4, INT, INT_VEC2, INT_VEC3, 530 INT_VEC4, UNSIGNED_INT, UNSIGNED_INT_VEC2_EXT, UNSIGNED_INT_VEC3_EXT, 531 UNSIGNED_INT_VEC4_EXT, FLOAT_MAT2, FLOAT_MAT3, or FLOAT_MAT4. If an error 532 occurred, the return parameters <length>, <size>, <type> and <name> will 533 be unmodified. This command will return as much information about the 534 varying variables as possible. If no information is available, <length> 535 will be set to zero and <name> will be an empty string. This situation 536 could arise if GetTransformFeedbackVaryingEXT is called after a failed 537 link. 538 539 540Additions to Chapter 3 of the OpenGL 2.0 Specification (Rasterization) 541 542 (Add new section 3.X, Discarding Rasterization) 543 544 Primitives can be optionally discarded before rasterization by calling 545 Enable and Disable with RASTERIZER_DISCARD_EXT. When enabled, primitives 546 are discared right before the rasterization stage, but after the optional 547 transform feedback stage. When disabled, primitives are passed through to 548 the rasterization stage to be processed normally. RASTERIZER_DISCARD_EXT 549 applies to the DrawPixels, CopyPixels, Bitmap, Clear and Accum commands as 550 well. 551 552 553Additions to Chapter 4 of the OpenGL 2.0 Specification (Per-Fragment 554Operations and the Frame Buffer) 555 556 (Replace section 4.1.7, "Occlusion Queries", p. 204, with the following) 557 558 Occlusion queries use query objects to track the number of fragments or 559 samples that pass the depth test. An occlusion query can be started and 560 finished by calling BeginQuery and EndQuery, respectively, with a <target> 561 of SAMPLES_PASSED. 562 563 When an occlusion query starts, the samples-passed count maintained by the 564 GL is set to zero. When an occlusion query is active, the samples-passed 565 count is incremented for each fragment that passes the depth test. If the 566 value of SAMPLE BUFFERS is 0, then the samples- passed count is 567 incremented by 1 for each fragment. If the value of SAMPLE BUFFERS is 1, 568 then the samples-passed count is incremented by the number of samples 569 whose coverage bit is set. However, implementations, at their discretion, 570 may instead increase the samples-passed count by the value of SAMPLES if 571 any sample in the fragment is covered. When an occlusion query finishes 572 and all fragments generated by the commands issued prior to EndQuery have 573 been generated, the samples-passed count is written to the corresponding 574 query object as the query result value, and the query result for that 575 object is marked as available. 576 577 If the samples-passed count overflows, (i.e., exceeds the value 2^n - 1, 578 where n is the number of bits in the samples-passed count), its value 579 becomes undefined. It is recommended, but not required, that 580 implementations handle this overflow case by saturating at 2^n - 1 and 581 incrementing no further. 582 583 584Additions to Chapter 5 of the OpenGL 2.0 Specification (Special Functions) 585 586 (Add to section 5.4, Display Lists p. 237) 587 588 On p. 241, add the following to the list of vertex buffer object commands 589 not compiled into a display list: BindBufferRangeEXT, BindBufferOffsetEXT, 590 BindBufferBaseEXT, and TransformFeedbackVaryingsEXT. 591 592 593Additions to Chapter 6 of the OpenGL 2.0 Specification (State and State 594Requests) 595 596 Modify the second paragraph of section 6.1.1 (Simple Queries) p244 to read 597 as follows: 598 599 ...<data> is a pointer to a scalar or array of the indicated type in which 600 to place the returned data. The commands 601 602 void GetIntegerIndexedvEXT(enum param, uint index, int *values); 603 void GetBooleanIndexedvEXT(enum param, uint index, boolean *values); 604 605 are used to query indexed state. <target> is the name of the indexed 606 state and <index> is the index of the particular element being queried. 607 <data> is a pointer to a scalar or array of the indicated type in which to 608 place the returned data. In addition ... 609 610 (Replace Section 6.1.12, Occlusion Queries, p. 254) 611 612 Section 6.1.12, Asynchronous Queries 613 614 The command 615 616 boolean IsQuery(uint id); 617 618 returns TRUE if <id> is the name of a query object. If <id> is zero, or if 619 <id> is a non-zero value that is not the name of a query object, IsQuery 620 returns FALSE. 621 622 Information about a query target can be queried with the command 623 624 void GetQueryiv(enum target, enum pname, int *params); 625 626 <target> identifies the query target and can be SAMPLES_PASSED for 627 occlusion queries or PRIMITIVES_GENERATED_EXT and 628 TRANSFORM_FEEDBACK_PRIMITIVES_WRITTEN_EXT for primitive queries. 629 630 If <pname> is CURRENT_QUERY, the name of the currently active query for 631 <target>, or zero if no query is active, will be placed in <params>. 632 633 If <pname> is QUERY_COUNTER_BITS, the implementation-dependent number of 634 bits used to hold the query result for <target> will be placed in 635 params. The number of query counter bits may be zero, in which case the 636 counter contains no useful information. 637 638 For primitive queries (PRIMITIVES_GENERATED_EXT and 639 TRANSFORM_FEEDBACK_PRIMITIVES_WRITTEN_EXT) if the number of bits is 640 non-zero, the minimum number of bits allowed is 32. 641 642 For occlusion queries (SAMPLES_PASSED), if the number of bits is non- 643 zero, the minimum number of bits allowed is a function of the 644 implementation's maximum viewport dimensions (MAX_VIEWPORT_DIMS). The 645 counter must be able to represent at least two overdraws for every pixel 646 in the viewport. The formula to compute the allowable minimum value (where 647 n is the minimum number of bits) is: 648 649 n = min(32, ceil(log_2(maxViewportWidth * 650 maxViewportHeight * 2))). 651 652 The state of a query object can be queried with the commands 653 654 void GetQueryObjectiv(uint id, enum pname, int *params); 655 void GetQueryObjectuiv(uint id, enum pname, uint *params); 656 657 If <id> is not the name of a query object, or if the query object named by 658 <id> is currently active, then an INVALID_OPERATION error is generated. 659 660 If <pname> is QUERY_RESULT, then the query object's result value is 661 returned as a single integer in <params>. If the value is so large in 662 magnitude that it cannot be represented with the requested type, then the 663 nearest value representable using the requested type is returned. If the 664 number of query counter bits for any <target> is zero, then the result is 665 returned as a single integer with a value of 0. 666 667 There may be an indeterminate delay before the above query returns. If 668 <pname> is QUERY_RESULT_AVAILABLE, FALSE is returned if such a delay would 669 be required, TRUE is returned otherwise. It must always be true that if 670 any query object returns a result available of TRUE, all queries of the 671 same type issued prior to that query must also return TRUE. 672 673 Querying the state for any given query object forces the corresponding 674 query to complete within a finite amount of time. 675 676 If multiple queries are issued using the same object name prior to calling 677 GetQueryObject[u]iv, the result and availability information returned will 678 always be from the last query issued. The results from any queries before 679 the last one will be lost if they are not retrieved before starting a new 680 query on the same <target> and <id>. 681 682 683 (Add to Section 6.1.13, Buffer Objects, p. 255) 684 685 Add the following paragraph to the bottom of this section, p. 256. 686 687 To query which buffer objects are bound to the array of transform feedback 688 binding points and will be used when transform feedback is active, call 689 GetIntegerIndexedvEXT() with <param> set to 690 TRANSFORM_FEEDBACK_BUFFER_BINDING_EXT. <index> has to be in the range 0 691 to MAX_TRANSFORM_FEEDBACK_SEPARATE_ATTRIBS_EXT - 1, otherwise the error 692 INVALID_VALUE is generated. The name of the buffer object bound to <index> 693 is returned in <values>. If no buffer object is bound for <index>, zero is 694 returned in <values>. 695 696 To query the starting offset or size of the range of each buffer object 697 binding used for transform feedback, call GetIntegerIndexedvEXT() with 698 <param> set to TRANSFORM_FEEDBACK_BUFFER_START_EXT or 699 TRANSFORM_FEEDBACK_BUFFER_SIZE_EXT respectively. The error INVALID_VALUE 700 is generated if <index> not in the range 0 to 701 MAX_TRANSFORM_FEEDBACK_SEPARATE_ATTRIBS_EXT - 1. If the parameter 702 (starting offset or size) was not specified when the buffer object was 703 bound, or if no buffer object is bound to <index>, zero is returned. 704 705 (add to Section 6.1.14, Shader and Program Queries, p. 256) 706 707 Add the following paragraph to the bottom of page 257: 708 709 If <pname> is TRANSFORM_FEEDBACK_BUFFER_MODE_EXT, the buffer mode, used 710 when transform feedback is active, is returned. It can be one of 711 SEPARATE_ATTRIBS_EXT or INTERLEAVED_ATTRIBS_EXT. If <pname> is 712 TRANSFORM_FEEDBACK_VARINGS_EXT, the number of varying variables to capture 713 in transform feedback mode for the program is returned. If <pname> is 714 TRANSFORM_FEEDBACK_VARYING_MAX_LENGTH, the length of the longest varying 715 name specified to be used for transform feedback, including a null 716 terminator, is returned. If no varyings are used for transform feedback, 717 zero is returned. 718 719Additions to Appendix A of the OpenGL 2.0 Specification (Invariance) 720 721 None. 722 723Additions to the AGL/GLX/WGL Specifications 724 725 None. 726 727GLX Protocol 728 729 UNDER DEVELOPMENT 730 731Interactions with NV_transform_feedback 732 733 NV_transform_feedback is the initial version of this extension, which 734 includes three capabilities not provided here: 735 736 * support for transform feedback with assembly vertex/geometry programs 737 and fixed-function vertex processing; 738 739 * the ability to change the set of GLSL varying variables to capture in 740 transform feedback mode without re-linking; and 741 742 * the "active varying" API that enumerates all varying variables in a 743 program object that are considered active. 744 745 This extension provides one capability not provided by 746 NV_transform_feedback -- the ability and requirement to specify the set of 747 varying variables used for transform feedback prior to linking. 748 749 If both extensions are supported, the following happens: 750 751 * When a program is linked, the active varying state defined in the NV 752 extension is updated. For the purposes of this API, any variables 753 enabled for transform feedback via TransformFeedbackVaryingsEXT() are 754 considered active. 755 756 * When a program is linked, the transform feedback configuration is 757 built from the state provided by TransformFeedbackVaryingsEXT() as in 758 the current extension. In terms of the NV extension, it is as though 759 the linker had queried the locations of each varying specified in 760 TransformFeedbackVaryingsEXT() and then called the 761 TransformFeedbackVaryingsNV() to update the transform feedback 762 configuration post-link. If no varying variables were specified by 763 TransformFeedbackVaryingsEXT(), the transform feedback configuration 764 is reset to an empty default state after linking, just as is always 765 the case when using the NV extension alone. 766 767 * Calling TransformFeedbackVaryingsNV() after linking allows an 768 application to update the transform feedback state post-link. Any 769 transform feedback state set when a program is linked is replaced with 770 the state specified by TransformFeedbackVaryingsNV(). 771 772 * Calling TransformFeedbackVaryingsEXT() after linking continues to have 773 no effect. 774 775 * The EXT and NV versions of all functions defined in both extension, 776 other than TransformFeedbackVaryings*(), operate identically. 777 778 * BeginTransformFeedbackEXT() does not require the use of a GLSL program 779 object if both extensions are supported. If no GLSL program object is 780 active, transform feedback is still enabled and captures the 781 attributes specified by TransformFeedbackAttribsNV(). 782 783 784Interactions with EXT_timer_query 785 786 EXT_timer_query is the first extension to generalize the BeginQuery and 787 EndQuery mechanism introduced by ARB_occlusion_query and OpenGL 1.5 to 788 cover an additional query type. This extension is the second. This 789 extension is written against the OpenGL 2.0 specification and uses most of 790 the modifications in the EXT_timer_query specification. If 791 EXT_timer_query is supported, timer queries need to be added as a third 792 query type. 793 794 795Dependencies on EXT_geometry_shader4 796 797 If EXT_geometry_shader4 is not supported, delete all references to 798 geometry shaders. 799 800 801Errors 802 803 The error INVALID_OPERATION is generated by BeginQuery if called with an 804 <id> of zero, if the active query object name for <target> is non- zero, 805 or if <id> is the active query object name for any query type. 806 807 The error INVALID_OPERATION is generated by EndQuery if the active query 808 object name for <target> is zero. 809 810 The error INVALID_OPERATION is generated if Begin, or any command that 811 performs an explicit Begin, is called when: 812 813 * a geometry shader is not active and <mode> does not match the allowed 814 begin modes for the current transform feedback state as given by table 815 X.1. 816 817 * a geometry shader is active and the output primitive type of the 818 geometry shader does not match the allowed begin modes for the current 819 transform feedback state as given by table X.1. 820 821 The error INVALID_OPERATION is generated by BeginTransformFeedbackEXT if 822 any transform feedback buffer object binding point used in transform 823 feedback mode does not have a buffer object bound. 824 825 The error INVALID_OPERATION is also generated by BeginTransformFeedbackEXT 826 if no binding points would be used, either because no program object is 827 active or because the active program object has specified no varying 828 variables to record. 829 830 If transform feedback is active, the error INVALID_OPERATION is generated 831 by BeginTransformFeedbackEXT; UseProgram; LinkProgram if called on the 832 currently in use program object; and BindBufferRangeEXT, 833 BindBufferOffsetEXT, or BindBufferBaseEXT if <target> is 834 TRANSFORM_FEEDBACK_BUFFER_EXT. 835 836 If transform feedback is inactive, the error INVALID_OPERATION is 837 generated by EndTransformFeedbackEXT. 838 839 The error INVALID_VALUE is generated by BindBufferRangeEXT, 840 BindBufferOffsetEXT, or BindBufferBaseEXT if <index> is greater or equal 841 than MAX_TRANSFORM_FEEDBACK_SEPARATE_ATTRIBS_EXT. 842 843 The error INVALID_VALUE is generated by BindBufferRangeEXT if the value of 844 <size> is less than or equal to zero, or not word-aligned. 845 846 The error INVALID_VALUE is generated by BindBufferRangeEXT or 847 BindBufferOffsetEXT if <offset> is not word-aligned. 848 849 The error INVALID_VALUE is generated by TransformFeedbackVaryingsEXT 850 commands if <program> is not the name of a program object, or if 851 <bufferMode> is SEPARATE_ATTRIBS_EXT and <count> is greater than 852 MAX_TRANSFORM_FEEDBACK_SEPARATE_ATTRIBS_EXT. 853 854 The error INVALID_VALUE is generated by GetTransformFeedbackVaryingEXT if 855 <index> is greater than or equal to the value of 856 TRANSFORM_FEEDBACK_VARYINGS_EXT. 857 858 The error INVALID_VALUE is generated by GetIntegerIndexedvEXT() or 859 GetBooleanIndexedvEXT() with <param> set to 860 TRANSFORM_FEEDBACK_BUFFER_BINDING_EXT if <index> is greater than or equal 861 to MAX_TRANSFORM_FEEDBACK_SEPARATE_ATTRIBS_EXT. 862 863 864New State 865 866 (Add a new table: Table 6.X, Transform Feedback State) 867 868 Get Value Type Get Command Init. Value Description Sec Attrib 869 ------------------ ------ -------------- ------------ ------------------------- ----- ------ 870 TRANSFORM_FEEDBACK_ Z+ GetIntegerv 0 Buffer object bound to 6.1.13 - 871 BUFFER_BINDING_EXT generic bind point for 872 transform feedback. 873 TRANSFORM_FEEDBACK_ nxZ+ GetInteger- 0 Buffer object bound to 6.1.13 - 874 BUFFER_BINDING_EXT IndexedvEXT each transform feedback 875 attribute stream. 876 TRANSFORM_FEEDBACK_ nxZ+ GetInteger- 0 Start offset of binding 6.1.13 - 877 BUFFER_START_EXT IndexedvEXT range for each transform 878 feedback attrib. stream 879 TRANSFORM_FEEDBACK_ nxZ+ GetInteger- 0 Size of binding range 6.1.13 - 880 BUFFER_SIZE_EXT IndexedvEXT for each transform 881 feedback attrib. stream 882 883 (Modify Table 6.37, p 298, updating the query object state to cover 884 transform feedback.) 885 886 Get Value Type Get Command Init. Value Description Sec Attribute 887 ---------------- ---- ---------------- ----------- ------------------------- ----- --------- 888 CURRENT_QUERY 3xZ+ GetQueryiv 0 Active query object name 2.X - 889 (occlusion, timer, xform 890 feedback) 891 892 (Modify Table 6.29, p. 290, Program Object State. Add the following state.) 893 894 Get Value Type Get Command Init. Value Description Sec Attribute 895 ---------------- ---- ------------ ----------- ------------------------- ----- --------- 896 TRANSFORM_FEEDBACK_ Z2 GetProgramiv INTERLEAVED_ Transform feedback mode 6.1.14 - 897 BUFFER_MODE_EXT ATTRIBS_EXT for the program 898 TRANSFORM_FEEDBACK_ Z+ GetProgramiv 0 Number of varyings to 6.1.14 - 899 VARYINGS_EXT stream to buffer object(s) 900 TRANSFORM_FEEDBACK_ Z+ GetProgramiv 0 Maximum transform feedback 6.1.14 - 901 VARYING_MAX_ varying name length 902 LENGTH_EXT 903 - Z+ GetTransform- - Size of each transform 2.15.3 - 904 Feedback- feedback varying variable 905 VaryingEXT 906 - Z+ GetTransform- - Type of each transform 2.15.3 - 907 Feedback- feedback varying variable 908 VaryingEXT 909 - 0+x- GetTransform- - Name of each transform 2.15.3 - 910 char Feedback- feedback varying variable 911 VaryingEXT 912 913 (Add new Table, Query Object State. Note: There is nothing transform 914 feedback-specific here; this table should be in the core specification.) 915 916 Get Value Type Get Command Init. Value Description Sec Attribute 917 ---------------- ---- ------------ ----------- ------------------------- ------ --------- 918 QUERY_RESULT Z+ GetQuery- 0 Query object result 6.1.12 - 919 Objectiv (query type-dependent) 920 QUERY_RESULT_ Z+ GetQuery- TRUE Is the query object 6.1.12 - 921 AVAILABLE Objectiv result available? 922 923 924New Implementation Dependent State 925 926 (Modify Table 6.34, p. 295. Update the query object state to cover 927 transform feedback.) 928 929 Get Value Type Get Command Minimum Value Description Sec Attribute 930 -------------------- ---- ----------- ------------- -------------------------- ------ --------- 931 QUERY_COUNTER_BITS 2xZ+ GetQueryiv see 6.1.12 Asynchronous query counter 6.1.12 - 932 bits (occlusion, timer, 933 tranform feedback queries) 934 935 (Add a new table, Table 6.X. Transform Feedback State.) 936 937 NOTE: In the "GetValue" columns below, MXFB stands for 938 "MAX_TRANSFORM_FEEDBACK". 939 940 Get Value Type Get Command Minimum Value Description Sec Attribute 941 -------------------- ---- ----------- ------------- -------------------------- ------ --------- 942 MXFB_INTERLEAVED_ Z+ GetIntegerv 64 Max number of components to 2.Y - 943 COMPONENTS_EXT write to a single buffer in 944 interleaved mode 945 MXFB_SEPARATE_ Z+ GetIntegerv 4 Max number of separate 2.Y - 946 ATTRIBS_EXT attributes or vayings that 947 can be captured in transform 948 feedback 949 MXFB_SEPARATE_ Z+ GetIntegerv 4 Max number of components 2.Y - 950 COMPONENTS_EXT per attribute or varying 951 in separate mode 952 953Issues 954 955 1. How does transform feedback differ from core GL feedback? 956 957 * Transform feedback writes vertex data to buffer objects, which allows 958 the data returned to be used directly by vertex pulling. GL feedback 959 mode writes vertex data to a buffer in system memory. 960 961 * Transform feedback is done after transformation, but prior to 962 clipping. The primitives returned contain the original transformed 963 vertices produced by vertex or geometry program execution, and does 964 not contain any primitives inserted by clipping. 965 966 * Transform feedback supports only a single basic output primitive type 967 (points, lines, or triangles), while core GL feedback mode supports 968 all primitive types. Since only one primitive type is supported, the 969 data returned does not contain tokens describing each primitive being 970 fed back. Primitive tokens make the data returned by GL feedback mode 971 irregular and unsuitable for vertex pulling. 972 973 2. What should this extension be called, and how does it differ from 974 previous extensions? 975 976 RESOLVED: The current name is "EXT_transform_feedback", playing off the 977 fact that it is transformed primitives that are handled and the 978 similarities to GL feedback mode. 979 980 This extension is new version of the shipping NV_transform_feedback 981 extension with some capabilities removed to ease multi-vendor adoption. 982 See the "Interactions with NV_transform_feedback" section for more 983 information on the functional differences. 984 985 3. What happens if you bind a buffer for transform feedback that is 986 currently bound for other purposes? Should we somehow detect this case 987 and produce an error? 988 989 !!! NBC I feel strongly that we should follow the precedent for 990 Map/Unmap. The reason that MapBuffer and UnmapBuffer are a precedent 991 here is because while a buffer object is in the mapped state, no GL 992 commands are allowed to operate on the buffer object's data. So by 993 analogy, while a buffer is being used for transform feedback, no other 994 GL commands should be allowed to operate on the buffer object's data. 995 This includes initiating any rendering which would cause the GL to 996 source data from an active transform feedback buffer object. 997 998 UNRESOLVED 999 1000 4. Should this extension include any new buffer object binding targets, or 1001 should it overload ARRAY_BUFFER, or should we skip the binding target 1002 altogether in favor of a buffer object name accepted directly by the 1003 new GL commands? 1004 1005 RESOLVED: There are new binding points for XFB along with a new API 1006 (BindBufferBase etc) to set the internal binding points. A new binding 1007 point, TRANSFORM_FEEDBACK_BUFFER_EXT is also introduced. 1008 1009 5. Previous buffer object extensions provided a way to have existing GL 1010 commands reference a buffer object instead of a user-supplied buffer. 1011 Should the new commands introduced here allow referencing a 1012 user-supplied buffer in addition to a buffer object? 1013 1014 RESOLVED: No. A program can get the contents of the feedback buffer back 1015 to the CPU using MapBuffer and GetBufferSubData. 1016 1017 6. Is BeginTransformFeedback really necessary? Could the query just 1018 initiate the transform feedback mode? 1019 1020 RESOLUTION: Using BeginTransformFeedback and EndTransformFeedback gives 1021 a clean place to spec all of the transform-feedback-specific issues 1022 without cluttering up the query language. Also, the queries don't have 1023 to be done at the same time as beginning and ending the feedback 1024 process. 1025 1026 7. What usage enums should be provided to glBufferData for use in 1027 conjunction with transform feedback? 1028 1029 RESOLVED: STREAM_COPY or STREAM_READ are expected to be the most common 1030 usages. If a buffer object is being written by the GL through transform 1031 feedback, and the contents of the buffer object are subsequently being 1032 consumed by the GL (e.g. by being used as a vertex buffer object), then 1033 this is a *_COPY usage. If the buffer object is being written by the GL 1034 through transform feedback, but is being consumed by the application 1035 (e.g. being mapped for read), this is a *_READ usage. The temporal 1036 (STREAM, STATIC, or DYNAMIC) component of the usage enum is determined 1037 by the ratio between how often the contents of the buffer object are 1038 modified and how often operations that source data from the buffer 1039 object occur. 1040 1041 8. What should the behavior be when a buffer object is the active target 1042 of transform feedback, and it is deleted via DeleteBuffers? 1043 1044 RESOLVED: Deletion is deferred until the EndTransformFeedback if 1045 transform feedback is active. 1046 1047 9. Should we allow more buffers to be bound than are used? 1048 1049 RESOLVED: Yes. The extra buffers are not in the way and can stay bound. 1050 1051 10. Should we allow feedback to buffer lists with holes (i.e. 0 and 2 1052 bound)? 1053 1054 RESOLVED: No. This makes for an ugly API with the potential for bugs, 1055 without any real benefit. The application can as well bind all buffers 1056 needed to incremented indices. It is an invalid operation to not have a 1057 buffer bound where one is required. 1058 1059 11. Why only one feedback primitive mode per feedback invocation? 1060 1061 RESOLVED: Having primitive tokens breaks up the stream and makes it less 1062 amenable to being read back in as a vertex buffer. Also, mixing multiple 1063 primitive types makes the counting of primitives less clear for the 1064 application. 1065 1066 12. Is RasterPos fed back? 1067 1068 RESOLVED: No. 1069 1070 13. Is DrawPixels/CopyPixels/Bitmap fed back? 1071 1072 RESOLVED: No. Rasterization occurs as normal, but there is no 1073 output to the feedback buffer. This is consistent with taking a 1074 tap out of the pipe before clipping. 1075 1076 14. Why do we need new BindBuffer* functions? 1077 1078 RESOLVED: All previous buffer object extensions have been retrofits of 1079 existing pointer-based APIs. New extensions built assuming buffer 1080 objects don't have that history, so need a new API. The functionality of 1081 these new functions combines the functionality of BindBuffer, to set the 1082 external bind point used by calls like MapBuffer and BufferSubData, with 1083 the functionality to set an internal bind point like VertexAttribPointer 1084 does. 1085 1086 15. How do the transform feedback indices, passed to the BindBuffer* 1087 commands, work with multiple bindings? 1088 1089 RESOLVED: The same way that they work with vertex arrays. There is one 1090 external bind point, TRANSFORM_FEEDBACK_BUFFER_EXT. There are n 1091 internal bind points, selected with the <index> parameter to the 1092 BindBuffer* commands, where n is some implementation dependent limit. 1093 The BindBuffer* commands take the buffer passed and bind it to the 1094 external bind point, as well as to the selected internal bind point. 1095 1096 For example: 1097 1098 BindBufferOffsetEXT(TRANSFORM_FEEDBACK_BUFFER_EXT, 0, 1, 12); 1099 // XFB index 0 points at buffer 1 with offset 12 1100 1101 BindBuffer(TRANSFORM_FEEDBACK_BUFFER_EXT, 2); 1102 // Buffer 2 is now bound to the external bind point. XFB index 0 still 1103 // points at buffer 1 1104 1105 MapBuffer(TRANSFORM_FEEDBACK_BUFFER_EXT, ...); 1106 // Maps buffer 2 1107 1108 16. How are quads/quadstrips/polygons tesselated into triangles? 1109 1110 RESOLVED: In an implementation-dependent manner. OpenGL doesn't define 1111 quads or polygons in terms of triangles, so there is no one correct way 1112 to do it, and different gpus may implement the behavior differently. A 1113 quad may be split into two triangles in several different ways, and an 1114 application may not rely on this behavior. 1115 1116 17. How does this extension interact with display lists? 1117 1118 RESOLVED: Just like the VBO extension, none of the BindBuffer* commands 1119 are compiled into a display list. 1120 1121 18. Does polygon mode state affect the logic that determines if the 1122 transform feed back primitive mode and the render mode states are 1123 valid at the start of transform feedback mode? 1124 1125 RESOLVED: PolygonMode has no influence on the BeginTransFormFeedback 1126 primitiveMode check since it is performed later in the pipeline. 1127 1128 19. What to do with incomplete primitives? 1129 1130 RESOLVED: If there is no room to store one or more vertices of a 1131 primitive in a buffer object, none of the vertices in that primitive are 1132 written to the buffer. If a partial primitive enters transform feedback 1133 (i.e. only two vertices sent in triangles mode), none of the vertices in 1134 that primitive are written to the buffer object. 1135 1136 20. Why does TRANSFORM_FEEDBACK_PRIMITIVES_WRITTEN_EXT have a 1137 TRANSFORM_FEEDBACK prefix but PRIMITIVES_GENERATED_EXT doesn't? 1138 1139 RESOLVED: The number of primitives generated is independent of any 1140 feedback that is active. The number of primitives that are written is 1141 only valid for transform feedback - another extension could conceivably 1142 have a different way of writing out primitives that would require a 1143 similar but distinct token. 1144 1145 25. Are primitives sent down the pipeline after transform feedback, or 1146 discarded? 1147 1148 RESOLVED: Primitives can be optionally discarded before rasterization by 1149 calling Enable and Disable with RASTERIZER_DISCARD_EXT. When enabled, 1150 primitives are discarded after vertex attributes are recorded into the 1151 buffer objects bound to transform feedback. When disabled, primitives 1152 are passed through to the rasterization stage to be clipped and 1153 rasterized normally. All rasterization operations are discarded, not 1154 just those that are fed back into the buffer. 1155 1156 This applies to DrawPixels, CopyPixels, Bitmap, Clear, Accum as well. 1157 1158 26. If a varying is declared as an array, is the whole array streamed out? 1159 1160 RESOLVED: No, the application has to specify which elements of an array 1161 it wants to stream out. Implementations might not be able to stream out 1162 a large number of components to a single buffer object. If that is the 1163 case, the application can stream each element of an array to a different 1164 buffer object in TRANSFORM_FEEDBACK_SEPARATE_ATTRIBS mode. 1165 1166 27. Is it possible to capture attributes when using the fixed-function 1167 pipeline? 1168 1169 RESOLVED: Not in this extension, which requires the use of a GLSL 1170 vertex or geometry shader. The NV_transform_feedback extension does 1171 provide this capability. 1172 1173 28. Should we provide queries to determine the set of varying variables to 1174 be captured for a program object in transform feedback mode -- i.e., 1175 the values in the array of strings <varyings> given to 1176 TransformFeedbackVaryingsEXT? 1177 1178 RESOLVED: Yes; the command GetTransformFeedbackVaryingEXT is provided 1179 to query the name, size, and type of each varying captured for a linked 1180 program object in transform feedback mode. 1181 1182 Transform feedback-related queries operate only on a linked program 1183 object. There is no API available to query transform feedback varying 1184 state set by TransformFeedbackVaryingsEXT until a program is linked. 1185 1186 29. What happens if a variable is specified in the array of names passed 1187 to TransformFeedbackVaryingsEXT, but not needed by the fragment 1188 shader? The linker may normally eliminate such variables. 1189 1190 RESOLVED: Varying variables specified by TransformFeedbackVaryingsEXT 1191 are always considered active and count against the total limit on the 1192 number of active varying components, regardless of the needs of the 1193 fragment shader. If such a program object is executed with transform 1194 feedback active, the values of these variables are computed by the 1195 vertex or geometry shader and stored in the appropriate buffer object. 1196 If transform feedback is inactive, the values of such varyings may be 1197 calculated even though they are only needed for transform feedback. 1198 1199 1200Revision History 1201 1202 Rev. Date Author Changes 1203 ---- -------- -------- --------------------------------------------- 1204 8 08/09/13 pbrown Remove extra <varyings> parameter in 1205 TransformFeedbackVaryingsEXT. 1206 1207 7 07/01/13 Jon Leech Change type of TransformFeedbackVaryingsEXT 1208 parameter from 'const char **varyings' to 1209 'const char * const *varyings' (Bug 10231). 1210 1211 6 01/27/11 Jon Leech Change return value for start/size queries 1212 when no buffer bound from -1 to zero, to 1213 match state tables (Bug 7318). 1214 1215 5 02/28/08 pbrown Merged in edits from Apple. Update status to 1216 shipping. Moved per-object query results into 1217 a separate table. 1218 1219 4 02/20/08 pbrown Fix incorrect minimum for MAX_TRANSFORM_ 1220 FEEDBACK_SEPARATE_COMPONENTS_EXT. Should be 1221 4, not 16. 1222 1223 3 12/13/07 pbrown Clean up a number of places where "NV" 1224 suffixes were incorrectly carried over from 1225 the NV_transform_feedback spec. 1226 1227 2 08/28/07 pbrown Document that BeginTransformFeedbackEXT 1228 results in an error if no program object is 1229 active or if the active program isn't 1230 capturing any varyings. 1231 1232 1 11/30/06 pbrown Created an initial EXT_transform_feedback 1233 spec by forking off the existing 1234 NV_transform_feedback spec. 1235