| Name |
| |
| OVR_multiview |
| |
| Name Strings |
| |
| GL_OVR_multiview |
| |
| Contact |
| |
| Cass Everitt, Oculus (cass.everitt 'at' oculus.com) |
| |
| Contributors |
| |
| 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 |
| Tobias Hector, Imagination Technologies |
| Daniel Koch, NVIDIA Corporation |
| James Helferty, NVIDIA Corporation |
| Olli Etuaho, NVIDIA Corporation |
| |
| Status |
| |
| Complete. |
| |
| Version |
| |
| Last Modified Date: October 19, 2018 |
| Revision: 6 |
| |
| Number |
| |
| OpenGL Extension #478 |
| OpenGL ES Extension #241 |
| |
| Dependencies |
| |
| OpenGL 3.0 or OpenGL ES 3.0 is required. |
| |
| This extension is written against the OpenGL ES 3.2 (November 3, 2016) |
| specification and the OpenGL 4.6 (Core Profile) (July 30, 2017) |
| |
| This extension is written against the OpenGL ES Shading Language 3.00.04 |
| specification. |
| |
| This extension interacts with OpenGL 3.3, ARB_timer_query, and |
| EXT_disjoint_timer_query. |
| |
| This extension interacts with OpenGL 4.5, ARB_direct_state_access and |
| EXT_direct_state_access. |
| |
| This extension interacts with OpenGL ES 3.2, OpenGL 4.0, |
| EXT_tessellation_shader, OES_tessellation_shader, and |
| ARB_tessellation_shader. |
| |
| This extension interacts with OpenGL ES 3.2, OpenGL 3.2, |
| EXT_geometry_shader, OES_geometry_shader and ARB_geometry_shader4 |
| |
| This extension interacts with OpenGL 4.3, ARB_multi_draw_indirect, and |
| EXT_multi_draw_indirect. |
| |
| This extension interacts with OpenGL 3.0, the OpenGL 3.0 Compatibility |
| Profile, and ARB_fragment_layer_viewport. |
| |
| Overview |
| |
| 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 gl_ViewID_OVR 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: |
| |
| FRAMEBUFFER_ATTACHMENT_TEXTURE_NUM_VIEWS_OVR 0x9630 |
| FRAMEBUFFER_ATTACHMENT_TEXTURE_BASE_VIEW_INDEX_OVR 0x9632 |
| |
| Accepted by the <pname> parameter of GetIntegerv: |
| |
| MAX_VIEWS_OVR 0x9631 |
| |
| Returned by CheckFramebufferStatus: |
| |
| FRAMEBUFFER_INCOMPLETE_VIEW_TARGETS_OVR 0x9633 |
| |
| |
| New Procedures and Functions |
| |
| void FramebufferTextureMultiviewOVR( enum target, enum attachment, |
| uint texture, int level, |
| int baseViewIndex, sizei numViews ); |
| |
| [[ If OpenGL 4.5 or ARB_direct_state_access is supported ]] |
| |
| void NamedFramebufferTextureMultiviewOVR( uint framebuffer, enum attachment, |
| uint texture, int level, |
| int baseViewIndex, sizei numViews ); |
| |
| |
| Modifications to Chapter 4 of the OpenGL 4.6 Specification (Event Model) |
| |
| Modify section 4.3 (Time Queries) adding the following to the list |
| of errors: |
| |
| "Queries where BeginQuery or EndQuery is called with a target of |
| TIME_ELAPSED, or a if QueryCounter is called with a target of TIMESTAMP |
| return undefined values if the draw framebuffer is multiview at any |
| point during their execution." |
| |
| Modifications to Chapter 9 of the OpenGL ES 3.2 Specification (Framebuffers |
| and Framebuffer Objects) |
| |
| Add a new subsection to section 9.2.2 (Attaching Images to Framebuffer |
| Objects): |
| |
| "9.2.2.2 (Multiview Images) |
| |
| Finally, multiple layers of two-dimensional array textures can be |
| attached to an attachment point. Such attachments represent multiple |
| views, and the corresponding attachment point is considered to be |
| _multiview_. |
| |
| In this mode there are several restrictions: |
| |
| - in vertex shader gl_Position is the only output that can depend on |
| gl_ViewID_OVR (see Section 7.1 of the OpenGL ES Shading Language |
| specification) |
| - no transform feedback (section 11.1.3.11)) |
| - no tessellation control or evaluation shaders (section 11.1.3.11) |
| - no geometry shader (section 11.1.3.11) |
| - no timer queries (section 4.3) |
| - occlusion query results must be between max per-view and the sum |
| of the per-view queries, inclusive (section 15.1.4)." |
| - in fragment shader the contents of gl_Layer are undefined |
| |
| [[ If implemented in OpenGL ]] |
| - the number of views rendered to by Begin/End is an undefined subset |
| of the views present in the framebuffer |
| |
| Add the following to list of <pname> parameters which can be queried |
| via GetFramebufferAttachmentParameteriv when the value of |
| FRAMEBUFFER_ATTACHMENT_OBJECT_TYPE is TEXTURE in section 9.2.3 |
| (Framebuffer Object Queries): |
| |
| "If <pname> is FRAMEBUFFER_ATTACHMENT_TEXTURE_NUM_VIEWS_OVR and the value |
| of FRAMEBUFFER_ATTACHMENT_OBJECT_NAME is a two-dimensional array texture, |
| then <params> will contain the number of views that were specified for the |
| attachment point via FramebufferTextureMultiviewOVR. Otherwise, <params> |
| will contain zero. |
| |
| "If <pname> is FRAMEBUFFER_ATTACHMENT_TEXTURE_BASE_VIEW_INDEX_OVR and the |
| value of FRAMEBUFFER_ATTACHMENT_OBJECT_NAME is a two-dimensional array |
| texture, then <params> will contain the base view index that was specified |
| for the attachment point via FramebufferTextureMultiviewOVR. Otherwise, |
| <params> will contain zero." |
| |
| Add the following to the end of section 9.2.8 (Attaching Textures to a |
| Framebuffer), immediately before the subsection "Effects of Attaching a |
| Texture Image": |
| |
| "Multiple layers of a two-dimensional array texture can be |
| attached as one of the logical buffers of a framebuffer object with the |
| commands |
| |
| void FramebufferTextureMultiviewOVR( enum target, enum attachment, |
| uint texture, int level, |
| int baseViewIndex, sizei numViews ); |
| |
| [[ If OpenGL 4.5 or ARB_direct_state_access is supported ]] |
| |
| void NamedFramebufferTextureMultiviewOVR( uint framebuffer, enum attachment, |
| uint texture, int level, |
| int baseViewIndex, sizei numViews ); |
| |
| These commands operate similarly to the FramebufferTextureLayer and |
| NamedFramebufferTexture commands, except that <baseViewIndex> |
| and <numViews> select a range of texture array elements that will be |
| targeted when rendering. Such an attachment is considered _multiview_ |
| (section 9.2.2.2) and rendering commands issued when such a framebuffer |
| object is bound are termed "multiview rendering". The maximum number |
| of views which can be bound simultaneously is determined by the value |
| of MAX_VIEWS_OVR, which can be queried with the GetIntegerv command. |
| |
| The command |
| |
| View( uint id ); |
| |
| does not exist in the GL, but is used here to describe the multiview |
| functionality in this section. The effect of this hypothetical function |
| is to set the value of the shader built-in input gl_ViewID_OVR. |
| |
| When multiview rendering is enabled, the Clear (section 15.2.3), |
| ClearBuffer* (section 15.2.3.1), and Draw* (section 10.5) |
| commands have the same effect as: |
| |
| for( int i = 0; i < numViews; i++ ) { |
| for ( enum attachment : all attachment values where multiple texture array elements have been targeted for rendering ) { |
| FramebufferTextureLayer( target, attachment, texture, level, baseViewIndex + i ); |
| } |
| View( i ); |
| <command> |
| } |
| |
| The result is that every such 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 (section 9.4.2). |
| |
| If <texture> is non-zero and the command does not result in an error, the |
| framebuffer attachment state corresponding to <attachment> is updated as |
| in the FramebufferTextureLayer command, except that the values of |
| FRAMEBUFFER_ATTACHMENT_TEXTURE_LAYER and |
| FRAMEBUFFER_ATTACHMENT_TEXTURE_BASE_VIEW_INDEX_OVR are is set to |
| <baseViewIndex>, and the value of |
| FRAMEBUFFER_ATTACHMENT_TEXTURE_NUM_VIEWS_OVR is set to <numViews>. |
| |
| Errors |
| |
| In addition to the corresponding errors for FramebufferTextureLayer when |
| called with the same parameters (other than <layer>): |
| |
| An INVALID_VALUE error is generated if: |
| - <numViews> is less than 1 or if <numViews> is greater than MAX_VIEWS_OVR. |
| - <texture> is a two-dimensional array texture and <baseViewIndex> + |
| <numViews> is larger than the value of MAX_ARRAY_TEXTURE_LAYERS. |
| - texture is non-zero and <baseViewIndex> is negative." |
| |
| An INVALID_OPERATION error is generated if texture is non-zero and is not |
| the name of a two-dimensional array texture." |
| |
| Add the following to the list of conditions required for framebuffer |
| attachment completeness in section 9.4.1 (Framebuffer Attachment |
| Completeness): |
| |
| "If <image> is a two-dimensional array and the attachment |
| is multiview, all the selected layers, [<baseViewIndex>, |
| <baseViewIndex> + <numViews>), are less than the layer count of the |
| texture." |
| |
| Add the following to the list of conditions required for framebuffer |
| completeness in section 9.4.2 (Whole Framebuffer Completeness): |
| |
| "The number of views is the same for all populated attachments. |
| |
| { FRAMEBUFFER_INCOMPLETE_VIEW_TARGETS_OVR }" |
| |
| Modifications to Chapter 11 of the OpenGL ES 3.2 Specification (Programmable |
| Vertex Processing |
| |
| Modify section 11.1.3.11 (Validation) adding the following conditions |
| to the list of reasons that may result in an INVALID_OPERATION error |
| being generated by any command that transfers vertices to the the GL: |
| |
| * Any attachment of the draw framebuffer is multiview (section 9.2.8) |
| and any of the following conditions are true: |
| |
| - There is an active program for tessellation control, tessellation |
| evaluation, or geometry stages, or |
| |
| - Transform feedback is active and not paused." |
| |
| Modifications to Chapter 15 of the OpenGL ES 3.2 Specification (Writing |
| Fragments and Samples to the Framebuffer) [OpenGL 4.6 Chapter 17] |
| |
| Modify section 15.1.4 [OpenGL 4.6 section 17.3.5] (Occlusion Queries) |
| adding the following to the end of the second paragraph (describing |
| the SAMPLES_PASSED query): |
| |
| "During multiview rendering (section 9.2.8), the samples-passed count |
| requirement is relaxed and the samples counted must be between the |
| maximum number of samples counted from any view, and the sum of samples |
| counted for all views." |
| |
| Add the following to the end of the fourth paragraph (describing |
| ANY_SAMPLES_PASSED and ANY_SAMPLES_PASSED_CONSERVATIVE): |
| |
| "During multiview rendering (section 9.2.8), the samples-boolean state |
| is set to TRUE if the samples-boolean state from any view is set to |
| TRUE." |
| |
| Modifications to Chapter 16 of the OpenGL ES 3.2 Specification (Reading and |
| Copying Pixels) |
| |
| Add the following paragraph to the end of the description of |
| BlitFramebuffer in section 16.2.1 (Blitting Pixel Rectangles): |
| |
| "If the draw framebuffer has multiple views (see section 9.2.8, |
| FramebufferTextureMultiviewOVR), values taken from the read buffer are |
| only written to draw buffers in the first view of the draw framebuffer." |
| |
| |
| New Implementation Dependent State |
| |
| (Additions to Table 21.40 "Implementation Dependent Values") |
| |
| Get Value Type Get Command Minimum Value Description Sec. |
| --------- ---- ----------- ------------- ----------- ---- |
| MAX_VIEWS_OVR Z+ GetIntegerv 2 Maximum number of views 9.2.8 |
| |
| 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 : <behavior> |
| |
| where <behavior> is as specified in section 3.5. |
| |
| A new preprocessor #define is added to the OpenGL ES Shading Language: |
| |
| #define GL_OVR_multiview 1 |
| |
| |
| In section 4.3.8.1 "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) |
| |
| [[ If implemented in OpenGL ES]] |
| |
| layout-qualifier-id |
| num_views = integer-constant |
| |
| [[ If implemented in OpenGL ]] |
| |
| layout-qualifier-id |
| num_views = integer-constant-expression |
| |
| 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. |
| |
| If this layout qualifier is declared more than once in the same shader, |
| all those declarations must set num_views to the same value; otherwise a |
| compile-time error results. If multiple vertex shaders attached to a |
| single program object declare num_views, the declarations must be |
| identical; otherwise a link-time error results. It is a compile-time |
| error to declare num_views to be less than or equal to zero, or greater |
| than MAX_VIEWS_OVR. |
| |
| Additions to Section 7.1 "Built-in Language Variables" |
| |
| Add the following to the list of built-in variables that are intrinsically |
| declared in the vertex and fragment shading languages: |
| |
| in mediump uint gl_ViewID_OVR; |
| |
| The gl_ViewID_OVR built-in variable holds the integer index of the view |
| number to which the current shader invocation belongs, as defined in |
| in section 4.4.2.4 (FramebufferTextureMultiviewOVR) in the OpenGL |
| Graphics Systems Specification. |
| |
| [[ If OVR_multiview2 is not supported ]] |
| |
| It is a compile- or link-time error if any output variable other |
| than gl_Position is statically dependent on gl_ViewID_OVR. If an |
| output variable other than gl_Position is dynamically dependent on |
| gl_ViewID_OVR, the values are undefined. |
| |
| NOTE: Implementations that also support OVR_multiview2 may not |
| generate an error if these conditions are violated, even if the |
| OVR_multiview2 extension is not enabled. |
| |
| Errors |
| |
| 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_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. |
| |
| Interactions with OpenGL 3.3, ARB_timer_query, and EXT_disjoint_timer_query |
| |
| If none of OpenGL 3.3, ARB_timer_query, or EXT_disjoint_timer_query |
| are supported, ignore references to TIMESTAMP and TIME_ELAPSED queries. |
| |
| Interactions with OpenGL 4.5, ARB_direct_state_access, and |
| EXT_direct_state_access |
| |
| If none of OpenGL 4.5, ARB_direct_state_access and EXT_direct_state_access |
| are supported, the command NamedFramebufferTextureMultiviewOVR does not |
| exist. |
| |
| Interactions with OpenGL ES 3.2, OpenGL 4.0, EXT_tessellation_shader, |
| OES_tessellation_shader and ARB_tessellation_shader. |
| |
| If none of OpenGL ES 3.2, OpenGL 4.0, EXT_tessellation_shader, |
| OES_tessellation_shader or ARB_tessellation shader are supported, ignore |
| all references to tessellation shaders. |
| |
| Interactions with OpenGL ES 3.2, OpenGL 3.2, EXT_geometry_shader, |
| OES_geometry_shader, and ARB_geometry_shader4. |
| |
| If none of OpenGL ES 3.2, OpenGL 3.2, EXT_geometry_shader, |
| OES_geometry_shader, or ARB_geometry_shader4 are supported, ignore all |
| references to geometry shaders. |
| |
| Interactions with OpenGL 4.3, ARB_multi_draw_indirect, and |
| EXT_multi_draw_indirect. |
| |
| If none of OpenGL 4.3, ARB_multi_draw_indirect, or EXT_multi_draw_indirect |
| are supported, ignore all references to multi-draw-indirect. |
| |
| Interactions with OpenGL 3.0 |
| |
| If OpenGL 3.0 (or later) is not supported, ignore all references to the |
| SAMPLES_PASSED occlusion query target. |
| |
| Interactions with OpenGL ES 3.2, OpenGL 4.3, EXT_geometry_shader, |
| OES_geometry_shader, and ARB_fragment_layer_viewport |
| |
| If none of OpenGL ES 3.2, OpenGL 4.3, EXT_geometry_shader, |
| OES_geometry_shader, or ARB_fragment_layer_viewport is supported, ignore |
| all references to gl_Layer. |
| |
| Interactions with OpenGL 3.0 Compatibility Profile |
| |
| If OpenGL 3.0 Compatibility Profile (or later) is not supported, ignore all |
| references to Begin/End. |
| |
| |
| Issues |
| |
| (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, |
| etc? |
| |
| 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 gl_ViewID_OVR visible at every pipeline stage? |
| |
| Resolved: To make integration simple for app developers, the intent is for |
| gl_ViewID_OVR 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 |
| restriction. |
| |
| (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 gl_ViewID_OVR in the shader? |
| |
| Resolved: No. Exposing the gl_ViewID_OVR 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 |
| gl_ViewID_OVR. |
| |
| (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 |
| handled? |
| |
| 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 |
| FramebufferTextureMultisampleMultiviewOVR. |
| |
| (15) How do clears apply to framebuffers with multiple views |
| (bugzilla 16173)? |
| |
| Resolved: Clears are applied to all views. |
| |
| (16) How should blit operations to draw framebuffers with multiple views |
| be handled (bugzilla 16174)? |
| |
| Resolved: The options are to broadcast the blit, only blit to a subset |
| of views, or throw an error. There's no particularly compelling use case |
| for either of the first options, so an error would have been desirable. |
| However, this was missed when the extension was initially drafted, and |
| implementations all ended up doing the same thing - blitting to just the |
| first view of the draw framebuffer. |
| |
| (17) How do clears apply to framebuffers with multiple views |
| (bugzilla 16173)? |
| |
| Resolved: Clears are applied to all views. |
| |
| (18) What happens if the num_views layout qualifier has an invalid value |
| like zero or something above MAX_VIEWS_OVR? What happens if num_views |
| is specified multiple times in the same shader, or in multiple vertex |
| shaders (this is only possible in OpenGL)? |
| |
| RESOLVED: This is treated similarly to how layout local_size_{x,y,z} is |
| handled in compute shaders: |
| - num_views <= 0 or > MAX_VIEWS_OVR is a compile error |
| - if declared multiple times in the same shader the values |
| must be the same or a compile-time error results. |
| - if declared in multiple shaders attached to the same program object |
| a link-time error results. |
| |
| (19) Is the shader built-in variable really called gl_ViewID_OVR? The |
| shading language convention does not normally include an underscore before |
| the vendor suffix. |
| |
| RESOLVED: Yes it really is. It doesn't quite follow the standard extension |
| conventions, but there were a number of implementations that already |
| supported it before this was realized. We'll just leave it this way for |
| compatibility. |
| |
| (20) Is there a gl_MaxViewsOVR shading language built-in constant? |
| |
| RESOLVED: No. Initial implementations didn't provide this. If this ever |
| is made KHR or core functionality, this could be added. |
| |
| (21) What is the minimum values permitted for MAX_VIEWS_OVR? |
| |
| RESOLVED: 2. But at least 6 is recommended for consistency with Vulkan. |
| Six views is desireable as it can be used to render all faces of a cube map |
| in a single pass. Added state table entries for this in revision 0.8. |
| |
| (22) What are the rules to check if anything other than gl_Position |
| depends on gl_ViewID_OVR and what happens if the rules aren't met? |
| |
| RESOLVED: It is a compile- or link-time error if it can be determined |
| that an output variable other than gl_Position is statically dependent on |
| gl_ViewID_OVR. However, if an output variable other than gl_Position |
| is dynamically dependent on gl_ViewID_OVR, the results are undefined. |
| |
| NOTE: This restriction is relaxed if OVR_multiview2 is supported, |
| and some implementations may not implement these checks even if |
| OVR_multiview2 is not enabled. It is recommended and preferred that |
| all implemenations support OVR_multiview2 and that applications |
| enable the extension when present. |
| |
| For non-VTG stages (eg fragment) which don't have a gl_Position output |
| variable this means that no outputs can depend on the gl_VIewID_OVR. |
| It is still possible that shader side effects (such as image or buffer |
| stores, if supported) could be view-dependent. |
| |
| (23) What is the behaviour if transform feedback, tessellation or |
| geometry shaders, or timer queries are used? |
| |
| RESOLVED: INVALID_OPERATION is generated for any draw operation |
| with when the draw framebuffer is multiview if there is an active |
| tessellation control, tessellation evaluation, or geometery shader, |
| or if transform feedback is active. |
| |
| For timer queries there is no good time to do a multiview error check, |
| (because a multiview framebuffer could be bound before or after the |
| timer query has started) and thus the results of the TIME_ELAPSED |
| and TIMESTAMP queries have undefined values if a multiview framebuffer |
| was bound at any time during their execution. |
| |
| (24) Do instanced drawing commands (DrawArraysInstanced*, and |
| DrawElementsInstanced*) work with this extension? |
| |
| RESOLVED: Yes. No specific edits are required because "It Just Works"(TM) |
| |
| (25) Do indirect drawing commands (DrawArraysIndirect, DrawElementsIndirect), |
| work with this extension? |
| |
| RESOLVED: Yes. No specific edits are required because "It Just Works"(TM) |
| |
| (26) Do multi draw indirect commands (MultiDrawArraysIndirect, |
| MultiDrawElementsIndirect) work with this extension? |
| |
| RESOLVED: Yes. No specific edits are required because "It Just Works"(TM) |
| |
| (27) What happens if the <baseViewIndex> + <numViews> is out of range? |
| For example, if it's greater than the number of layers in the attached |
| texture or greater than MAX_ARRAY_TEXTURE_LAYERS? |
| |
| RESOLVED: In cases there the resulting value could never be a valid |
| <layer> argument to FramebufferTextureLayer, the INVALID_VALUE value |
| is generated. This follows from the fact that |
| FramebufferTextureMultiviewOVR is defined in terms of |
| FramebufferTextureLayer. For cases which are dependant on the properties |
| of a specific texture (referencing more layers than exist), this is a |
| to be a framebuffer attachment completeness check as this can change if |
| the texture is redefined after the FramebufferTextureMultiviewOVR call. |
| |
| (28) What is the value of FRAMEBUFFER_ATTACHMENT_TEXTURE_LAYER after |
| FramebufferTextureMultiviewOVR is called? |
| |
| RESOLVED: It is set it to the value of <baseViewIndex>. |
| A FRAMEBUFFER_ATTACHMENT_MULTIVIEW_OVR framebuffer property would be |
| useful here.. |
| |
| (29) Should there be a FRAMEBUFFER_ATTACHMENT_MULTIVIEW_OVR property to |
| indicate multiview framebuffers, similar to the |
| FRAMEBUFFER_ATTACHMENT_LAYERED property? |
| |
| RESOLVED: No. Ideally there would to allow distinguising between |
| layered framebuffers and multiview framebuffers, and to know which of |
| FRAMEBUFFER_ATTACHMENT_TEXTURE_LAYER, |
| FRAMEBUFFER_ATTACHMENT_TEXTURE_NUM_VIEWS_OVR, and |
| FRAMEBUFFER_ATTACHMENT_TEXTURE_BASE_VIEW_INDEX_OVR are valid. |
| Unfortunately existing implementations don't have this, so it will |
| just have to be implied. This is something that could be improved in |
| a promoted version of this extension. |
| |
| (30) What types of textures can be used for multiview rendering? |
| Two-dimensional array textures at a minimum, what about three- |
| dimensional, cube map, cube map array or two-dimensional |
| multisample textures which are also accepted by FramebufferTextureLayer |
| (which is what this extension is defined in terms of). |
| |
| RESOLVED. The initial extension is limited to two-dimensional array |
| textures. A future extension could extend it further if there is demand. |
| |
| (31) Is multiview supported for compute shaders? If so, how would it work? |
| |
| RESOLVED. No. Multiview rendering is orthogonal to compute shaders since |
| Dispatch* commands do not operate on framebuffer attachments and therefore |
| it is meaningless to try to describe interactions with multiview |
| framebuffers. Prior to revision 3, this specification stated that |
| gl_ViewID_OVR was available in the compute shading language but not all |
| implementations did so, and for those that did, it is impossible for it |
| to ever have a value other than 0. |
| |
| (32) If geometry and tessellation shaders are not supported with multiview |
| rendering why allow gl_ViewID_OVR to be accepted in tessellation and |
| geometry shaders? |
| |
| RESOLVED. There is no benefit. This was removed in revision 3. Older |
| drivers may of course continue to allow such shaders to compile, but |
| it is not possible to use them. |
| |
| (33) How does the gl_Layer builtin input in the fragment shader interact |
| with multiview? |
| |
| RESOLVED: Whenever a multiview framebuffer is bound, the contents of |
| gl_Layer in the fragment shader are undefined. This is consistent with |
| issue (1), which disallows geometry shader with multiview framebuffers. |
| |
| (34) How does this extension interact with the OpenGL Compatibility |
| Profile? |
| |
| RESOLVED: When a multiview framebuffer is bound, Begin/End may render to a |
| subset of the views in the framebuffer. (Specifically which views is |
| undefined, and may be any subset of the views attached to the framebuffer, |
| including the null set.) |
| |
| |
| 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 |
| 0.7 07/25/17 tjh Clarify Blit and Clear behaviours, and fixed framebuffer attachment |
| binding psuedocode (bugzillas 16173, 16174, 16176) |
| 1 10/10/17 dgkoch Completed extension. |
| - Rebased on ES 3.2 (and OpenGL 4.6 where necessary) and added |
| extension interactions |
| - Added DSA command for GL: NamedFramebufferTextureMultiviewOVR |
| - properly documented gl_ViewID_OVR and behaviour |
| - documented error behavior for num_views |
| - added error behavior for tess, geom, xfb, and timer queries |
| - documented new FRAMEBUFFER_ATTACHMENT*OVR variables |
| - clarify that only 2D-array textures are supported |
| - better document new framebuffer completeness conditions |
| - document MAX_VIEWS_OVR and specify minimum value (2) |
| - added issues 18-30 |
| 2 11/15/17 dgkoch Fix tessellation typos. Fix incorrect reference to compute shaders |
| instead of vertex shaders. |
| 3 12/13/17 dgkoch Clarify that compute shaders are orthogonal to multiview |
| framebuffers (Issue 31). Remove gl_ViewID_OVR from compute, |
| tessellation, and geometry shaders. |
| 4 05/02/18 jhelferty Clarify interop rules for gl_Layer in fragment shader (33), and |
| interop with compatibility profile's Begin/End (34). Add mention |
| of OES_geometry_shader and OES_tessellation_shader to interop. |
| Clarify what happens when transform feedback is paused. |
| 5 07/25/18 oetuaho Fix off-by-one issue in baseViewIndex + numViews check. |
| 6 10/19/18 dgkoch Add standard boiler plate shader extension language. |
| |