3 ms·

Yes but that’s where WebGPU really shines though isn’t it? Writing a render graph system (or any reasonably complex renderer that at least does several passes)

Yes but that’s where WebGPU really shines though isn’t it? Writing a render graph system (or any reasonably complex renderer that at least does several passes) in Vulkan means juggling with manual synchronization but writing one in WebGPU at least means you pay a little performance to not have to do that. If you want to graduate your renderer from WebGPU to Vulkan/DX12 you can pretty easily do that I imagine. So it front loads the fun and lets you postpone the boring boilerplate somewhat. Obviously rendering is always going to be about managing dozens of descriptor sets and pipelines and controlling which resources are written and copied when and where. But WebGPU strikes a pretty good balance for complexity I think.

pjmlp 2y ago
No you can't, because you will need to rewrite all shaders anyway, unless already using the approach to use something else to generate WGSL. It isn't because of fun that most Web 3D frameworks like Threejs, Babylonjs and PlayCanvas provide their own shading abstractions, three shading languages to target now.
- alkonaut 2y ago
  If you write a rust+wgpu renderer now, your options are already Rust, glsl, wgsl (and probably more). You could do Spir-V too on webgpu so long as you stick to desktop. I'm sure we'll see people load glsl on webgpu on the web too. Any reasonably complex renderer will include shader generation/reflection/translation and so on. Just having a hole where you can plug vanilla hlsl/glsl shaders seems almost impossible.
  - pjmlp 2y ago
    I rather use WebGPU, on the Web, using it for native is always going to be playing catchup with middleware engines that don't have to worry about targeting a 2016 hardware design, as minimum viable product across all major native APIs, and with browser sandboxing in mind. Although it appears to be the next managed 3D API for Android userspace, as communicated at SIGGGRAPH, then again it is better than being stuck with GL ES 3.x as it is now. So a matter of perspective I guess.

pjmlp 2y ago

No you can't, because you will need to rewrite all shaders anyway, unless already using the approach to use something else to generate WGSL. It isn't because of fun that most Web 3D frameworks like Threejs, Babylonjs and PlayCanvas provide their own shading abstractions, three shading languages to target now.

alkonaut 2y ago
If you write a rust+wgpu renderer now, your options are already Rust, glsl, wgsl (and probably more). You could do Spir-V too on webgpu so long as you stick to desktop. I'm sure we'll see people load glsl on webgpu on the web too. Any reasonably complex renderer will include shader generation/reflection/translation and so on. Just having a hole where you can plug vanilla hlsl/glsl shaders seems almost impossible.
- pjmlp 2y ago
  I rather use WebGPU, on the Web, using it for native is always going to be playing catchup with middleware engines that don't have to worry about targeting a 2016 hardware design, as minimum viable product across all major native APIs, and with browser sandboxing in mind. Although it appears to be the next managed 3D API for Android userspace, as communicated at SIGGGRAPH, then again it is better than being stuck with GL ES 3.x as it is now. So a matter of perspective I guess.