Name

    NV_viewport_swizzle

Name Strings

    GL_NV_viewport_swizzle

Contact

    Jeff Bolz, NVIDIA Corporation (jbolz 'at' nvidia.com)
    Pat Brown, NVIDIA Corporation (pbrown 'at' nvidia.com)

Contributors

    Mathias Heyer, NVIDIA

Status

    Shipping.

Version

    Last Modified Date:         April 7, 2015
    Revision:                   1

Number

    OpenGL Extension #483
    OpenGL ES Extension #258

Dependencies

    This extension is written against the OpenGL 4.3 specification
    (Compatibility Profile).

    This extension interacts with the OpenGL ES 3.1 (March 17, 2014)
    specification.

    This extension interacts with NV_viewport_array2.

Overview

    This extension provides a new per-viewport swizzle that can modify the
    position of primitives sent to each viewport.  New viewport swizzle state
    is added for each viewport, and a new position vector is computed for each
    vertex by selecting from and optionally negating any of the four
    components of the original position vector.

    This new viewport swizzle is useful for a number of algorithms, including
    single-pass cubemap rendering (broadcasting a primitive to multiple faces
    and reorienting the vertex position for each face) and voxel
    rasterization.  The per-viewport component remapping and negation provided
    by the swizzle allows application code to re-orient three-dimensional
    geometry with a view along any of the X, Y, or Z axes.  If a perspective
    projection and depth buffering is required, 1/W buffering should be used,
    as described in the single-pass cubemap rendering example in the "Issues"
    section below.

New Procedures and Functions

    void ViewportSwizzleNV(uint index,
                           enum swizzlex, enum swizzley,
                           enum swizzlez, enum swizzlew);

New Tokens

    Accepted by the <swizzlex>, <swizzley>, <swizzlez>, and <swizzlew>
    parameters of ViewportSwizzleNV:

        VIEWPORT_SWIZZLE_POSITIVE_X_NV                  0x9350
        VIEWPORT_SWIZZLE_NEGATIVE_X_NV                  0x9351
        VIEWPORT_SWIZZLE_POSITIVE_Y_NV                  0x9352
        VIEWPORT_SWIZZLE_NEGATIVE_Y_NV                  0x9353
        VIEWPORT_SWIZZLE_POSITIVE_Z_NV                  0x9354
        VIEWPORT_SWIZZLE_NEGATIVE_Z_NV                  0x9355
        VIEWPORT_SWIZZLE_POSITIVE_W_NV                  0x9356
        VIEWPORT_SWIZZLE_NEGATIVE_W_NV                  0x9357

    Accepted by the <pname> parameter of GetBooleani_v, GetDoublei_v,
    GetIntegeri_v, GetFloati_v, and GetInteger64i_v:

        VIEWPORT_SWIZZLE_X_NV                           0x9358
        VIEWPORT_SWIZZLE_Y_NV                           0x9359
        VIEWPORT_SWIZZLE_Z_NV                           0x935A
        VIEWPORT_SWIZZLE_W_NV                           0x935B

Additions to Chapter 13 of the OpenGL 4.3 (Compatibility Profile)
Specification (Fixed-Function Vertex Post-Processing)

    Modify Section 13.2 (Transform Feedback), p. 453

    Modify the first paragraph:

    ...The vertices are fed back after vertex color clamping, but before
    viewport swizzling and viewport mask expansion, flatshading, and
    clipping. ...


    Add a new Section 13.X (Viewport Swizzle) after 13.3 (Primitive Queries)

    Each primitive sent to a given viewport has a swizzle and optional
    negation applied to its clip coordinates.  The swizzle that is applied
    depends on the viewport index, and is controlled by the command

        void ViewportSwizzleNV(uint index,
                               enum swizzlex, enum swizzley,
                               enum swizzlez, enum swizzlew);

    The viewport specified by <index> has its x,y,z,w swizzle state set to the
    corresponding <swizzlex>, <swizzley>, <swizzlez>, <swizzlew> value. If the
    value of VIEWPORT_SWIZZLE_X_NV is denoted by <swizzlex>, swizzling computes
    the new x component of the position as

        if (swizzlex == VIEWPORT_SWIZZLE_POSITIVE_X_NV) x' = x;
        if (swizzlex == VIEWPORT_SWIZZLE_NEGATIVE_X_NV) x' = -x;
        if (swizzlex == VIEWPORT_SWIZZLE_POSITIVE_Y_NV) x' = y;
        if (swizzlex == VIEWPORT_SWIZZLE_NEGATIVE_Y_NV) x' = -y;
        if (swizzlex == VIEWPORT_SWIZZLE_POSITIVE_Z_NV) x' = z;
        if (swizzlex == VIEWPORT_SWIZZLE_NEGATIVE_Z_NV) x' = -z;
        if (swizzlex == VIEWPORT_SWIZZLE_POSITIVE_W_NV) x' = w;
        if (swizzlex == VIEWPORT_SWIZZLE_NEGATIVE_W_NV) x' = -w;

    Similar selections are performed for the y, z, and w coordinates. This
    swizzling is applied after transform feedback, but before clipping and
    perspective divide.

    Errors:

    - The error INVALID_VALUE is generated if <index> is greater than or equal
      to the value of MAX_VIEWPORTS.

    - The error INVALID_ENUM is generated if any of <swizzlex>, <swizzley>,
      <swizzlez>, or <swizzlew> are not one of
      VIEWPORT_SWIZZLE_{POSITIVE,NEGATIVE}_{X,Y,Z,W}.


    Modify Section 13.6.1 (Controlling the Viewport)

    (modify the first paragraph, p. 470, as edited by NV_viewport_array2,
    using "transformed and swizzled" instead of "transformed")

    Multiple viewports are available ... The primitive is transformed and
    swizzled using the state of the selected viewport. ...

    ... If bit <i> is set in the mask, the primitive is emitted to viewport
    <i> and transformed and swizzled using the state of viewport <i>. ...


