extensions/AMD/AMD_vertex_shader_layer.txt

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