Comment by raphlinus | Hacker News Reader

Comment by raphlinus | Hacker News Reader

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.

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?

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?

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?

"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).

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

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?

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/

Saved in my note, much appreciated.

Yes, I agree building a UI library from scratch is hard and probably not worthy doing (too many people tried and gave up in the middle; probably better to channel that enthusiasm on improving existing ones). I should state that more clearly. I was looking at something more modest, like a canvas implementation based on wgpu that enables others to build their UI libraries on top.

I guess it would be something like Skia, but it also sounds like a tremendous effort, and I could probably just use Skia instead. However, I guess I am not going to match what Skia has (maybe what HTML canvas has is enough?). Also, I have played with skia-safe crate but I personally feel the dev experience could be better (not to blame skia-safe, it's wonderful and even provides a build process that automatically downloads a precompiled skia library).

Thanks for pointing out Iced. I didn't know they are using wgpu under the hood. I will take a good look at their code. I have been reading nannou's code to learn how to work with wgpu. If we skip my last paragraph, I think building a UI library on top of nannou is pretty doable.

[1]: https://github.com/nannou-org/nannou

From [1]:

> When writing SPIR-V, you can’t have two integer types of the same width. Or two texture types that match. All non-composite types have to be unique for some reason. We don’t have this restriction in Naga IR, it just doesn’t seem to make any sense. For example, what if I’m writing a shader, and I basically want to use the same “int32” type for both indices and lengths. I may want to name these types differently

This doesn't really make sense for IR. IR is not meant to be human writeable. It's meant to be generated by a compiler. So, having a one to one mapping between concept and name in the IR is a feature, not a bug.

Honestly, WGSL just repeats the JavaScript mistake: where we should have started with something like WASM instead of JavaScript. And JS could have been just one of the many languages that targeted WASM.

We were this close to not repeating this mistake by adopting an IR language (SPIR-V) for WebGPU, but then that got abandoned mostly for political reasons. Too bad. Now we get to write transpilers and hacks for decades to come, just like web people have been trying to paper over JS problems for decades.

> This doesn't really make sense for IR. IR is not meant to be human writeable. It's meant to be generated by a compiler. So, having a one to one mapping between concept and name in the IR is a feature, not a bug.

Do you consider the name for a type to be a part of the concept? SPIR-V doesn't. Overall, if you wanted one-to-one mapping, at least that would be consistent. But SPIR-V decided to require this only for simple types, while you can still have duplicate composite types.

> Honestly, WGSL just repeats the JavaScript mistake: where we should have started with something like WASM instead of JavaScript. And JS could have been just one of the many languages that targeted WASM.

We don't know if Web would be nearly as successful if it started with WASM instead of JS. The ability to just open a text editor and make a web page has served well in the early days.

> We were this close to not repeating this mistake by adopting an IR language (SPIR-V) for WebGPU, but then that got abandoned mostly for political reasons.

Look at the situation today: the very same people who were rooting for SPIR-V are currently introducing features the diverge WGSL away from SPIR-V, further and further. It's quite telling, I think. The moral of the story is: regardless of reasons (which we can argue a ton), WG members admit that what we ideally need is not SPIR-V, and this is supported by the way WGSL is shaping.

> We don't know if Web would be nearly as successful if it started with WASM instead of JS. The ability to just open a text editor and make a web page has served well in the early days.

And you would be able to do that just fine. All you'd need to do is include the JS compiler (helpfully hosted at http://cdn.google.com/ecmascript-2015.wasm) in the <head> of the HTML file's script tag, open a text editor and type away. Or, you know, include a more sane language like typescript, or python. Heck even lisp if you're so inclined. Or, and this is like totally crazy, but say you need performance, and want tight control over memory layout and allocations, then go for C or rust! Oh and no need to minify your JS. Just ship the WASM precompiled. Save on browser compilation time and network bytes at the same time. So long as you generate WASM that the browser understands use whatever lang makes you happy. Type it right into a text editor and include the compiler in the head of the HTML. Easy peasy.

It's without question that JS has held back web development for decades. Of course, people didn't know any better back then, and really JS was added as almost an afterthought, so we can't really blame them for getting it wrong.

We do know better now though. And still we get WGSL. Looking forward to 2041, when we finally get WGASM. The hottest new thing in web gpu technologies.

We will be back at native apps with networking protocols by then. :)

Welcome to the design by comittee APIs.

In restrospective I wasted a couple of years of my life beting on OpenGL, and keep seeing the same errors in all Khronos related APIs.

It is not only WebGPU, check how many extensions Vulkan has already.

Then there is OpeCL C++ versus SYSCL, OpenCL 3.0 is actually 1.2 rebooted,...

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.

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

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.

Could you explain blacklisting? What does this mean? Couldn't there be an API to probe whatever information the developer needs to determine acceleration?

Browsers blacklist driver/hardware combinations when they are known to be buggy.

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.

Reply on news.ycombinator.com