New Implementation Dependent State

    None.

New State

    Get Value                       Get Command    Type    Initial Value        Description                 Sec.    Attribute
    ---------                       -----------    ----    -------------        -----------                 ----    ---------
    VIEWPORT_SWIZZLE_X_NV           GetIntegeri_v  nxZ8    VIEWPORT_SWIZZLE-    coordinate and sign for     13.X    viewport
                                                           POSITIVE_X           viewport swizzling
    VIEWPORT_SWIZZLE_Y_NV           GetIntegeri_v  nxZ8    VIEWPORT_SWIZZLE-    coordinate and sign for     13.X    viewport
                                                           POSITIVE_Y           viewport swizzling
    VIEWPORT_SWIZZLE_Z_NV           GetIntegeri_v  nxZ8    VIEWPORT_SWIZZLE-    coordinate and sign for     13.X    viewport
                                                           POSITIVE_Z           viewport swizzling
    VIEWPORT_SWIZZLE_W_NV           GetIntegeri_v  nxZ8    VIEWPORT_SWIZZLE-    coordinate and sign for     13.X    viewport
                                                           POSITIVE_W           viewport swizzling

Additions to the AGL/GLX/WGL Specifications

    None.

GLX Protocol

    None.

Errors

    The error INVALID_VALUE is generated by ViewportSwizzleNV if <index> is
    greater than or equal to the value of MAX_VIEWPORTS.

    The error INVALID_ENUM is generated by ViewportSwizzleNV if any of
    <swizzlex>, <swizzley>, <swizzlez>, or <swizzlew> are not one of
    VIEWPORT_SWIZZLE_{POSITIVE,NEGATIVE}_{X,Y,Z,W}.

Interactions with OpenGL ES 3.1

    Remove references to GetDoublei_v and GetBooleani_v.  Also remove the
    reference to 'vertex color clamping'.

Interactions with NV_viewport_array2

    This specification modifies language added/changed by NV_viewport_array2.
    There are no functional interactions between the two extensions, though we
    expect that all implementations of this extension will support
    NV_viewport_array2 or similar functionality.

