1Name 2 3 AMD_transform_feedback4 4 5Name Strings 6 7 GL_AMD_transform_feedback4 8 9Contributors 10 11 Graham Sellers, AMD 12 Eric Zolnowski, AMD 13 14Contact 15 16 Graham Sellers (graham.sellers 'at' amd.com) 17 18Status 19 20 Shipping 21 22Version 23 24 Last Modified Date: 31/04/2014 25 Author Revision: 5 26 27Number 28 29 OpenGL Extension #450 30 31Dependencies 32 33 OpenGL 4.0 or ARB_transform_feedback3 is required. 34 35 This extension is written against the OpenGL Specification, Version 4.4 36 (Core Profile). 37 38 This extension is written against the OpenGL Shading Language (GLSL) 39 Specification, Version 4.40 40 41Overview 42 43 Transform feedback is a mechanism to record the output of the vertex, 44 tessellation evaluation or geometry shader into one or more buffers for 45 further processing, recursive rendering or read-back by the client. 46 ARB_transform_feedback3 (and OpenGL 4.0) extended the transform feedback 47 subsystem to allow multiple streams of primitive information to be 48 captured. However, it imposed a limitation that the primitive type for all 49 streams must be POINTS if more than one stream is to be captured. 50 AMD_transform_feedback3_lines_triangles relaxed that restriction to allow 51 lines or triangles to be captured, in the case where multiple streams are 52 to be processed. However, it still required that all streams share the same 53 primitive type. Additionally, with all current extensions to transform 54 feedback, only a single primitive stream may be rasterized. 55 56 This extension enhances transform feedback in two significant ways. First, 57 it allows multiple transform feedback streams to be captured, each with its 58 own, independent primitve type. Second, it allows any combination of streams 59 to be rasterized. As an example, this enables the geometry shader to take 60 a single stream of triangle geometry and emit filled triangles with a 61 wireframe outline and a point at each vertex, all in a single pass through 62 the input vertices. Combined with features such those provided by 63 ARB_viewport_array, layered rendering, shader subroutines and so on, an 64 application can render several views of its geoemtry, each with a 65 radically different style, all in a single pass. 66 67IP Status 68 69 None. 70 71New Procedures and Functions 72 73 None. 74 75New Tokens 76 77 Accepted by the <pname> parameter of Enablei, Disablei and IsEnabledi: 78 79 STREAM_RASTERIZATION_AMD 0x91A0 80 81Additions to Chapter 11 of the OpenGL 4.4 (Core Profile) Specification 82(Programmable Vertex Processing) 83 84 Modify subsection 11.3.4.3, "Geometry Shader Vertex Streams": 85 86 Replace the second to last paragraph of the subsection with: 87 88 The primitives emitted to all vertex streams are passed to the transform 89 feedback stage to be captured and written to buffer objects in the manner 90 specified by the transform feedback state. The primitives emitted to vertex 91 streams for which rasterization is enabled are then passed to subsequent 92 pipeline stages for clipping, rasterization, and subsequent fragment 93 processing. 94 95 Replace the last paragraph of the subsection with: 96 97 Geometry shaders that emit vertices to multiple vertex streams may 98 generate a different primitive type on each stream. Any combination of 99 streams may be rasterized (see Section 3.1). This allows a geometry shader 100 to transform a single input vertex stream into multiple primitives of 101 different types, all of which may be rasterized. 102 103Additions to Chapter 14 of the OpenGL 4.4 (Core Profile) Specification 104(Fixed-Function Primitive Assembly and Rasterization) 105 106 Modify Section 14.1 "Discarding Primitives Before Rasterization", p. 409: 107 108 Primitives sent to any vertex stream (see section 13.2) may be processed 109 further. When geometry shaders are disabled, all vertices are considered 110 to be emitted to stream zero. 111 Primitives can be optionally discarded before rasterization but after 112 the optional transform feedback stage (see section 13.2). All primitives 113 may be discarded by calling Enable with RASTERIZER_DISCARD. When enabled, 114 primitives emitted to any stream are discarded. When enabled, 115 RASTERIZER_DISCARD also causes the Clear and ClearBuffer* commands to be 116 ignored. When RASTERIZER_DISCARD is disabled, primitives emitted on streams 117 for which rasterization is enabled are passed through to the rasterization 118 stage to be processed normally. Rasterization for specific streams may be 119 enabled by calling Enablei (or disabled by calling Disablei) with the 120 constant STREAM_RASTERIZATION_AMD and the index of the selected stream. 121 Initially, rasterization is enabled for stream zero and is disabled for all 122 other streams. 123 If primitives are emitted on more than one stream for which 124 rasterization is enabled, the order of rasterization of primitives on 125 different streams is undefined. However, it is guaranteed that all 126 primitives emitted on a single stream are rasterized in the order in which 127 they are generated, and that all primitives generated by a single invocation 128 of a geometry shader are rasterized in stream order, starting with the 129 lowest numbered stream. 130 131Additions to Chapter 15 of the OpenGL 4.4 (Core Profile) Specification 132(Programmable Fragment Processing) 133 134 Modify Section 15.2, "Shader Execution" 135 136 Insert the following paragraph to subsection 15.2.2, "Shader Inputs", 137 after the paragraph describing gl_SamplePosition on p. 433: 138 139 The built-in read-only variable gl_StreamID contains the index of the 140 vertex stream from which the vertices forming the primitive currently being 141 rasterized were taken. User defined input varying variables belonging to 142 this stream have defined values, whilst all other user defined input 143 variables are undefined. When no geometry shader is active, gl_StreamID 144 is zero. When a geometry shader is active and writes to multiple output 145 vertex streams for which rasterization is enabled, gl_StreamID may range 146 from zero to the value of MAX_VERTEX_STREAMS - 1. 147 148Modifications to Chapter 4 of the OpenGL Shading Language Specification, 149Version 4.40 (Variables and Types) 150 151 Append to the end of Section 4.4.1 "Input Layout Qualifiers" 152 153 The identifier <stream> is used to specify that a fragment shader input 154 variable or block is associated with a particular vertex stream (numbered 155 beginning with zero). A default stream number may be declared at global 156 scope by qualifying interface qualifier out as in this example: 157 158 layout (stream = 1) in; 159 160 The stream number specified in such a declaration replaces any previous 161 default and applies to all subsequent block and variable declarations until 162 a new default is established. The initial default stream number is zero. 163 164 Each input block or non-block input variable is associated with a 165 vertex stream. If the block or variable is declared with the <stream> 166 identifier, it is associated with the specified stream; otherwise, it is 167 associated with the current default stream. A block member may be declared 168 with a stream identifier, but the specified stream must match the stream 169 associated with the containing block. One example: 170 171 layout (stream = 1) in; // default is now stream 1 172 out vec4 var1; // var1 belongs to default stream (1) 173 layout (stream = 2) in Block1 { // "Block1" belongs to stream 2 174 layout (stream = 2) vec4 var2; // redundant block member stream decl 175 layout (stream = 3) vec2 var3; // ILLEGAL (must match block stream) 176 vec3 var4; // belongs to stream 2 177 }; 178 layout (stream = 0) in; // default is now stream 0 179 in vec4 var5; // var5 belongs to default stream (0) 180 in Block2 { // "Block2" belongs to default stream (0) 181 vec4 var6; 182 }; 183 layout ( stream = 3) in vec4 var7; // var7 belongs to stream 3 184 185 Each fragment processed by the fragment shader receives its input 186 variables from a specific stream corresponding to the stream upon which the 187 source vertices were emitted in the geometry shader. Each invocation of 188 the fragment shader processes a fragment belonging to a primitive generated 189 from vertices emitted to a single stream. The index of the stream to which 190 these vertices belong is available in the built-in variable gl_StreamID 191 (see Section 7.1, "Built-in Language Variables"). Only those input variables 192 belonging to the current stream have defined values. Reading from a variable 193 belonging to any other stream may cause undefined behavior, including 194 program termination. 195 196Modifications to Chapter 7 of the OpenGL Shading Language Specification, 197Version 4.40 (Built-in Variables) 198 199 Add to the list of built-in variables in the fragment language, sec. 7.1, 200 p.122. 201 202 in int gl_StreamID; 203 204 Insert the following paragraph after the description of gl_SamplePosition 205 on p.122: 206 207 The input variable gl_StreamID indicates the vertex stream from which 208 vertices were taken to generate the primitive to which the current fragment 209 belongs. This information may be used to deduce which of the fragment 210 shader input variables contain defined values. Reading from input variables 211 belonging to a vertex stream other than that indicated by gl_StreamID 212 may produce undefined behavior, possibly including application termination. 213 214Modifications to Chapter 8 of the OpenGL Shading Language Specification, 215Version 4.40 (Built-in Functions) 216 217 Remove the final paragraph of section 8.15 "Geometry Shader Functions" on 218 p.180, which disallows shaders with multiple streams that are not all 219 set to POINTS primitive type. 220 221Additions to the AGL/GLX/WGL Specifications 222 223 None. 224 225GLX Protocol 226 227 None. 228 229Errors 230 231 INVALID_VALUE is generated by Enablei, Disablei and IsEnabledi if <target> 232 is STREAM_RASTERIZATION_AMD and <index> is greater than or equal to 233 MAX_VERTEX_STREAMS_AMD. 234 235New State 236 237 Append to table 23.9, Rasterization 238 239 +---------------------------------------------------+-----------+-------------------+---------------+-----------------------------------------------+-------+ 240 | | | Get | Initial | | | 241 | Get Value | Type | Command | Value | Description | Sec. | 242 +---------------------------------------------------+-----------+-------------------+---------------+-----------------------------------------------+-------+ 243 | STREAM_RASTERIZATION_AMD | nxB | GetBoolean | See 14.1 | Per stream rasterizer enable | 14.1 | 244 +---------------------------------------------------+-----------+-------------------+---------------+-----------------------------------------------+-------+ 245 246Issues 247 248 1) Why is rasterization order undefined? 249 250 DISCUSSION: Implementations typically break large draws into chunks and 251 process each separately. Within each chunk, the rasterization order is 252 guaranteed. Between chunks, ordering is also guaranteed - everything in 253 early chunks is rasterized before later chunks. However, this means 254 that primitives emitted to higher numbered streams in early chunks will 255 be rasterized before primitives emitted to lower numbered streams in 256 later chunks. Because the boundaries between chunks are not necessarily 257 in fixed positions, it is not possible to specify where they will be and 258 therefore guarantee rasterization order. 259 260 2) Is this still useful then? 261 262 RESOLVED: Yes, sure. If rendering is order independent (depth test on, 263 blending off for example), or can be guaranteed to not overlap (viewport 264 arrays, layered rendering and so on), it makes no difference whether 265 rasterization order between streams is guaranteed or not. 266 267 3) What's the need for multiple 'streams' in the fragment shader? 268 269 DISCUSSION: In unextended OpenGL, the inputs to the fragment shader are 270 derived from the vertices generated on stream 0 in the geometry shader 271 (the vertex shader always writes to stream 0). When multiple streams can 272 be rasterized, the fragment shader can be invoked as part of a primitive 273 on any stream. As each stream can have wildly different outputs in the 274 geometry shader, it is really not possible to have only a single set 275 of inputs in the fragment shader. Therefore, we expose each stream 276 independently. Only those variables written by the geometry shader on the 277 stream from which the current primitive was generated will be defined, 278 and the others will likely have garbage in them (aliases of the real 279 variables). That stream is given by the new gl_StreamID built-in in the 280 fragment shader. Other built-in variables (such as gl_FragCoord) are 281 always available on any stream. 282 283Revision History 284 285 Rev. Date Author Changes 286 ---- ---------- -------- ----------------------------------------- 287 5 31/04/2014 gsellers Update for OpenGL 4.4, ready for posting. 288 4 12/03/2012 gsellers Update against OpenGL 4.3. 289 3 05/01/2011 gsellers Assign enumerants 290 2 10/14/2010 gsellers Add fragment shader streams. 291 1 10/11/2010 gsellers Initial revision 292