8 ms·

Porting WebGL Shaders to WebGPU

88 points by AshleysBrain 5y ago

skinner_ 5y ago
> GLSL supports the ternary ?: operator. WGSL does not support this, but provides the built-in function select(falseValue, trueValue, condition) which does much the same thing (although mind that parameter order!). I'd really like to hear a justification for that parameter order. To me it seems like the 4th best option out of 6.
- jamienicol 5y ago
  It could be because it matches the order of glsl's `mix()`. Not sure why glsl chose that order, though perhaps you might find it less unintuitive for an interpolation than a select. (Mix acts as a select rather than interpolation when the third argument is a boolean)
  - skinner_ 5y ago
    That makes much sense, thanks! But then why didn't they call it mix() or lerp() or interpolate()? I would have immediately spotted the logic behind it. EDIT: I think I get it, there also a mix() with a different type signature but same parameter order.
- kevingadd 5y ago
  lerp(zero, one, t) -> select(falseValue, trueValue, condition ? 1.0 : 0.0)
jabl 5y ago
As a non-web-developer, I'm kinda excited about WebGPU. Specifically WebGPU native, that has potential to be a portable modern 3D graphics API without the difficulty of using Vulkan or DX12.
- astlouis44 5y ago
  What game engine do you use? UE4 or Unity?
  - jabl 5y ago
    I'm not a game developer, so neither.
- yissp 5y ago
  Agree, it gives you pretty low-level access if you need it, but you can still draw a triangle in under 100 lines, e.g. https://github.com/morzel85/webgpu-wgsl-hello-triangle https://github.com/morzel85/webgpu-wgsl-hello-triangle
- pjmlp 5y ago
  It can only expose a subset of their capabilities. Don't expect using mesh shaders on WebGPU for example.
  - slimsag 5y ago
    I'll say I am definitely biased in favor of WebGPU up front[2]. WebGPU is focused on landing 1.0 currently, so yes, more features are not on the immediate roadmap. But they've been considering/investigating adding support for this before mesh shaders in DX12 were even finalized[0] so it's not like there is some "we cannot / will not expose that functionality" mandate going on here. Despite its name, WebGPU is actually pretty much a 1:1 mapping of what is commonly available across APIs. Separately, AMD doesn't support mesh shaders in Vulkan either, in fact Vulkan doesn't at all outside of a Nvidia extension from what I understand - and it sounds like there are some concerns from Khronos about whether they even map to all GPU architectures in a reasonable way at all.[1] If you want to argue "but by dropping to the level of DX12, Vulkan, Metal, etc. I can use some very specific new features" that's totally true, but you can do that with WebGPU native too: after all, Dawn and other WebGPU implementations are just abstractions over those 3 APIs. One can just as easily hop into their code and add your own extension to make use of Mesh shaders in DX12, I can say that at least Dawn's codebase is set up to allow for such extensions from what I've seen. [0] https://github.com/gpuweb/gpuweb/issues/445 https://github.com/gpuweb/gpuweb/issues/445 [1] https://github.com/KhronosGroup/Vulkan-Docs/issues/1423#issuecomment-754322730 https://github.com/KhronosGroup/Vulkan-Docs/issues/1423#issu... [2] https://devlog.hexops.com/2021/mach-engine-the-future-of-graphics-with-zig https://devlog.hexops.com/2021/mach-engine-the-future-of-gra...
AshleysBrain 5y ago
Sorry about the formatting at the top. An unexpected problem with the blog system on our website! The rest of it looks OK though.
NiekvdMaas 5y ago
Is 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?
- pjmlp 5y ago
  Not at all, it took 10 years for WebGL 2.0 to be generally available, and WebGPU is with luck reaching MVP 1.0 in 2022 on Chrome, let alone anywhere else.
- klodolph 5y ago
  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.
- modeless 5y ago
  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.
  - hajile 5y ago
    It is currently shipping behind a flag in desktop versions of Chrome (and all its derivatives), Safari, and Firefox. It is also shipping behind a flag in Firefox for Android. I don't think it's too far out from finally shipping. The biggest boon would be for mobile devs to help avoid the 30% store tax, but this is also the reason why mobile Chrome and mobile Safari (especially Safari) tend to lag behind in major ways.
