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.