4 ms·

I've been doing something of a deep dive into the suitability of WebGPU and WGSL for "serious" compute tasks (ie potentially competing with CUDA). Here's my tak

I've been doing something of a deep dive into the suitability of WebGPU and WGSL for "serious" compute tasks (ie potentially competing with CUDA). Here's my take on the current state. The upside is that it's very pleasant to program compared with existing APIs, and is portable. Even when the GPU doesn't quite meet the requirements, it's possible to polyfill compute shaders with SwiftShader. As this standard becomes more mature, it will be reasonable to expect that it will be correct and performant pretty much everywhere. Note that both web and non-web implementations are viable. The biggest drawback is that the "MVP" covers the basics of compute shaders but not the advanced features. It's roughly equivalent to DX11 / Shader Model 5, which is of course good for compatibility on pre-Windows 10 devices. It's missing subgroup operations, scalar types other than 32 bits, an explicit memory model, and some other goodies. This potentially leaves quite a bit of performance on the table, but that will depend on the exact workload. For example, machine learning inference workloads will probably suffer considerably due to the lack of f16. Thus, if you want to ship something based on compute shaders today, it makes sense to build your own portability layer on top of existing APIs such as Vulkan, DX12, and Metal. I do think WebGPU is an excellent on-ramp to learning compute shader programming, as it will get stronger over time, and concepts will transfer to other APIs as listed above. Watch my Twitter feed for more depth on the points I listed above.

longstation 5y ago
Could someone correct me? I am pretty new to graphics programing but I was learning wgpu (the Rust binding of WebGPU) the other day. I was under the impression that the shader language is GLSL (version 450) and it is then converted into SPIR-V. Would those limitations still apply with SPIR-V?
- lights0123 5y ago
  The shader language you write in does not matter, as it can be converted into whatever format the API expects. wgpu historically accepts SPIR-V, but the latest version released ~a month ago has moved to WGSL as much as it can in the examples. Have you upgraded yet?
  - longstation 5y ago
    I haven't. I didn't realize the move. Looks like I need to find some new learning material. BTW, do you know any up-to-date tutorials?
  - raphlinus 5y ago
    "Does not matter" is overstating the case. There are lots of tools for converting between shader languages (naga, spirv-cross, glslangValidator, dxc), but these conversions aren't 100% lossless and not all shader languages have the same capabilities. To give one example, HLSL (Shader Model 6) has a fairly complete set of subgroup (wave) operations, but is missing nonuniform shuffle. Another gap is that only GLSL (Vulkan flavor) has support for explicit memory semantics. Of course, WGSL currently has none of this, as it's something of a lowest common denominator. In the game world, it is very common to write shaders in HLSL because of good support on Windows, and then use the tools mentioned above to translate into other shader languages. I explored this for my own work but ultimately settled on GLSL because it allows access to advanced features. Fans of shader languages should also be aware of rust-gpu, which promises to be considerably higher level; most existing shader languages show their clear lineage to C (through Cg).
- raphlinus 5y ago
  This is still in transition, and the full story is complicated. The official shader language for WebGPU is WGSL, and that will almost certainly be the only language supported for web deployment. Originally this was going to be a textual representation that had exactly the same semantics ("bijective") as SPIR-V, but that's been diverging a bit[1]. Only very recently have atomics been added to the spec, and implementations are still catching up. Because WGSL is still under construction, for native deployment, wgpu supports SPIR-V shaders as well. On Vulkan, those are passed pretty much straight through to the GPU driver (with some validation). On DX12 and Metal, those are translated into HLSL and MSL, respectively. Until recently, in wgpu, all those translations were handled by spirv-cross. More recently, the new naga crate is doing those translations. Again, this is under construction and not everything works yet. [1]: https://kvark.github.io/spirv/2021/05/01/spirv-horrors.html https://kvark.github.io/spirv/2021/05/01/spirv-horrors.html
  - longstation 5y ago
    I see. Thank you for the detailed information. I will read the linked content. I don't know if this is a good place to ask. But I was interested in wgpu because of the interest in building a cross-platform non-web UI library. I read a few of your articles and also looked at druid. I am pretty new to it and there seems to be no books on this topic. Do you have any recommendations?
    - raphlinus 5y ago
      Yes: don't. It's very hard. More seriously. There is very good reason to be encouraged about wgpu as a cross-platform low-level GPU drawing interface for UI work. There are already successful UI toolkits using it, of which probably the most impressive is iced. For 2D graphics in general, a good starting point is Diego Nehab's 2D graphics course. It has links to a bunch of resources including papers on GPU rendering. Of course, I'm working on my own stuff, which in time I hope will become a very strong foundation for building things such as UI toolkits, but it's not ready yet, and of course you're already aware of it. [1]: http://w3.impa.br/~diego/teaching/vg/ http://w3.impa.br/~diego/teaching/vg/
- deleted 5y ago
  [deleted]
pjmlp 5y ago
Given the slow uptake on WebGL and the hit-and-miss on browser hardware support, I fear it will take several years for WebGPU to be an usable target beyond learning purposes.
mrec 5y ago
Do we know yet what the evolution and conditional-support mechanism is going to look like? Will there be "feature levels" like D3D, or ad-hoc independent extensions like interim GL, or some mix of the two? Now that basically all relevant browsers are evergreen (sit down, IE11) I wonder whether an API roadmap could take advantage of that in a way that's less pesky than the traditional approaches.
- raphlinus 5y ago
  You'll probably be interested in section 3.6 of the spec[1], "optional capabilities." One such is timestamp queries, which I find especially annoying when they're not available. [1]: https://gpuweb.github.io/gpuweb/#optional-capabilities https://gpuweb.github.io/gpuweb/#optional-capabilities
