Is The WebGL2 Backend Production Ready?

[zicklag]

Originally posted by @andrewvarga here: #1617 (comment)

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.

---

Hi @andrewvarga!

I can't get to matrix, so I can't get to your exact question, but I think that the WebGL2 backend is fairly "production-ish" ready, with the caveat that WebGL2 will never be able to be a fully-compliant WGPU implementation. That doesn't mean you can't use it and get great results, though.

For instance, here's a Bevy WebGL2 demo with PBR: https://bevyengine.org/examples/3d/load-gltf/.

As far as the official examples, both the mipmap and shadow examples on the official site don't work right for me, but the other ones do.

I think shadow should be fixable, but I don't know what's causing the issue. I don't know that mipmap is ever going to work right or not, I can't remember if there's a way to get WebGL to run that correctly.

As far as setting the color of a triangle, you should absolutely be able to get that working. Does the Bevy example linked to above work for you. And how about the WGPU.rs Cube example?

If neither of those work, it might be a driver/browser/hardware issue.

[andrewvarga]

Hey @zicklag, thanks for getting back on this, the Bevy example looks really promising.

I've created a simple branch with my changes which modifies the cube example by adding a uniform buffer for the color:
https://github.com/andrewvarga/wgpu/pull/1/files

When running this with WebGPU I'm getting a red triangle, but it is white on WebGL2. It's possible that I did an easy oversight somewhere.. would be interesting to see if you see the same thing, I'm on an M1 Macbook but I can test this out on Windows too.

[zicklag]

It looks like it's not generating the uniform block bindings. Looks like it might be an issue during the shader reflection here.

Because we're never hitting this line, which I think is necessary to map the buffer binding to the block in the shader.

[zicklag]

It's not finding the uniform name here, so it's not generating the name_binding_map entry.

[zicklag]

@cwfitzgerald if you get the chance to look a this, do think that naga should be finding the uniform name here? Do you think I'm on the right track with this?

[andrewvarga]

I created a github issue to track this: #3024
In the meantime I guess a workaround would be to use a single bind group instead of two (?)

[zicklag]

Good idea to open an issue.

In the meantime I guess a workaround would be to use a single bind group instead of two (?)

I'm not super familiar with the terminology, but I think we are already using a single bind group, but different bindings? ( Because both use @group(0), but different @binding([number]) )

But I know what you mean, and it seems worth a try.

It might also be worth trying to put it in a separate group. I was just looking at the Bevy sprite shader and it looks like it uses a separate group for the fragment shader data. That might be something worth trying.

[ryankaplan]

@zicklag @andrewvarga do either of you know if this has been fixed? I'm using the WebGL backend and I'm running into an issue that looks a lot like shaders getting garbage uniform data. I'm wondering if it's the same problem you ran into.

I'm asking because it's been a year and I know folks have been working on the WebGL backend. So I wanted to check if this is stale before digging further.

[cwfitzgerald]

Take a look at #3674, this should have the majority of the known issues