1Name 2 3 AMD_vertex_shader_layer 4 5Name Strings 6 7 GL_AMD_vertex_shader_layer 8 9Contact 10 11 Graham Sellers, AMD (graham.sellers 'at' amd.com) 12 13Contributors 14 15 Graham Sellers 16 17Status 18 19 Shipping. 20 21Version 22 23 Last Modified Date: March 19, 2012 24 Revision: 3 25 26Number 27 28 417 29 30Dependencies 31 32 OpenGL 3.0 or EXT_texture_array is required. 33 34 OpenGL 3.2 and ARB_geometry_shader4 affect the definition of this 35 extension. 36 37 The extension is written against the OpenGL 4.2 Specification, Core Profile, 38 January 19, 2012 and the OpenGL Shading Language Specification, version 39 4.20.11. 40 41Overview 42 43 The gl_Layer built-in shading language variable was introduced with the 44 ARB_geometry_shader extension and subsequently promoted to core OpenGL 45 in version 3.2. This variable is an output from the geometry shader stage 46 that allows rendering to be directed to a specific layer of an array 47 texture, slice of a 3D texture or face of a cube map or cube map array 48 attachment of the framebuffer. Thus, this extremely useful functionality is 49 only available if a geometry shader is present - even if the geometry shader 50 is not otherwise required by the application. This adds overhead to the 51 graphics processing pipeline, and complexity to applications. It also 52 precludes implementations that cannot support geometry shaders from 53 supporting rendering to layered framebuffer attachments. 54 55 This extension exposes the gl_Layer built-in variable in the vertex shader, 56 allowing rendering to be directed to layered framebuffer attachments with 57 only a vertex and fragment shader present. Combined with features such 58 as instancing, or static vertex attributes and so on, this allows a wide 59 variety of techniques to be implemented without the requirement for a 60 geometry shader to be present. 61 62New Procedures and Functions 63 64 None. 65 66New Tokens 67 68 None. 69 70Additions to Chapter 2 of the OpenGL 4.2 (Core) Specification (OpenGL Operation) 71 72 Add the following paragraph to the "Shader Outputs" subsection of 73 section 2.11, "Vertex Shaders" on p. 112. 74 75 The built-in special variable gl_Layer, if written, holds the layer to 76 which rendering should be directed and is discussed in the next subsection. 77 78 Insert the following subsection after the "Shader Outputs" subsection on 79 p.112. 80 81 "Layered Rendering" 82 83 Vertex shaders can be used to render to one of several different layers 84 of cube map textures, three-dimensional textures, or one- or two-dimensional 85 texture arrays. This functionality allows an application to bind an entire 86 complex texture to a framebuffer object, and render primitives to arbitrary 87 layers computed at run time. For example, it can be used to project and 88 render a scene onto all six faces of a cube map texture in one pass. The 89 layer to render to is specified by writing to the built-in output variable 90 gl_Layer. Layered rendering requires the use of framebuffer objects 91 (see section 4.4.7). 92 93 Replace the first paragraph of the "Layer and Viewport Selection" subsection 94 of section 2.13, "Geometry Shaders", p.150 with: 95 96 The special built-in variable gl_Layer is available to geometry 97 shaders to direct rendering to a specific layer of a layered framebuffer 98 attachment and has the same effect as the similarly named variable in the 99 vertex shader. 100 101Additions to Chapter 3 of the OpenGL 4.2 (Core) Specification (Rasterization) 102 103 None. 104 105Additions to Chapter 4 of the OpenGL 4.2 (Core) Specification (Per-Fragment Operations 106and the Framebuffer) 107 108 Modify section 4.4.7, "Layered Framebuffers", p. 339: 109 110 Remove the first bullet point from the list on p. 339. 111 Modify the second bullet point to read: 112 113 * the current vertex or geometry shader (if present) does not statically 114 assign a value to the built-in output variable gl_Layer. 115 116 Modify the following paragraph to read: 117 118 Otherwise, the layer for each point, line or triangle generated by 119 primitive assembly, or emitted by the geometry shader (if present) is taken 120 from the gl_Layer output of one of the vertices of the primitive. The 121 vertex used is implementation-dependent. To obtain defined results, all 122 vertices of a single primitive (including strips, fans and loops) should 123 receive the same value for gl_Layer. When a geometry shader is present, 124 since the EndPrimitive built-in function starts a new output primitive, 125 defined results can be achieved if EndPrimitive is called between two 126 vertices emitted with different layer numbers. A layer number written by a 127 vertex or geometry shader has no effect if the framebuffer is not layered. 128 129Additions to Chapter 5 of the OpenGL 4.2 (Core) Specification (Special 130Functions) 131 132 None. 133 134Additions to Chapter 6 of the OpenGL 4.2 (Core) Specification (State and 135State Requests) 136 137 None. 138 139Additions to Chapter 7 of the OpenGL Shading Language Specification, Version 4.20 140 141 Add to the list of vertex shader built-in variables, Section 7.1, p.97: 142 143 out int gl_Layer; 144 145 Modify the first paragraph on p.100, describing gl_Layer as follows: 146 147 The output variable gl_Layer is available only in the vertex and 148 geometry languages, and is used to select ... See section 2.11.11, 149 "Shader Exection" (under "Shader Outputs") and section 4.4.7, "Layered 150 Framebuffers" in the OpenGL Graphics System for more information. 151 152 Add the following paragraph after the discussion of cube-map arrays on 153 p.101: 154 155 Should a vertex shader write to gl_Layer when a geometry shader is 156 present, this value will be discarded and the value written to gl_Layer 157 by the geometry shader (if any) will be used instead. If the geometry 158 shader does not write to gl_Layer, layer zero will be assumed. If 159 selection of layer by the vertex shader is desired in the presence of a 160 geometry shader, the layer should be communicated from the vertex shader 161 to the geometry shader via a user defined varying per-vertex and the 162 geometry shader used to copy the appropriate value to the gl_Layer output 163 variable. 164 165Additions to the AGL/GLX/WGL Specifications 166 167 None. 168 169GLX Protocol 170 171 None. 172 173Errors 174 175 None. 176 177New State 178 179 None. 180 181New Implementation Dependent State 182 183 None. 184 185Interaction with versions of OpenGL prior to 3.2 or with the absence of 186ARB_geometry_shader4 187 188 If geometry shaders are not supported, remove all references to geometry 189 shaders. gl_Layer is still introduced in the vertex shader. However, 190 layered framebuffer attachments were also introduced with geometry shaders, 191 and so this extension is of limited use. In order to expose this extension 192 on an implementation that does not support geometry shaders in a meaningful 193 way, it may be necessary to introduce an extension that adds layered 194 framebuffer attachments alone. 195 196Issues 197 198 1) What happens when there is a tessellation shader in the pipe? 199 200 RESOLVED: gl_Layer is not exposed to tessellation shaders. The primary 201 motivation for this extension is to allow simple applications using only 202 vertex and fragment shaders to take advantage of layered rendering. To use 203 vertex-shader specified layers in a program that uses tessellation, the 204 layer can be passed from vertex to control to evaluation shader and then 205 a geometry shader can be used to initialize gl_Layer as would be the case 206 in the absence of this extension. 207 208 2) Can we use the provoking vertex semantics to decide which layer will 209 be rendered to in case the vertices of a single primitive are emitted 210 with different layer index? 211 212 RESOLVED: Yes, the provoking vertex semantics, including 213 LAYER_PROVOKING_VERTEX remain in place. 214 215 3) Why we don't introduce layered framebuffers in this extension as we 216 did in ARB_geometry_shader4? 217 218 RESOLVED: The scope of changes required to introduce layered framebuffer 219 attachments, cube map attachments, 3D texture attachments and so on would 220 be quite large and serve little purpose, at least as far as AMD's 221 implementation of this extension is concerned. However, requiring 222 ARB_geometry_shader4 is not conducive to allowing support for this 223 extension in the absence of geometry shader support. Therefore, we decided 224 to expose only the layer functionality here and leave it to said 225 hypothetical implementation to define the behavior of layered attachments 226 as a separate extension. 227 228 4) What happens if the VS writes gl_Layer while there is a geometry shader 229 present? 230 231 RESOLVED: The value written by the VS is lost and the value written by 232 the GS (if any) is used. If the GS does not write gl_Layer then layer 233 zero is assumed. 234 235Revision History 236 237 Rev. Date Author Changes 238 ---- -------- -------- ----------------------------------------- 239 240 3 19/03/2012 gsellers Address final feedback. 241 2 15/03/2012 gsellers Ready for posting in repository. 242 1 04/05/2011 gsellers Initial draft 243