[Public WebGL] WEBGL_multiview discussion

Rafael Cintron [email protected]
Wed Jan 4 14:08:23 PST 2017

Some feedback:

I would prefer that this extension work in WebGL 1.0 and be used to render to multiple views with one draw command.  While it is great that Chrome and Firefox have WebGL 2.0, it will not be available in all browsers in the short term.  For Edge, WebVR is likely going to arrive before WebGL 2.0.

If the layout qualifier prevents the shader from working in WebGL 1.0, I think we should drop the qualifier requirement.  This will allow the shader to be used in more places and remove the additional overhead/complexity of rationalizing the number of views in the qualifier with the state of the world on the API side.

We should also consider simplifying the extension API by removing FramebufferTextureMultiviewOVR and its associated <pname> parameters.  If we need these for a more general extension that allows additional things to be “multi-viewed”, we can add them as a separate extension.


From: [email protected] [mailto:[email protected]] On Behalf Of Olli Etuaho
Sent: Wednesday, January 4, 2017 3:54 AM
To: Florian Bösch <[email protected]>; Mark Callow <[email protected]>
Cc: Maksims Mihejevs <[email protected]>; public webgl <[email protected]>
Subject: RE: [Public WebGL] WEBGL_multiview discussion

Trying to answer the questions here:

The extension document includes proposed changes to the core WebGL 1.0 spec to enable creation of stereo default framebuffers. This is required to introduce an opaque stereo framebuffer concept which can be implemented under the hood in various ways, such as side-by-side images inside a single texture, as a texture array, or as a native stereo framebuffer. This makes it possible to avoid extra copies in the display pipeline. Basically the API user would set context creation parameter “stereo: true” and then get a stereo default framebuffer back. Support can be checked by querying the actual context creation parameters.

We want stereo canvases in WebGL 1.0 so that existing WebVR applications that are built on WebGL 1.0 will be able to easily migrate to using them. It also makes the spec simpler. I would expect practically all WebVR capable hardware to eventually support WebGL 2.0, though.

In the current proposal using shaders that don’t declare numViews can’t be used to render to multiple views with a single draw command. Whether multiple views can be cleared with a single clear() command is not clearly defined in the native OVR_multiview spec either, and needs to be either fixed there or defined in the WebGL version of the extension spec. The question is whether these things should be possible, maybe even in the core spec when using a stereo framebuffer.

We’re trying to keep the WebGL extension spec close to OVR_multiview, but unfortunately OVR_multiview is quite vague in many respects and needs to be tightened for WebGL. Also the WebGL spec needs to be reasonably implementable on top of different APIs like DirectX as well, which requires some changes like the support for opaque stereo framebuffers.


From: Florian Bösch [mailto:[email protected]]
Sent: keskiviikkona 4. tammikuuta 2017 11.01
To: Mark Callow <[email protected]<mailto:[email protected]>>
Cc: Maksims Mihejevs <[email protected]<mailto:[email protected]>>; Olli Etuaho <[email protected]<mailto:[email protected]>>; public webgl <[email protected]<mailto:[email protected]>>
Subject: Re: [Public WebGL] WEBGL_multiview discussion

On Mon, Jan 2, 2017 at 6:14 PM, Olli Etuaho <[email protected]<mailto:[email protected]>> wrote:
1. Why not just enable WEBGL_multiview extension automatically when a stereo canvas is requested? Support for stereo canvas requires core spec changes either way. The biggest hurdle for this I see is that WEBGL_multiview requires layout qualifiers, which do not exist in core WebGL 1.0 shaders, so it would be a bad fit for WebGL 1.0.

I'm not sure I understand the question. How is a stereo canvas requested?

2. Should drawing commands that don’t use multiview shaders be compatible with choosing both default framebuffer draw buffers with gl.BACK? This could be done similarly for clears as well.

Also not sure I understand this one, can you elaborate?

On Tue, Jan 3, 2017 at 2:48 AM, Mark Callow <[email protected]<mailto:[email protected]>> wrote:
Why does this extension need to be supported on WebGL 1.0? Browsers are on the verge of removing the flags that are currently hiding their WebGL 2 implementations.
 If something can be supported in WebGL1 in principle, it's worth investigating because WebGL1 will be the only choice for a long time long after WebGL2 activation by some or other UA. That's because either other UAs haven't implemented WebGL2 yet, or because the hardware does not support it, or the hardware/drivers exhibit blacklistable flags for the WebGL2 implementation (but not WebGL1).

On Tue, Jan 3, 2017 at 3:19 AM, Mark Callow <[email protected]<mailto:[email protected]>> wrote:
The question in this case is whether any of this hardware can support stereo canvases?
That's irrelevant.

The ES extension for multiview https://www.khronos.org/registry/gles/extensions/OVR/multiview.txt refers to OpenGL ES 3.0 as required. It doesn't matter what the hardware supports or not, unless an API revision of ES 3.0 is used (both on the front-end as well as on the backend, or something better), OVR_multiview cannot be exposed.

It's unfortunate that that means OVR_multiview can't go on WebGL1, but it is what it is. And unless we're willing to break with the parent standards intentionally (please don't), that's the way it is.


I have some questions regarding this extension:

  1.  The extension definition does not follow the customary form of extensions so far defined that mirror underlying ES extensions. Can you elaborate why?
  2.  How does an application switch between stereo and non stereo rendering? (a common thing that web pages would do depending if the user wishes to interact with a HMD or with a monitor)
  3.  Does this extension integrate with WebVR in any way?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://khronos.org/pipermail/public_webgl_khronos.org/attachments/20170104/590e9c36/attachment.html>

More information about the public_webgl mailing list