blob: 4b18cd6bc3a8673174223bb8acedc21b020010c8 [file] [log] [blame]
Name Strings
Cass Everitt, Oculus (cass.everitt 'at'
John Carmack, Oculus
Tom Forsyth, Oculus
Maurice Ribble, Qualcomm
James Dolan, NVIDIA Corporation
Mark Kilgard, NVIDIA Corporation
Michael Songy, NVIDIA Corporation
Yury Uralsky, NVIDIA Corporation
Jesse Hall, Google
Timothy Lottes, Epic
Jan-Harald Fredriksen, ARM
Jonas Gustavsson, Sony Mobile
Sam Holmes, Qualcomm
Nigel Williams, Qualcomm
Last Modified Date: July 1, 2016
Author Revision: 0.6
OpenGL Extension #478
OpenGL ES Extension #241
OpenGL 3.0 or OpenGL ES 3.0 is required.
The method of stereo rendering supported in OpenGL is currently achieved by
rendering to the two eye buffers sequentially. This typically incurs double
the application and driver overhead, despite the fact that the command
streams and render states are almost identical.
This extension seeks to address the inefficiency of sequential multiview
rendering by adding a means to render to multiple elements of a 2D texture
array simultaneously. In multiview rendering, draw calls are instanced into
each corresponding element of the texture array. The vertex program uses a
new ViewID variable to compute per-view values, typically the vertex
position and view-dependent variables like reflection.
The formulation of this extension is high level in order to allow
implementation freedom. On existing hardware, applications and drivers can
realize the benefits of a single scene traversal, even if all GPU work is
fully duplicated per-view. But future support could enable simultaneous
rendering via multi-GPU, tile-based architectures could sort geometry into
tiles for multiple views in a single pass, and the implementation could even
choose to interleave at the fragment level for better texture cache
utilization and more coherent fragment shader branching.
The most obvious use case in this model is to support two simultaneous
views: one view for each eye. However, we also anticipate a usage where two
views are rendered per eye, where one has a wide field of view and the other
has a narrow one. The nature of wide field of view planar projection is
that the sample density can become unacceptably low in the view direction.
By rendering two inset eye views per eye, we can get the required sample
density in the center of projection without wasting samples, memory, and
time by oversampling in the periphery.
New Tokens
Accepted by the <pname> parameter of GetFramebufferAttachmentParameteriv:
Accepted by the <pname> parameter of GetIntegerv:
Returned by CheckFramebufferStatus:
New Procedures and Functions
void FramebufferTextureMultiviewOVR( enum target, enum attachment, uint texture, int level, int baseViewIndex, sizei numViews );
Additions to Chapter X of the OpenGL 3.0 Specification
Additions to Chapter 4 of the OpenGL ES 3.0 Specification
The command
FramebufferTextureMultiviewOVR( enum target, enum attachment, uint texture, int level, int baseViewIndex, sizei numViews );
operates similarly to FramebufferTextureLayer, except that baseViewIndex and
numViews selects a range of texture array elements that will be targeted
when rendering.
The command
View( uint id );
does not exist in the GL, but is used here to describe the multi-view
functionality in this section. The effect of this hypothetical function is
to set the value of the shader built-in input uint gl_ViewID_OVR.
When multi-view rendering is enabled, drawing commands have the same effect
for( int i = 0; i < numViews; i++ ) {
FramebufferTextureLayer( target, attachment, texture, level, baseViewIndex + i );
View( i );
The result is that every drawing command is broadcast into every active
view. The shader uses gl_ViewID_OVR to compute view dependent outputs.
The number of views, as specified by numViews, must be the same for all
framebuffer attachments points where the value of FRAMEBUFFER_ATTACHMENT_-
OBJECT_TYPE is not NONE or the framebuffer is incomplete. The following is
added to the conditions for Whole Framebuffer Completeness:
The number of views is the same for all populated attachments.
In this mode there are several restrictions:
- in vertex shader gl_Position is the only output that can depend on
- no transform feedback
- no tessellation control or evaluation shaders
- no geometry shader
- no timer query
- occlusion query results must be between max and sum of per-view
queries, inclusive
Modifications to The OpenGL ES Shading Language Specification, Version 3.00.04
Including the following line in a shader can be used to control the
language features described in this extension:
#extension GL_OVR_multiview
In section "Input Layout Qualifiers":
Insert a paragraph before the final one ("Fragment shaders cannot ..."):
Vertex shaders also allow the following layout qualifier on "in" only
(not with variable declarations)
num_views = integer-constant
to indicate that the shader will only be used with the given number of
views, as described in section 4.4 ("Framebuffer Objects") of the OpenGL ES
Specification. If this qualifier is not declared, the behavior is as if it
had been set to 1.
INVALID_FRAMEBUFFER_OPERATION is generated by commands that read from the
framebuffer such as BlitFramebuffer, ReadPixels, CopyTexImage*, and
CopyTexSubImage*, if the number of views in the current read framebuffer
is greater than 1.
INVALID_VALUE is generated by FramebufferTextureMultiviewOVR if numViews is
less than 1, if numViews is more than MAX_VIEWS_OVR or if (baseViewIndex +
INVALID_OPERATION is generated if a rendering command is issued and the the
number of views in the current draw framebuffer is not equal to the number
of views declared in the currently bound program.
(1) Should geometry shaders be allowed in multiview mode?
Resolved: Not in this extension. By disallowing it, we hope to enable more
implementations to be available sooner, and there are complex issues that
arise when a GS is used to target gl_Layer explicitly.
(2) Should there be separate scissor and viewport per view?
Resolved: No, while there might be some uses for such support, it adds
unnecessary implementation complexity. In the case of inset rendering, there
will be a need to adjust the scissor per view. We will defer that issue for
now by forcing all views to use the same scissor and viewport.
(3) Why not just use geometry shaders?
Resolved: GS could be used to achieve stereo rendering by broadcasting each
primitive to each view. The problem with this approach is that it requires
the GS's very general mechanism with known performance implications to solve
a problem that does not require that solution and perhaps more frequently
than not, will not be the most efficient means of implementation.
(4) Why use texture arrays instead of separate FBOs?
Resolved: Use of arrays does imply that we use a minimum version of GL and
ES 3.0. On the other hand, it has some nice simplifying properties. In
particular, the format and resolution of each view is known to be the same
and only one FBO is bound, just like with normal rendering. It has some
potentially limiting interactions with GS use, but on the whole, the
implementation simplifications are considered worth the implied limitations.
(5) How does this extension interact with occlusion queries, timer queries,
Resolved: The bias will be toward relaxed rules to allow implementation
freedom. For example, occlusion queries should not return fewer than the max
samples returned from any view, but returning the sum may also be fine.
Simply reporting the result from view 0 is not sufficient.
(6) Is ViewID visible at every pipeline stage?
Resolved: To make integration simple for app developers, the intent is for
ViewID to be visible as a built-in at each programmable pipeline stage.
(7) Are view-dependent parameters exposed explicitly?
Resolved: No. This is implicit in the dependence of a parameter on ViewID.
In this extension, however, only gl_Position is allowed to depend on ViewID
in the vertex shader. If a shader violates this restriction it results in
undefined behavior or may produce an error. Later extensions may relax that
(8) Should the parameters that affect view-dependent position be driver
visible or otherwise restricted?
Resolved: No. Letting the app index via ViewID makes it a lot harder for the
driver to know much about the details of the transform inputs that result in
view-dependent outputs, but no such support exists in the API today either.
Adding that support would be complex, and thus not in the spirit of an
extension that can be implemented broadly with low risk.
(9) Should there be a per-view UBO instead of exposing ViewID in the shader?
Resolved: No. Exposing the ViewID variable is the smallest change. It does
imply dynamic branching, predication, or indexing based on the view id,
however, implementations could compile separate versions of the shader with
view id translated to literals if that would improve performance. Extra API
and machinery would be required to sequence one or more UBOs to different
objects per view.
(10) Should there be DSA style entry points?
Resolved: Almost certainly in GL 4.5 and beyond. Less clear that it should
be required for ES 3.0.
(11) Should tessellation shaders be allowed in multiview mode?
Resolved: Not in this extension. By disallowing it, we hope to enable more
implementations to be available sooner.
(12) Does the number of views need to be declared in the shader?
Resolved: Yes. This enables the implementation to specialize the compilation
for the declared number of views, for example by loop-unrolling. It could
also serves as a notification that the shader outputs must be 'broadcast' to
a set of views - even in cases where the shader does not reference from
(13) What should happen if the number of views declared in the shader does
not match num_views?
Resolved: Such a mismatch can only be detected at draw call time, so it
would have to either generate a draw call time error, or just result in
undefined results for any view > num_views. To avoid undefined results, the
draw call time error is preferred.
(14) How should read operations on FBOs with multiview texture attachments be
Resolved: Generating INVALID_OPERATION when the target is GL_READ_FRAMEBUFFER
for FramebufferTextureMultiviewOVR to disallow attaching a multiview texture
to the current read framebuffer is not sufficient to prevent a read operation
on a FBO with a multiview texture attachment. The multiview texture may still
be attached to the current write framebuffer and then bound as the read
framebuffer. Instead, an INVALID_FRAMEBUFFER_OPERATION error should be
generated for any read operations that occur whenever a multiview texture is
attached to the current read framebuffer. The multiview texture needs to be
instead attached as a 2D texture array with the level explicitly specified to
be read. This conforms to the expected behavior for read operations on FBOs
with multiview texture attachments to be consistent with
Revision History
Rev. Date Author Changes
---- -------- -------- -----------------------------------------
0.1 10/17/14 cass Initial draft
0.2 11/10/14 cass Changes to use texture array instead of separate FBOs
0.3 02/05/15 cass Only gl_Position can be view dependent in the vertex shader.
0.4 02/11/15 cass Switch to view instead of layer, as these are distinct now
0.5 04/15/15 cass Clean up pass before publishing
0.6 07/01/16 nigelw Modify errors to conform to multisample multiview spec changes