Support for the OVR_multiview2 WebGL extension

[expenses]

The WebGL OVR_multiview2 extension is implemented in:

• Chrome on Windows, Linux and Android
• Firefox on Android

but NOT on Firefox on Linux afaik.

This is the main (there's also an Occulus extension: https://developer.mozilla.org/en-US/docs/Web/API/OVR_multiview2) extension used for multiview rendering in WebGL.

Registry link: https://www.khronos.org/registry/webgl/extensions/OVR_multiview2/
MDN link: https://developer.mozilla.org/en-US/docs/Web/API/OVR_multiview2

The number of views needs to be passed in as a pipeline option and then set in the vertex shader with layout(num_views = X). I have a working (but messy) integration with wgpu here: expenses/wgpu@7da24f3. Note that this relies on rustwasm/wasm-bindgen#2903 and grovesNL/glow@main...expenses:multiview.

We need a good way to check whether the target API is WebGL so that we can determine whether to use this extension or the regular GL_EXT_multiview one.

[expenses]

We need a good way to check whether the target API is WebGL so that we can determine whether to use this extension or the regular GL_EXT_multiview one.

I've solved this by using Embedded { version: u16, is_webgl: bool } in the version. Not sure if this is the best way.

[jimblandy]

@JCapucho, if this isn't something you can review feel free to turn down the review request - I just wanted to put this on someone's plate to see if we could make some progress.

[JCapucho]

I'll be honest, I don't have a lot of experience with webgl and have almost 0 experience with multiview, but I've looked at the extensions and overall everything looks mostly fine.

But I think there are some problems.

[expenses]

@JCapucho I've re-done this a little bit to make selecting which multiview extension to use explicit. I've put the multiview options on the glsl options for convenience, but wgpu creates these when creating a pipeline layout so we need to set it to None there:

https://github.com/expenses/wgpu/blob/dbab152093dd9ca1ca255a57df4048a92b857325/wgpu-hal/src/gles/device.rs#L881-L888

Should I be putting the multiview options on the pipeline options instead?

Also the nightly test seems to be broken by something outside of this PR.

[JCapucho]

@JCapucho I've re-done this a little bit to make selecting which multiview extension to use explicit.

What's the benefit of doing it this way? It seems to add a lot of code with no real benefit

I've put the multiview options on the glsl options for convenience, but wgpu creates these when creating a pipeline layout so we need to set it to None there:

https://github.com/expenses/wgpu/blob/dbab152093dd9ca1ca255a57df4048a92b857325/wgpu-hal/src/gles/device.rs#L881-L888

Should I be putting the multiview options on the pipeline options instead?

If they are only available in the pipeline section they should be added in pipeline options.

Also the nightly test seems to be broken by something outside of this PR.

I noticed, seems like some PR didn't update the snapshots, I'll see if I can fix it
Nevermind seems like nightly ron as defaulted to always add the decimal part of floating point numbers.

[expenses]

What's the benefit of doing it this way? It seems to add a lot of code with no real benefit

I think it's nicer to only specify which extension to use if the multiview options are set, as opposed to always having is_webgl in the version. It could be streamlined though but I don't think that it adds that much code.

[JCapucho]

I think it's nicer to only specify which extension to use if the multiview options are set, as opposed to always having is_webgl in the version. It could be streamlined though but I don't think that it adds that much code.

My worry is that we are opening ourselves up to have the backend mismatch extensions and version, with this approach it's possible to set the version to core and produce a webgl extension, and if we end up doing this for other extensions the problem will quickly get worse.

[expenses]

My worry is that we are opening ourselves up to have the backend mismatch extensions and version, with this approach it's possible to set the version to core and produce a webgl extension, and if we end up doing this for other extensions the problem will quickly get worse.

So my thinking is that we'd only need to check for WebGL with this extension, so doing this would be okay. Unfortunately https://www.khronos.org/registry/webgl/extensions/WEBGL_multi_draw/ also needs a specific WebGL extension: GL_ANGLE_multi_draw, so this would cause problems if we wanted to support that.

So I think I'll go and revert these changes to have is_webgl on the version again. Sorry about that.

[JCapucho]

So my thinking is that we'd only need to check for WebGL with this extension, so doing this would be okay. Unfortunately https://www.khronos.org/registry/webgl/extensions/WEBGL_multi_draw/ also needs a specific WebGL extension: GL_ANGLE_multi_draw, so this would cause problems if we wanted to support that.

So I think I'll go and revert these changes to have is_webgl on the version again. Sorry about that.

No worries, sometimes we gotta try stuff to realize it's not the best solution.

[JCapucho]

I think everything implementation wise is good (I left just a small nit), but in terms of testing I think it's best to use wgsl tests instead of spirv, since wgsl is the "blessed" frontend and it allows us to quickly see what a test should produce especially when reviewing.

[JCapucho]

I think a better name for this would be gles since embedded is the name of the glsl profile and in this case we are trying to distinguish the platform.

[expenses]

Done

[JCapucho]

Just one more small thing and we are good to go

[JCapucho]

Brilliant work, just needs the auto formatter to run and it's good to merge

[expenses]

@JCapucho okay, lets try that!