Porting WebGL Shaders to WebGPU
construct.net
Porting WebGL Shaders to WebGPU
1–10 of 64 posts
Re: Porting WebGL Shaders to WebGPU
#2Sorry about the formatting at the top. An unexpected problem with the blog system on our website! The rest of it looks OK though.
Re: Porting WebGL Shaders to WebGPU
#3Is there any advantage at this point in time to port a game to WebGPU? Is it going to run faster, or have broader browser support in the future?
Re: Porting WebGL Shaders to WebGPU
#4The confusion with `let` and `var` does seem confusing from a JS perspective, but it seems to be so that you can have the same mental model between WGSL and SPIR-V:
Re: Porting WebGL Shaders to WebGPU
#5The confusion with `let` and `var` does seem confusing from a JS perspective, but it seems to be so that you can have the same mental model between WGSL and SPIR-V: https://github.com/gpuweb/gpuweb/issues/2207
It seems to be a syntax mismash between Rust, which uses `let` and `let mut`, and JavaScript, which uses `const` and `var`, giving WGSL's `let` and `var`, probably chosen because they are the shortest.
Re: Porting WebGL Shaders to WebGPU
#6Really glad you made this article. Do you guys use rust for webGPU?
Re: Porting WebGL Shaders to WebGPU
#7Is there any advantage at this point in time to port a game to WebGPU? Is it going to run faster, or have broader browser support in the future?
It's like a web version of Vulkan / Metal / DX12, in that it's designed to more directly represent how modern GPUs work. If you are happy with your WebGL performance, by all means, continue using it. However, it can sometimes be a bit hard to understand what is going wrong (performance-wise) in an OpenGL or WebGL application... the underlying implementation will sometimes paper over its limitations. You can accidentally stray from the high-performance paths.
There are some feature differences, like how WebGPU has compute shaders.
Re: Porting WebGL Shaders to WebGPU
#8I took a very different approach for porting my WebGPU shaders over: I have far too many shaders to port (sometimes pretty massive ones! [0]), so I used Naga [1] at to runtime-translate my GLSL shaders to WGSL. I had to get involved a bit upstream to fix quite a few different bugs in the implementation, but once I got it working I was really happy with the result. It's quite fast, it compiles to a pretty light-weight WebAssembly module, and it works surprisingly well.
[0] https://github.com/magcius/noclip.website/blob/e15f8045cf262... [1] https://github.com/gfx-rs/naga/
Re: Porting WebGL Shaders to WebGPU
#9Is there any advantage at this point in time to port a game to WebGPU? Is it going to run faster, or have broader browser support in the future?
At this time I would recommend WebGL 2. WebGL 2 is finally supported in all major browsers now that Safari 15 shipped. WebGL 2 has some of the benefits mentioned in the article for WebGPU, such as a reasonable minimum texture size (2048 vs 64 in WebGL 1) and the built-in ability to get the size of a texture in a shader.
WebGPU will not ship in all browsers for some time, and when it does it will not have have wider hardware support than WebGL 2. It has the potential to be faster in some cases, but the difference is unlikely to matter for most. The big draw of WebGPU should be compute shader support, though it is definitely possible to do compute work in WebGL 2 either with transform feedback or just regular shaders.
Re: Porting WebGL Shaders to WebGPU
#10I took a very different approach for porting my WebGPU shaders over: I have far too many shaders to port (sometimes pretty massive ones! [0]), so I used Naga [1] at to runtime-translate my GLSL shaders to WGSL. I had to get involved a bit upstream to fix quite a few different bugs in the implementation, but once I got it working I was really happy with the result. It's quite fast, it compiles to a pretty light-weight…
Cool project, there is also someone working on making wgsl and glsl together: https://github.com/scoopr/naga-include-poc