Switch to webgpu-rs for rendering backend

[Herschel]

I started with glium just to get something up and running quickly, but ideally we'd use gfx-rs for the rendering backend on desktop platforms. wasm support also just landed in gfx-rs thanks to glow, so maybe this backend could also be used on web.

edit 4-25: Instead of gfx-rs, we could use webgpu-rs, which will soon have browser support, and is a better level of abstraction for us.

[Dinnerbone]

Are we set on gfx-rs, or is something like wgpu an option? That's supposed to be web compatible soon, and feels much easier to switch to (and easier to maintain, I hope). Will also be easier to integrate a UI library if we want fancy debugging stuff in the future.

[Herschel]

I've been keeping an eye on wgpu, it's just a question of what is actually usable and actionable in the present. I expect it will be at least a year before WebGPU is solidified and has good browser compatibility. Meanwhile, gfx-rs has a WebGL backend today.

That said, I don't see any reason why we can't try both, and then switch from one to the other as things settle. We could even use wgpu for desktop and call WebGL directly on web for now. Our renderer is simple enough that it's easy to experiment.

[Dinnerbone]

My biggest concern is the amount of work (now, and in the future as we bring in more complexity) required. gfx-rs is entirely DIY and wgpu is slightly less so (it's a layer on top of gfx-rs). It also means we can easily bring in UI frameworks without needing to write our own renderer for them.

[leo60228]

Web support was just merged into wgpu.

[Dinnerbone]

@Herschel this issue is assigned to you, are you actively working on it? I'd like to tinker with a wgpu backend for desktop

[Herschel]

I've actually been working on the WebGL side, so if you want to team up and start on the WebGPU side for desktop, that'd be great. I think this is the best path:

• WebGL backend for web. This will be used in the immediate future on web because WebGPU will not be standard on browsers for some time.
• WebGPU backend for desktop, with an eye on also using it on the web as support becomes widespread.

I've got a branch where I've pulled out the rendering backends and common tessellation code into subcrates; WebGPU could be another backend under here. I'll push it to my fork this weekend.

[Dinnerbone]

I have a working wgpu backend locally now save for one thing: we can't do the same stencil operations as we do in GL, the stencil data needs to be set at creation of the pipeline and not during actual render-time. GFX seems to support dynamic stencil data but wGPU doesn't. Will investigate further.

Good idea on pulling out rendering into another crate. I'll see how to get my stuff and your PR working nicely together!

[Herschel]

For most modern APIs, you can still set at least the stencil reference value at render-time, is that true for webgpu too?

1. If we have to create every single state, this is 513 currently (8-bit * 2 for "write mask" vs "use mask" + 1 for "not-masking"). Even in combination with the shader states, I don't think it's too bad.

2. With the current stencil method, I think the "using mask" state may only need to set the reference value. The current GL renderer sets the read/write mask, but I don't think this is necessary (I have to think about this a little more). That would cut it down 256ish states. Scratch that, the read mask is needed here because we don't want previous masks to interfere with the comparison. But the "write mask" state only needs to set a specific bit (write_stencil_mask), so this is 8 states instead of 256 currently.

3. An alternative stencil method: use the "increment" stencil op; when pushing a mask, draw the mask with increment. This only requires a single state for the "writing mask" state. The "using mask" state again only needs to set the reference value (to the depth of the mask stack), so this would be another single stencil state. The down side: we'd have to store the stencil buffer on each activate_mask, and restore it on pop_mask for multiple masks to work properly. The plus side: this completely avoids the issue running out of stencil bits with too many masks-in-masks (happens in Achievement Unlocked, for example, but I think this could also be avoided with some smarter logic in the current stencil method.)

[Dinnerbone]

I like 3 the most but it looks like copying depth/stencil buffers is prohibited. :(

https://github.com/gfx-rs/wgpu/blob/bc065e4/wgpu-core/src/device/mod.rs#L351

If we just use a fresh buffer for each mask group, we'd forget about the parent mask info and start overwriting already reserved pixels.

I'm really scared to go with option 1 because that's a lot of pipelines to create, honestly. 513 * 3 (color, gradient, bitmap) sounds so very expensive. I'm positive we can merge the 3 separate draw types into just one later (I have lots of ideas on how to improve our rendering), but still... oof.

[Herschel]

Added in #527.