First Public Working Drafts: WebGPU and WebGPU Shading Language

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.

I took the opportunity to base my visual computing project for this semester on the Rust WebGPU implementation (wgpu-rs). Working with it is very nice, compared to OpenGL and Vulkan. The biggest pain point right now is WGSL because it still is a moving target, but it's already good enough to work with in my case. The repository for my project currently lacks any info at all unfortunately: https://github.com/niklaskorz/linon/

It is a ray caster that I plan to evolve into a nonlinear ray caster where the viewing rays travel along a vector field which thus distorts the image. You can enable the nonlinear mode by setting the "linear_mode" constant in "src/compute.wgsl" to false. I also implemented hot reloading for the shaders, which made experimenting a lot easier. The project doesn't have any non-Rust dependencies, so giving it a go is as easy as "cargo run" in the repository directory. For an idea of what I'm aiming for, see the "Visualizing Strange Worlds" paper by Eduard Gröller from 1995: https://www.cs.drexel.edu/~david/Classes/Papers/Groller95.pd...

You can also drag&drop .obj models to load them, but I advise you to only use small models (500 triangles max) in linear mode and completely avoid it in nonlinear mode right now, as the performance is really bad at the moment. :) I'm looking into acceleration structures next, so hopefully this will improve.

You can trigger some insane GPU bugs from just user-space programs, and while using the WebGPU Python wrapper, I’ve managed to completely corrupt the screen buffer (which required a restart), completely frozen the GPU, and can consistently trigger denial of service attacks. I can guarantee that WebGPU opens a huge attack space that is relatively unexplored.

For those unfamiliar with the W3C:

Working Drafts are essentially just "drafts with stable URLs for review purposes and historical interest".

First Public Working Drafts also have consequences under the W3C Patent Policy, primarily starting a timer under which any participant of the group has to say they wish to exclude any patents they hold from the W3C royalty-free grant.

Idk if WebGPU will ever be fully supported by enough browsers to be viable for the web. Even if it is eventually supported people are saying it will take 10+ years.

I do think WebGPU can be a great cross-platform compute shader framework outside of the web. My experience with compute shaders is that they're really really platform specific: you need not just the right OS, but also the right graphics chip. It would be nice to write cross-platform high-end 3D apps without relying on Unity or Unreal.

Also, hopefully WebGPU has better debugging tools (if they're even possible). I tried GPU programming before but it's a mess: almost every example I tried to run crashed terribly (e.g. system reboot), and even at best, I couldn't get much debugging output other than "code = problem".

I imagine that this, in addition to WebAssembly, could lead in the future to playing more complex games from the browser with the benefit of being platform agnostic (in kind of device, hardware architecture, OS) as long as the browser, the OS, and the hardware is compatible. Am I wrong?

Maybe worth noting that Deno 1.8 has WebGPU support[1]. Deno's quest to be the web-platform compatible alternative to Node is expansive & impressive!! I have high hopes for it!

[1] https://deno.com/blog/v1.8 https://news.ycombinator.com/item?id=26323600

For anyone unfamiliar with WebGPU:

It's a successor to WebGL, along the lines of newer graphics APIs like Metal/Vulkan/DirectX 12. Google and Mozilla are also developing a C-compatible library that should be available as an OpenGL alternative for native code.

So if successful it might end up as the most convenient cross-platform graphics library (across desktop/mobile/the web). Currently the alternatives in this space are:

- OpenGL (which Apple has deprecated and is stuck on an older version on their platforms)

- Vulkan, which is the lowest level and most difficult to get started on of the APIs, and also doesn't work on the web, but is supported on Apple systems by using the MoltenVK library to translate it to Metal

- some non-standardized libraries written by third party developers like bgfx and Oryol.

For the shading language they settled on a text based language designed to be easily translatable to/from Vulkan SPIR-V bytecode, with the goal of being able to re-use existing shader compilation toolchains (and most of the work put in to SPIR-V), while still having the ability to write/read shaders without a shader compiler. Also SPIR-V files are fairly large and apparently don't compress well with standard algorithms (see SMOL-V) so the text based format should probably be more efficient to transmit on the web.

I'm looking at the complex specs of the shading language which accomplish almost the same thing as other modern high level shading languages, and thinking is there any possibility we'll reach a state of consensus on a single unified GPU graphics interface? Right now things seem to go more fragmented instead of unified, we moved away from "cross-platform" OpenGL to extremely vendor specific Vulkan, Metal, D3d and WebGPU, looks like cross platform graphics programming is becoming more and more far away, have to rely on abstraction layer which are often huge dependencies and tedious to develop / maintain.

---

[[stage(fragment)]]

fn main() -> [[location(0)]] vec4<f32> {

    return vec4<f32>(0.4, 0.4, 0.8, 1.0);

}

---

That is very ugly and full of noise, c'mon people, that's one thing to like rust, but let's not import its ugly and noisy cluttered syntax..., it took me few seconds to understand what's going on there

---

var<private> x: f32;

---

let's not confuse things even more, we have vec4<f32> already, C'MON PEOPLE

You should check out the Rust WebGPU implementation https://github.com/gfx-rs/wgpu-rs

I was looking under security and I don’t see any mention of misuse, but that can also be hard to identify.

Potential misuse should not stop WebGPU from moving forward, but isn’t there a concern that the make JavaScript injection attacks more attractive? Rather than buying and operate a crypto mining setup it now becomes more attractive to attempt to utilize the GPUs of unsuspecting web users. Or am I misunderstanding how much of the GPU this will grant you access to?

I find interesting that WGSL is clearly influenced by Rust.

GSL and WGSL are completely unrelated, apparently time to rewrite shaders.

And in what concerns debugging, better get good at understanding what is the actual application code and browser own rendering engine, as the best solution keeps being to use native GPGPU debuggers.

So the long march towards the "other" future continues ...

Failure #1: to get operating systems to ever agree on a truly common API for most modern computing

Failure #2: to implement a write-once, run-anywhere language capable of being used for the majority of software development (mostly because the main efforts at doing so all rely on VMs that come with their own costs and benefits)

Conclusion: just give up. Postulate the existence of a virtual machine inside a web browser. Spend a decade or three slowly extending the scope of that virtual machine. Put in a little bit of effort to persuade people that this new, evolving VM is the new key to "write once, run anywhere".

Result: a new platform, distinct from all the rest (i.e. "native") with its own costs and benefits.

Whoo-hoo.

It would be cool if the shading document has an example ... just diving into details makes it hard to get the flavor. Anyone have a smallish SL example?

The moment Google made js throttling to kill miners, miners switched to WebGL, and WASM.

A WebGPU miner will be coming out the same second it is adopted.

the performance is pretty impressive on some devices https://news.ycombinator.com/item?id=26333369

I fear this does nothing to prevent fingerprinting via your GPU.

Yuck. So now there's 3 of them. What's wrong with GLSL? HLSL? Somebody link that xkcd about competing standards.

But seriously, why do they reinvent the wheel? Either make javascript work on the GPU (because that's the language of the web, just like C++ and Cuda go hand in hand), or just stick with HLSL.