Pros:
- Compared to OpenGL, WebGPU is wayyy better in every way
- Compared to Vulkan/DirectX 12/Metal, WebGPU is 0.5-1 steps higher level (easier to use), and covers macOS/iOS without needing a separate Metal backend
- We get WebGPU (browser) support for free, as mentioned in this post :). wgpu also gives us WebGL2 for free (provided you don't use certain features) which we're using to target browsers until WebGPU is more fully supported.
- WGSL (the shader language) is actually fairly nice coming from Rust, compared to the more C-style GLSL/HLSL
Cons:
- We're leaving performance on the table due to WebGPU validation / extra work it needs to do to abstract differences between platforms and be higher level than the APIs it wraps. Not the worst thing in the world, but it's a downside. Probably can be alleviated on non-browser platforms with opt-in relaxed validation and lower level APIs (wpgu-hal).
- Library/tooling maturity is much worse. Wgpu/naga (the WGSL shader compiler) frequently have bugs (less now than they used to), and error messages leave much to be desired. Shader tooling is much worse - we've had to build our own shader import system, syntax highlighting is provided by a non-bevy VSCode extension someone on the internet kindly maintains, GPU debugging tools don't have source-level info for WGSl shaders, etc. Again this will get better over time.
- We can't access all the latest features. Things like raytracing, subgroup/warp/wave operations, binding arrays, etc. That said, wgpu does provide native-only extensions for some of these. Support inevitably trails behind Vulkan/DirectX 12 though. Not really a huge deal for the most part, but I personally do miss this. Again will get better as wgpu/webgpu finalize and more time can be spent extending the spec with newer features.
- I've left this for last, but the explicit binding model sucks. WebGPU is fairly high level, but keeping explicit binding instead of requiring binding arrays is awful. Every time you want to add a texture/buffer/etc to your shader, you need to modify the bind group layout, modify the bind group, and then modify the shader, and keep those definitions in sync. When you have multiple pipelines, bind groups, shaders, and modular systems that only need certain resources under different conditions or certain parts of different shaders, it's just awful to keep track of. The ergonomics are terrible. I wish WebGPU would've required binding arrays and just accepted losing support for some older devices. In Bevy we plan to write an abstraction that acts more like binding arrays and falls back to explicit bindings where needed, but that's still a lot of work.
Overall, I generally think wgpu was/is the right choice for Bevy. The ergonomics could still use work, we leave performance on the table, we don't get all the advanced and new features, and the growing pains were (and still are, to a lesser degree) real. But we still get better ergonomics compared to other options, WebGPU support for browsers, 1 rendering backend vs at least 3 (Vulkan/Metal/WebGL2), and the rest of the issues are fixable over time and with more work done on both Bevy's side and the library and tooling side.
Sometimes I wish we went with just Vulkan+Metal and could drop down to lower level stuff, get access to new features, and just generally not have to deal with extra layers and immature tooling. But I still think it's the right choice for the project overall. Discalimer: just my own opinion, I don't represent the project.
> Also, have you thought of teaming up with anyone who is explicitly teaching webgpu / wgsl? Seeing someone create a rust perspective course on learning webgpu could be nice.
Learn wgpu (https://sotrh.github.io/learn-wgpu) provides a nice intro to WebGPU/WGSL. I don't think there's really anything Bevy specifically would be able to provide. Once you wrap your head around the APIs themselves, generally the hard part of graphics programming is dealing with the boilerplate, and the actual 3D rendering techniques themselves irrespective of the API you write in.
That said, there's a few improvements I've though about contributing to learn wgpu to cover the more advanced side of things (compute shaders, storage resources, alignment rules, etc), but I haven't had time lately.