blob: 2c558a6aa0ec41fcab9b1f1d78343918674ad97f [file] [log] [blame]
Name Strings
Graham Sellers, AMD (graham.sellers 'at'
Graham Sellers
Last Modified Date: March 19, 2012
Revision: 3
OpenGL 3.0 or EXT_texture_array is required.
OpenGL 3.2 and ARB_geometry_shader4 affect the definition of this
The extension is written against the OpenGL 4.2 Specification, Core Profile,
January 19, 2012 and the OpenGL Shading Language Specification, version
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
New Tokens
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
"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)
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
Additions to Chapter 6 of the OpenGL 4.2 (Core) Specification (State and
State Requests)
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
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
Additions to the AGL/GLX/WGL Specifications
GLX Protocol
New State
New Implementation Dependent State
Interaction with versions of OpenGL prior to 3.2 or with the absence of
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.
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
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
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