Name AMD_vertex_shader_layer Name Strings GL_AMD_vertex_shader_layer Contact Graham Sellers, AMD (graham.sellers 'at' amd.com) Contributors Graham Sellers Status Shipping. Version Last Modified Date: March 19, 2012 Revision: 3 Number 417 Dependencies OpenGL 3.0 or EXT_texture_array is required. OpenGL 3.2 and ARB_geometry_shader4 affect the definition of this extension. The extension is written against the OpenGL 4.2 Specification, Core Profile, January 19, 2012 and the OpenGL Shading Language Specification, version 4.20.11. Overview The gl_Layer built-in shading language variable was introduced with the ARB_geometry_shader extension and subsequently promoted to core OpenGL in version 3.2. This variable is an output from the geometry shader stage that allows rendering to be directed to a specific layer of an array texture, slice of a 3D texture or face of a cube map or cube map array attachment of the framebuffer. Thus, this extremely useful functionality is only available if a geometry shader is present - even if the geometry shader is not otherwise required by the application. This adds overhead to the graphics processing pipeline, and complexity to applications. It also precludes implementations that cannot support geometry shaders from supporting rendering to layered framebuffer attachments. This extension exposes the gl_Layer built-in variable in the vertex shader, allowing rendering to be directed to layered framebuffer attachments with only a vertex and fragment shader present. Combined with features such as instancing, or static vertex attributes and so on, this allows a wide variety of techniques to be implemented without the requirement for a geometry shader to be present. New Procedures and Functions None. New Tokens None. Additions to Chapter 2 of the OpenGL 4.2 (Core) Specification (OpenGL Operation) Add the following paragraph to the "Shader Outputs" subsection of section 2.11, "Vertex Shaders" on p. 112. The built-in special variable gl_Layer, if written, holds the layer to which rendering should be directed and is discussed in the next subsection. Insert the following subsection after the "Shader Outputs" subsection on p.112. "Layered Rendering" Vertex shaders can be used to render to one of several different layers of cube map textures, three-dimensional textures, or one- or two-dimensional texture arrays. This functionality allows an application to bind an entire complex texture to a framebuffer object, and render primitives to arbitrary layers computed at run time. For example, it can be used to project and render a scene onto all six faces of a cube map texture in one pass. The layer to render to is specified by writing to the built-in output variable gl_Layer. Layered rendering requires the use of framebuffer objects (see section 4.4.7). Replace the first paragraph of the "Layer and Viewport Selection" subsection of section 2.13, "Geometry Shaders", p.150 with: The special built-in variable gl_Layer is available to geometry shaders to direct rendering to a specific layer of a layered framebuffer attachment and has the same effect as the similarly named variable in the vertex shader. Additions to Chapter 3 of the OpenGL 4.2 (Core) Specification (Rasterization) None. Additions to Chapter 4 of the OpenGL 4.2 (Core) Specification (Per-Fragment Operations and the Framebuffer) Modify section 4.4.7, "Layered Framebuffers", p. 339: Remove the first bullet point from the list on p. 339. Modify the second bullet point to read: * the current vertex or geometry shader (if present) does not statically assign a value to the built-in output variable gl_Layer. Modify the following paragraph to read: Otherwise, the layer for each point, line or triangle generated by primitive assembly, or emitted by the geometry shader (if present) is taken from the gl_Layer output of one of the vertices of the primitive. The vertex used is implementation-dependent. To obtain defined results, all vertices of a single primitive (including strips, fans and loops) should receive the same value for gl_Layer. When a geometry shader is present, since the EndPrimitive built-in function starts a new output primitive, defined results can be achieved if EndPrimitive is called between two vertices emitted with different layer numbers. A layer number written by a vertex or geometry shader has no effect if the framebuffer is not layered. Additions to Chapter 5 of the OpenGL 4.2 (Core) Specification (Special Functions) None. Additions to Chapter 6 of the OpenGL 4.2 (Core) Specification (State and State Requests) None. Additions to Chapter 7 of the OpenGL Shading Language Specification, Version 4.20 Add to the list of vertex shader built-in variables, Section 7.1, p.97: out int gl_Layer; Modify the first paragraph on p.100, describing gl_Layer as follows: The output variable gl_Layer is available only in the vertex and geometry languages, and is used to select ... See section 2.11.11, "Shader Exection" (under "Shader Outputs") and section 4.4.7, "Layered Framebuffers" in the OpenGL Graphics System for more information. Add the following paragraph after the discussion of cube-map arrays on p.101: Should a vertex shader write to gl_Layer when a geometry shader is present, this value will be discarded and the value written to gl_Layer by the geometry shader (if any) will be used instead. If the geometry shader does not write to gl_Layer, layer zero will be assumed. If selection of layer by the vertex shader is desired in the presence of a geometry shader, the layer should be communicated from the vertex shader to the geometry shader via a user defined varying per-vertex and the geometry shader used to copy the appropriate value to the gl_Layer output variable. Additions to the AGL/GLX/WGL Specifications None. GLX Protocol None. Errors None. New State None. New Implementation Dependent State None. Interaction with versions of OpenGL prior to 3.2 or with the absence of ARB_geometry_shader4 If geometry shaders are not supported, remove all references to geometry shaders. gl_Layer is still introduced in the vertex shader. However, layered framebuffer attachments were also introduced with geometry shaders, and so this extension is of limited use. In order to expose this extension on an implementation that does not support geometry shaders in a meaningful way, it may be necessary to introduce an extension that adds layered framebuffer attachments alone. Issues 1) What happens when there is a tessellation shader in the pipe? RESOLVED: gl_Layer is not exposed to tessellation shaders. The primary motivation for this extension is to allow simple applications using only vertex and fragment shaders to take advantage of layered rendering. To use vertex-shader specified layers in a program that uses tessellation, the layer can be passed from vertex to control to evaluation shader and then a geometry shader can be used to initialize gl_Layer as would be the case in the absence of this extension. 2) Can we use the provoking vertex semantics to decide which layer will be rendered to in case the vertices of a single primitive are emitted with different layer index? RESOLVED: Yes, the provoking vertex semantics, including LAYER_PROVOKING_VERTEX remain in place. 3) Why we don't introduce layered framebuffers in this extension as we did in ARB_geometry_shader4? RESOLVED: The scope of changes required to introduce layered framebuffer attachments, cube map attachments, 3D texture attachments and so on would be quite large and serve little purpose, at least as far as AMD's implementation of this extension is concerned. However, requiring ARB_geometry_shader4 is not conducive to allowing support for this extension in the absence of geometry shader support. Therefore, we decided to expose only the layer functionality here and leave it to said hypothetical implementation to define the behavior of layered attachments as a separate extension. 4) What happens if the VS writes gl_Layer while there is a geometry shader present? RESOLVED: The value written by the VS is lost and the value written by the GS (if any) is used. If the GS does not write gl_Layer then layer zero is assumed. Revision History Rev. Date Author Changes ---- -------- -------- ----------------------------------------- 3 19/03/2012 gsellers Address final feedback. 2 15/03/2012 gsellers Ready for posting in repository. 1 04/05/2011 gsellers Initial draft