| 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 |