WebGL2 backend

[kvark]

Is your feature request related to a problem? Please describe.
The new GLES3 backend landed in #1510
Now we need to enable the Web target for WebGL2.

Describe the solution you'd like
On "wasm32-unknown-unknown" target the GLES backend should target WebGL2, just like the old "gfx-backend-gl" did.

Describe alternatives you've considered
Having a separate feature for this, may still be a good idea in order to help the cargo-vendor volume.

Additional context
Required for Bevy

[zicklag]

I'm going to start working on this as I have the time. So far I got it compiling, but haven't tested it yet.

[zicklag]

Got the hello-triangle example working on web. So far it's the only example running, and I may have to figure out how to calculate certain hardware limits that I am just guessing at so far, but it's a good sign. 😄

And now with naga we don't have to bundle the WASM build of spirv_cross! So nice. :)

[kvark]

It would be very useful to get in touch with you on more immediate channels than Github. Please consider joining Matrix or Discord!

[Gordon-F]

@zicklag Hi! A couple of notes, that, maybe, helps you a little bit with your journey :)

1. Bring WebGL related fixes, that are presented in gfx-backend-gl, but not present in wgpu-hal:

• [WebGL] Return only RGBA swapchain formats gfx#3699
• [WebGL] Fix index buffer usage gfx#3682
• Support wgpu skybox example on webgl gfx#3773

2. 2 debugging tools (idk, maybe these are the only 2 existing useful debugging tools for webgl 😢)

• SpectorJS
• webgl-lint. I recommend disabling throwOnError first. And you can safely ignore all errors like glAnyFunction(None) because wasmbindgen send None as undefined, but webgl-lint required null.

[zicklag]

Got some help on Matrix ( thanks guys! ), and with gfx-rs/naga#1100 the shader problem I was stuck on was fixed.

After that I got to a blank screen for the cube example ( no more panic! ):

It's got an invalid operation I've got to investigate, but we got past the shader problems!

[Gordon-F]

@zicklag This was fixed in gfx-rs/gfx#3682.

From WebGL docs:

Only one target can be bound to a given WebGLBuffer. An attempt to bind the buffer to another target will throw an INVALID_OPERATION error and the current buffer binding will remain the same.

I guess, you can use gfx-backend-gl solution as is in wgpu-hal. https://github.com/gfx-rs/gfx/blob/master/src/backend/gl/src/queue.rs#L621-L665

[zicklag]

@Gordon-F Ah, cool, thanks. I had already started copying that code from the gfx backend. So far grabbing the gfx-backend-gl code every time something goes wrong is working pretty well. 😁

---

And...We've got a cube!

Apparently my browser is using mesa for the WebGL implementation and runs into the same fastclear bug ( #1627 ), but I think something else is wrong, too, because the color is still wrong with fastclear disabled. I'm going to look into that a little more.

Also, a quick test of the shadow example yields:

[cwfitzgerald]

The fact the error is talking about the vertex stage is erroneous. As it stands now, the shadow example cannot run on WebGL at all as it uses SSBOs and WebGL doesn't support SSBOs.

That being said, it doesn't actually need to use SSBOs, it could totally use a uniform buffer for what it is doing.

[zicklag]

That being said, it doesn't actually need to use SSBOs, it could totally use a uniform buffer for what it is doing.

Would it be good to switch it to a uniform for web and desktop, or do we want it using SSBOs for the sake of demonstrating GPU features?

[kvark]

Let's have the shader with 2 different vs entry points: one using a storage buffer, and another using a uniform buffer at exactly the same binding. The Rust side can check downlevel features and adjust the selected entry point as well as the bind group accordingly.

…

On Jul 17, 2021, at 15:37, Zicklag ***@***.***> wrote:  That being said, it doesn't actually need to use SSBOs, it could totally use a uniform buffer for what it is doing. Would it be good to switch it to a uniform for web and desktop, or do we want it using SSBOs for the sake of demonstrating GPU features? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[zicklag]

If you compile WGPU for web, how do we want to indicate that you want support for WebGPU or WebGL or both?

Right now if you compile for web, it just assumes WebGPU and there's no way to disable it ( if I've interpreted that correctly ). Since it's just passthrough to the browser is that probably fine, or do we want a webgpu feature flag so that you could choose just to target WebGL?

Also, if we pass in the WebGL flag do we want it to keep the WebGPU backend, too. So that, unless otherwise specified by the user's Backends selection, it will try to use WebGPU and fall back to WebGL?

---

On a related topic, does anybody else get a problem trying to compile WGPU master for WASM? I'm getting tons of errors like the web-sys features are not properly activating somehow and all of the GPU types are missing.

cargo build --target wasm32-unknown-unknown --example shadow

error[E0432]: unresolved import `web_sys::GpuTextureFormat`
   --> wgpu/src/backend/web.rs:461:9
    |
461 |     use web_sys::GpuTextureFormat as tf;
    |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ no `GpuTextureFormat` in the root

---

Edit: Building the docs with the following command also only shows so many types enabled. I wonder if it's like winit's selected features are the only ones being applied. Maybe this has something to do the Cargo resolver version 2.

 cargo doc -p web-sys --no-deps --target wasm32-unknown-unknown --open

---

Edit2: Now I'm even more confused. CI seems to be running just fine, but I can't get this command to complete locally without tons of errors:

cargo +1.53.0 clippy --target wasm32-unknown-unknown -p wgpu -- -D warnings

[grovesNL]

@zicklag

Since it's just passthrough to the browser is that probably fine, or do we want a webgpu feature flag so that you could choose just to target WebGL?

IMO it should be the other way around, so people would opt-in to using WebGL as fallback somehow and we always assume WebGPU is available by default. We had a feature for opting into WebGL previously but not sure if it's still there after the gfx-hal -> wgpu-hal migration.

On a related topic, does anybody else get a problem trying to compile WGPU master for WASM? I'm getting tons of errors like the web-sys features are not properly activating somehow and all of the GPU types are missing.

You need to use RUSTFLAGS=--cfg=web_sys_unstable_apis, see https://github.com/gfx-rs/wgpu/wiki/Running-on-the-Web-with-WebGPU-and-WebGL#compiling-for-wasm

[zicklag]

You need to use RUSTFLAGS=--cfg=web_sys_unstable_apis

Ah, that works!

IMO it should be the other way around,

The only issue I have with that is actually that building the WebGPU wrapper requires that web_sys_unstable_apis flag. For now, because WebGPU isn't even available in normal browsers yet, it seems like having a default feature that requires an unstable flag when targeting web isn't ideal. That would require everybody who wants to build for WebGL to add the extra rustc flag, even though they aren't practically using it.

[andrewvarga]

Hi all! I asked this on the Wgpu Users channel but maybe it's better to track on github:
https://matrix.to/#/!XFRnMvAfptAHthwBCx:matrix.org/$xqMiU6EZP9Vk4K1Rl7VDxmXiXeeAvqdcIYeau80gNSY?via=matrix.org&via=mozilla.org&via=kyju.org

In short, I'm just curious if the WebGL2 backend is considered stable enough for production at this point, and if it is maybe I'm doing something wrong?
Something as simple as using a uniform buffer to set the color of a triangle seems not to work when target is WebGL2, and the official examples have problems on my end.

[zicklag]

Replied in a new discussion: #3003 (comment).