Issues

    (1) Where does viewport swizzling occur in the pipeline?

    RESOLVED: Despite being associated with the viewport, viewport swizzling
    must happen prior to the viewport transform.  In particular, it needs to
    be performed before clipping and perspective division.

    The viewport mask expansion (NV_viewport_array2) and the viewport swizzle
    could potentially be performed before or after transform feedback, but
    feeding back several viewports worth of primitives with different swizzles
    doesn't seem particularly useful.  This specification applies the viewport
    mask and swizzle after transform feedback, and makes primitive queries
    only count each primitive once.

    (2) Any interesting examples of how this extension, NV_viewport_array2,
    and NV_geometry_shader_passthrough can be used together in practice?

    RESOLVED:  One interesting use case for this extension is for single-pass
    rendering to a cubemap.  In this example, the application would attach a
    cubemap texture to a layered FBO where the six cube faces are treated as
    layers.  Vertices are sent through the vertex shader without applying a
    projection matrix, where the gl_Position output is (x,y,z,1) and the
    center of the cubemap is at (0,0,0).  With unextended OpenGL, one could
    have a conventional instanced geometry shader that looks something like
    the following:

      layout(invocations = 6) in;     // separate invocation per face
      layout(triangles) in;
      layout(triangle_strip) out;
      layout(max_vertices = 3) out;

      in Inputs {
        vec2 texcoord;
        vec3 normal;
        vec4 baseColor;
      } v[];

      out Outputs {
        vec2 texcoord;
        vec3 normal;
        vec4 baseColor;
      };

      void main()
      {
        int face = gl_InvocationID;  // which face am I?

        // Project gl_Position for each vertex onto the cube map face.
        vec4 positions[3];
        for (int i = 0; i < 3; i++) {
          positions[i] = rotate(gl_in[i].gl_Position, face);
        }

        // If the primitive doesn't project onto this face, we're done.
        if (shouldCull(positions)) {
          return;
        }

        // Otherwise, emit a copy of the input primitive to the
        // appropriate face (using gl_Layer).
        for (int i = 0; i < 3; i++) {
          gl_Layer = face;
          gl_Position = positions[i];
          texcoord = v[i].texcoord;
          normal = v[i].normal;
          baseColor = v[i].baseColor;
          EmitVertex();
        }
      }

    With passthrough geometry shaders, this can be done using a much simpler
    shader:

      layout(triangles) in;
      layout(passthrough) in Inputs {
        vec2 texcoord;
        vec3 normal;
        vec4 baseColor;
      }
      layout(passthrough) in gl_PerVertex {
        vec4 gl_Position;
      } gl_in[];
      layout(viewport_relative) out int gl_Layer;

      void main()
      {
        // Figure out which faces the primitive projects onto and
        // generate a corresponding viewport mask.
        uint mask = 0;
        for (int i = 0; i < 6; i++) {
          if (!shouldCull(face)) {
            mask |= 1U << i;
          }
        }
        gl_ViewportMask = mask;
        gl_Layer = 0;
      }

    The application code is set up so that each of the six cube faces has a
    separate viewport (numbered 0..5).  Each face also has a separate swizzle,
    programmed via the ViewportSwizzleNV() command.  The viewport swizzle
    feature performs the coordinate transformation handled by the rotate()
    function in the original shader.  The "viewport_relative" layout qualifier
    says that the viewport number (0..5) is added to the base gl_Layer value
    of zero to determine which layer (cube face) the primitive should be sent
    to.

    Note that the use of the passed through input <normal> in this example
    suggests that the fragment shader in this example would perform an
    operation like per-fragment lighting.  The viewport swizzle would
    transform the position to be face-relative, but <normal> would remain in
    the original coordinate system.  It seems likely that the fragment shader
    in either version of the example would want to perform lighting in the
    original coordinate system.  It would likely do this by reconstructing the
    position of the fragment in the original coordinate system using
    gl_FragCoord, a constant or uniform holding the size of the cube face, and
    the input gl_ViewportIndex (or gl_Layer), which identifies the cube face.
    Since the value of <normal> is in the original coordinate system, it would
    not need to be modified as part of this coordinate transformation.

    Note that while the rotate() operation in the regular geometry shader
    above could include an arbitrary post-rotation projection matrix, the
    viewport swizzle does not support arbitrary math.  To get proper
    projection, 1/W buffering should be used.  To do this:

      (1) Program the viewport swizzles to move the pre-projection W eye
      coordinate (typically 1.0) into the Z coordinate of the swizzle output
      and the eye coordinate component used for depth into the W coordinate.
      For example, the viewport corresponding to the +Z face might use a
      swizzle of (+X, -Y, +W, +Z).  The Z normalized device coordinate
      computed after swizzling would then be z'/w' = 1/Z_eye.

      (2a) On NVIDIA implementations supporting floating-point depth buffers
      with values outside [0,1], prevent unwanted near plane clipping by
      enabling DEPTH_CLAMP.  Ensure that the depth clamp doesn't mess up depth
      testing by programming the depth range to very large values, such as
      glDepthRangedNV(-z, +z), where z == 2^127.  It should be possible to use
      IEEE infinity encodings also (0xFF800000 for -INF, 0x7F800000 for +INF).
      Even when near/far clipping is disabled, primitives extending behind the
      eye will still be clipped because one or more vertices will have a
      negative W coordinate and fail X/Y clipping tests.

      (2b) On other implementations, scale X, Y, and Z eye coordinates so that
      vertices on the near plane have a post-swizzle W coordinate of 1.0.  For
      example, if the near plane is at Z_eye = 1/256, scale X, Y, and Z by
      256.  Also, ideally, program the depth range transformation to be a NOP
      by using a clip control depth mode (OpenGL 4.5) of ZERO_TO_ONE.

      (3) Adjust depth testing to reflect the fact that 1/W values are large
      near the eye and small away from the eye.  Clear the depth buffer to
      zero (infinitely far away) and use a depth test of GREATER instead of
      LESS.

Revision History

    Revision 1
    - Internal revisions.