- pjmlp 5y ago
  It will be extension spaghetti as always. Note that not even with the same browser version there are any guarantees regarding GPGPU support. A big difference between browsers and native 3D APIs is the blacklisting of client hardware/drivers, so one never knows what is actually being accelerated.
  - enos_feedler 5y ago
    Could you explain blacklisting? What does this mean? Couldn't there be an API to probe whatever information the developer needs to determine acceleration?
    - eptcyka 5y ago
      Browsers blacklist driver/hardware combinations when they are known to be buggy.

longstation 5y ago

Could someone correct me? I am pretty new to graphics programing but I was learning wgpu (the Rust binding of WebGPU) the other day. I was under the impression that the shader language is GLSL (version 450) and it is then converted into SPIR-V. Would those limitations still apply with SPIR-V?

lights0123 5y ago
The shader language you write in does not matter, as it can be converted into whatever format the API expects. wgpu historically accepts SPIR-V, but the latest version released ~a month ago has moved to WGSL as much as it can in the examples. Have you upgraded yet?
- longstation 5y ago
  I haven't. I didn't realize the move. Looks like I need to find some new learning material. BTW, do you know any up-to-date tutorials?
- raphlinus 5y ago
  "Does not matter" is overstating the case. There are lots of tools for converting between shader languages (naga, spirv-cross, glslangValidator, dxc), but these conversions aren't 100% lossless and not all shader languages have the same capabilities. To give one example, HLSL (Shader Model 6) has a fairly complete set of subgroup (wave) operations, but is missing nonuniform shuffle. Another gap is that only GLSL (Vulkan flavor) has support for explicit memory semantics. Of course, WGSL currently has none of this, as it's something of a lowest common denominator. In the game world, it is very common to write shaders in HLSL because of good support on Windows, and then use the tools mentioned above to translate into other shader languages. I explored this for my own work but ultimately settled on GLSL because it allows access to advanced features. Fans of shader languages should also be aware of rust-gpu, which promises to be considerably higher level; most existing shader languages show their clear lineage to C (through Cg).
raphlinus 5y ago
This is still in transition, and the full story is complicated. The official shader language for WebGPU is WGSL, and that will almost certainly be the only language supported for web deployment. Originally this was going to be a textual representation that had exactly the same semantics ("bijective") as SPIR-V, but that's been diverging a bit[1]. Only very recently have atomics been added to the spec, and implementations are still catching up. Because WGSL is still under construction, for native deployment, wgpu supports SPIR-V shaders as well. On Vulkan, those are passed pretty much straight through to the GPU driver (with some validation). On DX12 and Metal, those are translated into HLSL and MSL, respectively. Until recently, in wgpu, all those translations were handled by spirv-cross. More recently, the new naga crate is doing those translations. Again, this is under construction and not everything works yet. [1]: https://kvark.github.io/spirv/2021/05/01/spirv-horrors.html https://kvark.github.io/spirv/2021/05/01/spirv-horrors.html
- longstation 5y ago
  I see. Thank you for the detailed information. I will read the linked content. I don't know if this is a good place to ask. But I was interested in wgpu because of the interest in building a cross-platform non-web UI library. I read a few of your articles and also looked at druid. I am pretty new to it and there seems to be no books on this topic. Do you have any recommendations?
  - raphlinus 5y ago
    Yes: don't. It's very hard. More seriously. There is very good reason to be encouraged about wgpu as a cross-platform low-level GPU drawing interface for UI work. There are already successful UI toolkits using it, of which probably the most impressive is iced. For 2D graphics in general, a good starting point is Diego Nehab's 2D graphics course. It has links to a bunch of resources including papers on GPU rendering. Of course, I'm working on my own stuff, which in time I hope will become a very strong foundation for building things such as UI toolkits, but it's not ready yet, and of course you're already aware of it. [1]: http://w3.impa.br/~diego/teaching/vg/ http://w3.impa.br/~diego/teaching/vg/
deleted 5y ago
[deleted]

pjmlp 5y ago

Given the slow uptake on WebGL and the hit-and-miss on browser hardware support, I fear it will take several years for WebGPU to be an usable target beyond learning purposes.

mrec 5y ago

Do we know yet what the evolution and conditional-support mechanism is going to look like? Will there be "feature levels" like D3D, or ad-hoc independent extensions like interim GL, or some mix of the two? Now that basically all relevant browsers are evergreen (sit down, IE11) I wonder whether an API roadmap could take advantage of that in a way that's less pesky than the traditional approaches.

raphlinus 5y ago
You'll probably be interested in section 3.6 of the spec[1], "optional capabilities." One such is timestamp queries, which I find especially annoying when they're not available. [1]: https://gpuweb.github.io/gpuweb/#optional-capabilities https://gpuweb.github.io/gpuweb/#optional-capabilities
pjmlp 5y ago
It will be extension spaghetti as always. Note that not even with the same browser version there are any guarantees regarding GPGPU support. A big difference between browsers and native 3D APIs is the blacklisting of client hardware/drivers, so one never knows what is actually being accelerated.
- enos_feedler 5y ago
  Could you explain blacklisting? What does this mean? Couldn't there be an API to probe whatever information the developer needs to determine acceleration?
  - eptcyka 5y ago
    Browsers blacklist driver/hardware combinations when they are known to be buggy.