lainga 5y ago
The 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 https://github.com/gpuweb/gpuweb/issues/2207
- devit 5y ago
  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.
  - djxfade 5y ago
    Javascript also has `let`. It's basically like var, but doesn't get hoisted. And can't be unassigned once assigned.
jak6jak 5y ago
Really glad you made this article. Do you guys use rust for webGPU?
Jasper_ 5y ago
I 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/e15f8045cf2622e1dc383e924ebe7ca25982ec0b/src/SourceEngine/Materials.ts#L1104-L1948 https://github.com/magcius/noclip.website/blob/e15f8045cf262... [1] https://github.com/gfx-rs/naga/ https://github.com/gfx-rs/naga/
- wrnr 5y ago
  Cool project, there is also someone working on making wgsl and glsl together: https://github.com/scoopr/naga-include-poc https://github.com/scoopr/naga-include-poc
- saurik 5y ago
  Why do you do this translation at runtime--causing every user to have to re-execute it--instead of at compile-time? Is there some kind of per-user optimization this makes possible?
  - mrec 5y ago
    Not GP, but shader translation depends heavily on device capabilities and the current pipeline state. In principle I think it's possible to cache a lot of this on the client, so that it only has to be run once per install (or per device fingerprint change) rather than once per execution, but I don't think that's implemented yet.
astlouis44 5y ago
Our team is working to build out support for Unreal Engine 4 and Unreal Engine 5 to support WebGPU, so game developers and real-time 3D developers can export their creations to the web at near native performance and access features like computer shaders. Long term goal is to disrupt Steam and the App Stores. We're also working on WebXR support to enable UE VR apps on the web. If anyone is interested and wants to learn more, you can join our Discord here: https://discord.gg/zUSZ3T8 https://discord.gg/zUSZ3T8
- Impossible 5y ago
  It seems like you aren't associated with Epic? What's the long term outcome here? Have Epic take your PRs? Get hired\acquihired (it's unclear if you are a company or a group of hobbyists)? It seems like when WebGPU is production ready Epic will support it as well as WebXR... Epic's goal is very obviously to disrupt Steam and app stores as well... Ignore all of this if you actually are an Epic employee of course :)
  - astlouis44 5y ago
    Just to clarify, we're a funded startup and we've already had calls with them showcasing our platform. The goal is to get our SDK and tools in the hand of every UE developer out there.
- ianlevesque 5y ago
  As a gamer though, why would I want to play any of these developers' games through the browser instead of Steam?
  - kaetemi 5y ago
    Yep. I don't see this game-in-the-browser thing taking off anytime soon for anything serious. Player retention, and immersion, are terrible. Casual 'adware' games, maybe.
  - hunterb123 5y ago
    To try it out? Also to play or check in on a friend's computer or a public computer. The ease of visiting a game like a website is sometimes preferred, depends on the game. There's a game where the web client is mainly used to view streams of other players (instead of streaming video they mirrored the same packets they received/sent to your web client)
