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 parameter of GetFramebufferAttachmentParameteriv: FRAMEBUFFER_ATTACHMENT_TEXTURE_NUM_VIEWS_OVR 0x9630 FRAMEBUFFER_ATTACHMENT_TEXTURE_BASE_VIEW_INDEX_OVR 0x9632 Accepted by the 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 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 is FRAMEBUFFER_ATTACHMENT_TEXTURE_NUM_VIEWS_OVR and the value of FRAMEBUFFER_ATTACHMENT_OBJECT_NAME is a two-dimensional array texture, then will contain the number of views that were specified for the attachment point via FramebufferTextureMultiviewOVR. Otherwise, will contain zero. "If is FRAMEBUFFER_ATTACHMENT_TEXTURE_BASE_VIEW_INDEX_OVR and the value of FRAMEBUFFER_ATTACHMENT_OBJECT_NAME is a two-dimensional array texture, then will contain the base view index that was specified for the attachment point via FramebufferTextureMultiviewOVR. Otherwise, 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 and 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 ); } 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 , 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 is non-zero and the command does not result in an error, the framebuffer attachment state corresponding to 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 , and the value of FRAMEBUFFER_ATTACHMENT_TEXTURE_NUM_VIEWS_OVR is set to . Errors In addition to the corresponding errors for FramebufferTextureLayer when called with the same parameters (other than ): An INVALID_VALUE error is generated if: - is less than 1 or if is greater than MAX_VIEWS_OVR. - is a two-dimensional array texture and + is larger than the value of MAX_ARRAY_TEXTURE_LAYERS. - texture is non-zero and 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 is a two-dimensional array and the attachment is multiview, all the selected layers, [, + ), 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 : where 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 + 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 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 . 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.