paulgb 5y ago
Good article, I was looking for a resource like this when I was experimenting with WGSL. I ended up writing a short cheat sheet that might be useful to others here: https://github.com/paulgb/wgsl-cheat-sheet https://github.com/paulgb/wgsl-cheat-sheet
slx26 5y ago
My main worry with WebGPU is the dependence with Javascript. If I understand it correctly, you can't use web APIs nor stuff like WebGPU directly through web assembly anyway, so there's always a javascript glue layer involved. Now, I know some languages like Rust have decent bindings that hide all that, but I wonder about the performance cost of that glue. Has someone measured it, or estimated how better we could go without it? Or am I completely wrong about this? Or are there clear plans to make this better/disappear? (Though in my brief research I didn't find anything like it).
- hunterb123 5y ago
  https://github.com/WebAssembly/WASI/issues/53 https://github.com/WebAssembly/WASI/issues/53
- modeless 5y ago
  WebGPU is a less chatty API than WebGL. You can kick off a huge amount of GPU computation with just a couple of function calls. The overhead of the function calls themselves is usually not a big issue. That said, I know there has been work in Chrome to make these calls more efficient for WebGL and I think the overhead is actually small.
- wrnr 5y ago
  The same WebGPU API can be used as a cross platform layer to do graphics, no js needed. For example rust's wgpu can just be used without a browser.
RantyDave 5y ago
Semi-related: does anyone have WebGPU running on an M1 Mac? Pretty sure it "can be done" but the appropriate experimental options are not even there on either Safari or Chrome...
- kangz 5y ago
  WebGPU is enabled by default in Chrome on Mac as part of the WebGPU Origin Trial (https://web.dev/gpu https://web.dev/gpu). We didn't really test on M1 Macs but several people reported it just works.
  - RantyDave 5y ago
    I got it going by passing "--enable-unsafe-webgpu" actually on the command line. Thanks.
jeroenhd 5y ago
As someone who's never used this API: is there some kind of permission prompt for this before websites start trying to use my GPU for crypto mining? Most CPU crypto miners were basically worthless, but GPU power is a whole lot more powerful.
- ferdowsi 5y ago
  No permission prompt, just as there is no permission prompt for WebGL (which already enables crypto mining on your GPU). https://arxiv.org/pdf/1904.13071&ved=2ahUKEwipqPGblenzAhWDbs0KHQpICZsQFnoECAQQAQ&usg=AOvVaw14FCjS4dT6yPRBNzu0lZZt https://arxiv.org/pdf/1904.13071&ved=2ahUKEwipqPGblenzAhWDbs...
  - jeroenhd 5y ago
    I see. That is somewhat worrying. However, the authors of the paper do state that there are significant drawbacks to the WebGL API that I believe WebGPU would solve, notably by its direct access to compute resources. I suppose I'll just be disabling these APIs until I can find a personal use for them, then.
a_c 5y ago
As someone new to the WebGL scene, can someone shed light on what are the motivations in porting WebGL to WebGPU?
- gugagore 5y ago
  Check out another comment: https://news.ycombinator.com/item?id=29002748 https://news.ycombinator.com/item?id=29002748

88 points by AshleysBrain 5y ago

> GLSL supports the ternary ?: operator. WGSL does not support this, but provides the built-in function select(falseValue, trueValue, condition) which does much the same thing (although mind that parameter order!). I'd really like to hear a justification for that parameter order. To me it seems like the 4th best option out of 6.

jamienicol 5y ago
It could be because it matches the order of glsl's `mix()`. Not sure why glsl chose that order, though perhaps you might find it less unintuitive for an interpolation than a select. (Mix acts as a select rather than interpolation when the third argument is a boolean)
- skinner_ 5y ago
  That makes much sense, thanks! But then why didn't they call it mix() or lerp() or interpolate()? I would have immediately spotted the logic behind it. EDIT: I think I get it, there also a mix() with a different type signature but same parameter order.
kevingadd 5y ago
lerp(zero, one, t) -> select(falseValue, trueValue, condition ? 1.0 : 0.0)

jabl 5y ago

As a non-web-developer, I'm kinda excited about WebGPU. Specifically WebGPU native, that has potential to be a portable modern 3D graphics API without the difficulty of using Vulkan or DX12.

astlouis44 5y ago
What game engine do you use? UE4 or Unity?
- jabl 5y ago
  I'm not a game developer, so neither.
yissp 5y ago
Agree, it gives you pretty low-level access if you need it, but you can still draw a triangle in under 100 lines, e.g. https://github.com/morzel85/webgpu-wgsl-hello-triangle https://github.com/morzel85/webgpu-wgsl-hello-triangle
pjmlp 5y ago
It can only expose a subset of their capabilities. Don't expect using mesh shaders on WebGPU for example.
- slimsag 5y ago
  I'll say I am definitely biased in favor of WebGPU up front[2]. WebGPU is focused on landing 1.0 currently, so yes, more features are not on the immediate roadmap. But they've been considering/investigating adding support for this before mesh shaders in DX12 were even finalized[0] so it's not like there is some "we cannot / will not expose that functionality" mandate going on here. Despite its name, WebGPU is actually pretty much a 1:1 mapping of what is commonly available across APIs. Separately, AMD doesn't support mesh shaders in Vulkan either, in fact Vulkan doesn't at all outside of a Nvidia extension from what I understand - and it sounds like there are some concerns from Khronos about whether they even map to all GPU architectures in a reasonable way at all.[1] If you want to argue "but by dropping to the level of DX12, Vulkan, Metal, etc. I can use some very specific new features" that's totally true, but you can do that with WebGPU native too: after all, Dawn and other WebGPU implementations are just abstractions over those 3 APIs. One can just as easily hop into their code and add your own extension to make use of Mesh shaders in DX12, I can say that at least Dawn's codebase is set up to allow for such extensions from what I've seen. [0] https://github.com/gpuweb/gpuweb/issues/445 https://github.com/gpuweb/gpuweb/issues/445 [1] https://github.com/KhronosGroup/Vulkan-Docs/issues/1423#issuecomment-754322730 https://github.com/KhronosGroup/Vulkan-Docs/issues/1423#issu... [2] https://devlog.hexops.com/2021/mach-engine-the-future-of-graphics-with-zig https://devlog.hexops.com/2021/mach-engine-the-future-of-gra...

AshleysBrain 5y ago

Sorry about the formatting at the top. An unexpected problem with the blog system on our website! The rest of it looks OK though.

NiekvdMaas 5y ago

Is 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?

pjmlp 5y ago
Not at all, it took 10 years for WebGL 2.0 to be generally available, and WebGPU is with luck reaching MVP 1.0 in 2022 on Chrome, let alone anywhere else.
klodolph 5y ago
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.
modeless 5y ago
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.
- hajile 5y ago
  It is currently shipping behind a flag in desktop versions of Chrome (and all its derivatives), Safari, and Firefox. It is also shipping behind a flag in Firefox for Android. I don't think it's too far out from finally shipping. The biggest boon would be for mobile devs to help avoid the 30% store tax, but this is also the reason why mobile Chrome and mobile Safari (especially Safari) tend to lag behind in major ways.

lainga 5y ago

The 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 https://github.com/gpuweb/gpuweb/issues/2207

devit 5y ago
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.
- djxfade 5y ago
  Javascript also has `let`. It's basically like var, but doesn't get hoisted. And can't be unassigned once assigned.

jak6jak 5y ago

Really glad you made this article. Do you guys use rust for webGPU?

Jasper_ 5y ago

I 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/e15f8045cf2622e1dc383e924ebe7ca25982ec0b/src/SourceEngine/Materials.ts#L1104-L1948 https://github.com/magcius/noclip.website/blob/e15f8045cf262... [1] https://github.com/gfx-rs/naga/ https://github.com/gfx-rs/naga/

wrnr 5y ago
Cool project, there is also someone working on making wgsl and glsl together: https://github.com/scoopr/naga-include-poc https://github.com/scoopr/naga-include-poc
saurik 5y ago
Why do you do this translation at runtime--causing every user to have to re-execute it--instead of at compile-time? Is there some kind of per-user optimization this makes possible?
- mrec 5y ago
  Not GP, but shader translation depends heavily on device capabilities and the current pipeline state. In principle I think it's possible to cache a lot of this on the client, so that it only has to be run once per install (or per device fingerprint change) rather than once per execution, but I don't think that's implemented yet.

astlouis44 5y ago

Our team is working to build out support for Unreal Engine 4 and Unreal Engine 5 to support WebGPU, so game developers and real-time 3D developers can export their creations to the web at near native performance and access features like computer shaders. Long term goal is to disrupt Steam and the App Stores. We're also working on WebXR support to enable UE VR apps on the web. If anyone is interested and wants to learn more, you can join our Discord here: https://discord.gg/zUSZ3T8 https://discord.gg/zUSZ3T8

Impossible 5y ago
It seems like you aren't associated with Epic? What's the long term outcome here? Have Epic take your PRs? Get hired\acquihired (it's unclear if you are a company or a group of hobbyists)? It seems like when WebGPU is production ready Epic will support it as well as WebXR... Epic's goal is very obviously to disrupt Steam and app stores as well... Ignore all of this if you actually are an Epic employee of course :)
- astlouis44 5y ago
  Just to clarify, we're a funded startup and we've already had calls with them showcasing our platform. The goal is to get our SDK and tools in the hand of every UE developer out there.
ianlevesque 5y ago
As a gamer though, why would I want to play any of these developers' games through the browser instead of Steam?
- kaetemi 5y ago
  Yep. I don't see this game-in-the-browser thing taking off anytime soon for anything serious. Player retention, and immersion, are terrible. Casual 'adware' games, maybe.
- hunterb123 5y ago
  To try it out? Also to play or check in on a friend's computer or a public computer. The ease of visiting a game like a website is sometimes preferred, depends on the game. There's a game where the web client is mainly used to view streams of other players (instead of streaming video they mirrored the same packets they received/sent to your web client)

paulgb 5y ago

Good article, I was looking for a resource like this when I was experimenting with WGSL. I ended up writing a short cheat sheet that might be useful to others here: https://github.com/paulgb/wgsl-cheat-sheet https://github.com/paulgb/wgsl-cheat-sheet

slx26 5y ago

My main worry with WebGPU is the dependence with Javascript. If I understand it correctly, you can't use web APIs nor stuff like WebGPU directly through web assembly anyway, so there's always a javascript glue layer involved. Now, I know some languages like Rust have decent bindings that hide all that, but I wonder about the performance cost of that glue. Has someone measured it, or estimated how better we could go without it? Or am I completely wrong about this? Or are there clear plans to make this better/disappear? (Though in my brief research I didn't find anything like it).

hunterb123 5y ago
https://github.com/WebAssembly/WASI/issues/53 https://github.com/WebAssembly/WASI/issues/53
modeless 5y ago
WebGPU is a less chatty API than WebGL. You can kick off a huge amount of GPU computation with just a couple of function calls. The overhead of the function calls themselves is usually not a big issue. That said, I know there has been work in Chrome to make these calls more efficient for WebGL and I think the overhead is actually small.
wrnr 5y ago
The same WebGPU API can be used as a cross platform layer to do graphics, no js needed. For example rust's wgpu can just be used without a browser.

RantyDave 5y ago

Semi-related: does anyone have WebGPU running on an M1 Mac? Pretty sure it "can be done" but the appropriate experimental options are not even there on either Safari or Chrome...

kangz 5y ago
WebGPU is enabled by default in Chrome on Mac as part of the WebGPU Origin Trial (https://web.dev/gpu https://web.dev/gpu). We didn't really test on M1 Macs but several people reported it just works.
- RantyDave 5y ago
  I got it going by passing "--enable-unsafe-webgpu" actually on the command line. Thanks.

jeroenhd 5y ago

As someone who's never used this API: is there some kind of permission prompt for this before websites start trying to use my GPU for crypto mining? Most CPU crypto miners were basically worthless, but GPU power is a whole lot more powerful.

ferdowsi 5y ago
No permission prompt, just as there is no permission prompt for WebGL (which already enables crypto mining on your GPU). https://arxiv.org/pdf/1904.13071&ved=2ahUKEwipqPGblenzAhWDbs0KHQpICZsQFnoECAQQAQ&usg=AOvVaw14FCjS4dT6yPRBNzu0lZZt https://arxiv.org/pdf/1904.13071&ved=2ahUKEwipqPGblenzAhWDbs...
- jeroenhd 5y ago
  I see. That is somewhat worrying. However, the authors of the paper do state that there are significant drawbacks to the WebGL API that I believe WebGPU would solve, notably by its direct access to compute resources. I suppose I'll just be disabling these APIs until I can find a personal use for them, then.

a_c 5y ago

As someone new to the WebGL scene, can someone shed light on what are the motivations in porting WebGL to WebGPU?

gugagore 5y ago
Check out another comment: https://news.ycombinator.com/item?id=29002748 https://news.ycombinator.com/item?id=29002748