CobyPear

Ive been working on a webgpu 2d light simulation thingy this week and its been SO SURPRISINGLY EASY! once i got the js stuff set up to let me throw some data at the compute shader and get it back, I was golden. It even let me pass it arrays of structs, which was frankly mindblowing because when I previously dealt with webgl things, it was much more strict about what I could and couldnt do. Webgpu is amazingly cool and im glad it exists

Re 18: JS modules and import work in browsers now and it’s great. (And it works more consistently and reliably than it does in node which is funny to me.)

since the examples in the wgpu repo don't come with build scripts.

This is probably because cargo is aware of examples and so the right way to build them is to run e.g. cargo run --example hello-triangle from the top level of the repo. But that doesn’t get you the web part of things.

Except Linux has a severe driver problem with Vulkan and a lot of the Linux devices I've been checking out don't support Vulkan even now after it's been out seven years

do you mean embedded Linux? bc Vulkan is definitely widely supported on desktop

The purpose of the pipeline and bind group layouts is to explicitly declare the bindings you use in your code for future use. I believe they are needed if you are doing any kind of advanced dynamic binding of buffers and other resources to the shader. As an example from some WebGPU code I wrote, for this in the shader:

@binding(0) @group(0) var<storage, read> raw_fft: array<f32>;
@binding(1) @group(0) var<storage, read_write> smoothened: array<f32>;

I'd define the pipeline like such:

const computePipelineDesciptor = {
    compute: {
        module: computeShader,
        entryPoint: 'cm_smoother'
    },
    layout: device.createPipelineLayout({
        bindGroupLayouts:[ device.createBindGroupLayout({
            entries: [
                {
                    binding: 0,
                    buffer: {
                        type: "read-only-storage",
                    },
                    visibility: GPUShaderStage.COMPUTE
                },
                {
                    binding: 1,
                    buffer: {
                        type: "storage",
                    },
                    visibility: GPUShaderStage.COMPUTE
                }
            ]
        })]
    })
} as GPUComputePipelineDescriptor;

At some point, you want to take control from the shader compiler to more explicitly allow you to declare what exactly you want to do with your data, and that's where layouts come in.

If I were a cynical, paranoid conspiracy theorist, I would float the theory here that Apple at some point decided they wanted to leave open the capability to sue the other video card developers on the Khronos board, so they are aggressively refusing to let their code touch anything that has touched the Vulkan patent pool to insulate themselves from counter-suits. Or that is what I would say if I were a cynical, paranoid conspiracy theorist. Hypothetically.

iirc Apple has said in WebGPU meetings that they can't support SPIR-V because they can't implement Khronos specs due to confidential legal proceedings, so

Very cool post! As a webGL user maybe I need to get on this and start learning it. My only comment: you've used a picture of Steven from Steven Universe Future (2019), not his jacketless kid design from 2013.

Even with my stumbling not-in-software-dev understanding of the details this was a fascinating read. DirectX and OpenGL were just names to me that people would seem to ascribe to good/bad graphics performance at random and now I appreciate a bit more just how deeply fucked this field is for a layman to understand.

My perception is it was Direct3D, not OpenGL, which eventually managed to wrangle all of this into a standard, which really sucked if you were using a non-Microsoft OS at the time. It really seemed like DirectX (and the "X Box" standalone console it spawned) were an attempt to lock game companies into Microsoft OSes by getting them to wire Microsoft exclusivity into their code at the lowest level, and for a while it really worked.

There were four strategic goals of DirectX, with different priorities at different times:

1. Make Windows gaming competitive with the consoles, so they had the same titles.
2. Make Windows gaming better than Mac.
3. Make DirectX better than OpenGL/Linux/SGI/etc
4. Bring 3D to the Windows desktop.

#1 was basically just to make Windows a decent single(ish) platform for people doing cross-platform games (remember DirectX included things like input, audio, 2D, etc). And it worked. Lots of console games came to PC, everybody happy, no bad motives there.

Very quickly it became clear that #2 was going to be trivial because every even year, Apple would introduce a new and completely different gaming ecosystem, and every odd year they'd refuse to talk to game devs at all. In theory Metal fixed this, but... we'll see.

#3 was initially absolutely cut-throat, including the devious fuckery of Fahrenheit ( https://en.wikipedia.org/wiki/Fahrenheit_(graphics_API) ), but as OpenGL got cruftier and cruftier, while DirectX wasn't afraid to throw old junk away, it got easier and easier. The competition was really only reawakened by Vulkan.

#4 was because everybody was paranoid that 3D would be the Next Big Thing for the OS, and Microsoft was sure that they needed a 3DAPI they could embed deeeeeep into the OS so that things like Excel and Task Manager could use it (yeah...). So obviously it had to be their 3DAPI - they're not going to put someone else's API at the heart of their OS. Anyway, this absolutely succeeded - there's almost no native 2D API left, everything graphical the OS and apps do is layered upon DirectX (DX9 initially) and managing graphics memory seamlessly with multiple contexts was probably the most difficult part of that. Was it all worth the huge effort? Unclear - we basically just got a fancy Alt+Tab animation and the edges of windows have shadows, but fixing all that stuff certainly did make life much easier for gamedevs.

Great post! Excited that the WGPU future is finally here. It's seemed like a good default for Rust graphics for a while, but having it on the web makes it feel Real™️.

(The stuff re: Apple and their behavior in WGPU sounds right, as someone who was not involved in WGPU but was adjacent to the Rust folks who were stakeholders at the time)

By the way, have you noticed the cheesy Star Trek joke yet? The companies with seats on the Khronos board have a combined market capitalization of 6.1 trillion dollars. This is the sense of humor that 6.1 trillion dollars buys you

Nah, it's because the first version of Vulkan was literally just AMD's "Mantle" API with a search-and-replace on the prefix (I am 100% serious about this). Mantle was itself a pun - it's the layer around the "core" you see, so there was lots of imagery of volcanos and magma and things being hammered on subterranean forges (and of course it's red because AMD).

And when it needed a new name, because nobody could consistently spell "Hephaestus" they settled on his Roman name Vulcan instead, except to actually AVOID the Star Trek problem they used a K. And that's why the armadillo is waving a blacksmith's hammer around.

So yes of course it's a pun. But deliberately not a Star Trek one.

tried out the wgpu examples on desktop over the weekend, very keen to see this in a browser besides chrome, ie Firefox! i looked around for a "how is webgpu support coming along in FF" page like they've done for other major features/changes but couldn't find one, any idea if there's a decent place on the web to track that progress?

Great article that gives a superb info-dump. It looks long, but (aside from the history lesson) it couldn't really have been much shorter! I hope people take the time to read it.

I've only really used threejs, mostly because webgl seemed too intimidating. this is really cool!

I hadn't heard of dawn and then of course I had to click through to the CMakeLists.txt file. Yet another "Google write CMake that doesn't instantly make me want to crawl into a hole and pass away challenge (impossible)"

What a read! Good history lesson and introduction to WebGPU, got me interested in looking into it further. I've been down in the Vulkan mines for a good while, so I'm definitely intrigued by something that's a little more ergonomic than Vulkan, but which is also not OpenGL, and keeps the low level vibes.

WebGPU does look neat. I'm a bit worried it will quickly gain adoption as the interface people program against though, as my current computer is able to only do OpenGL 3.3 (Intel Integrated) / OpenGL 4.3 (NVidia), and I'd rather avoid having to replace it just because the new shiny user-facing API requires the new shiny low-level API my hardware doesn't implement.

What a great longpost! History note: AMD's Mantle (already mentioned in the comments I see) was the real first effort in this direction, and AZDO I think was more of an attempt to get GL specifically closer to that level.

Production games like Battlefield 4 shipped with a Mantle renderer actually, and I saw a project that implements Mantle on top of Vulkan to preserve these renderers!

Oh, Vulkan is Graphics CORBA

I don't do graphics programming often(despite meaning to get more into it, and this might be a good opportunity), but I really enjoyed this post, particularly the history section. Thanks for the read!

this is a really excellent post and was fascinating to read, thank you for writing it!

Will perpetually wish that WebGPU didn't come along with another NIH shader language. We're getting one more with SDL_gpu as well so soon there will be 200 different shader languages you have to care about

EDIT: Also just remembered that pipelines are on the way out in Vulkan* so it will be interesting to see if WebGPU later has to do the same or if they will stay stuck on pipelines

and what a blog post it is. five stars, would read again in a year

Nice to see more enthusiasm for webgpu, especially webgpu on native (the name is unfortunate, just like with wasm). Do note the firefox backed version isn't limited to Rust, I've been using it from the C FFI all along: https://github.com/gfx-rs/wgpu-native. For a while both implementations target the same C header, so the differences are very minimal like you explained in the post.

About targeting shaders from the language, since I use the Scopes programming language (which I surely mentioned to you on twitter sometime) this has been a feature from the beginning for me, and it's indeed nice over here! For a bit I was scared that it was going to be taken away but indeed on desktop they still accept SPIR-V bytecode and GLSL as well. Currently I'm writing wgsl anyway because our bytecode doesn't pass the naga validation (even though it worked fine before), but I'll try to fix that along the way.

Hi Andi, I'm not really a graphics programmer, but this was a really cool and fascinating read. Thank you so much for sharing!

Wow this is incredible. I kinda hate browsers, I mean there’s reasons all the way back to IE6, and Electron certainly hasn’t helped. So I had kind of ignored this whole space as being slightly cursed? But hearing that it’s abstracted enough from the browsers that it makes sense to use it native, with a lot less overhead than you’d expect, has made this sound much more interesting. We really do just want some cross platform stuff and honestly, nothing brings all the major players to the table like the web.

I also had never heard before that Vulkan was never meant to be written by humans, I’d heard it was fiendishly complex and then was surprised that people were excited by D3D12 and Metal.

Also I’m amazed that you made Apple’s decision to deprecate OpenGL sound reasonable hahaha, kinda goes to show that Apple doesn’t get the marketing team to talk about engineering decisions, you get the consumer facing half of the company being all friendly and the technical half is seemingly code-of-silenced into being unable to explain even the simplest things satisfactorily.

I suspect you may even be underestimating the impact of WebGPU. I'll make two observations.

First, for AI and machine learning type workloads, the infrastructure situation is a big mess right now unless you buy into the Nvidia / CUDA ecosystem. If you're a research, you pretty much have to, but increasingly people will just want to run models that have already been trained. Fairly soon, WebGPU will be an alternative that more or less Just Works, although I do expect things to be rough. There's also a performance gap, but I can see it closing.

Second, for compute shaders in general (potentially accelerating a large variety of tasks), the barrier to entry falls dramatically. That's especially true on web deployments, where running your own compute shader costs somewhere around 100 lines of code. But it becomes practical on native too, especially Rust where you can pull in a wgpu dependency.

As for text being one of the missing pieces, I'm hoping Vello and supporting infrastructure will become one of the things people routinely reach for. That'll get you not just text but nice 2D vector graphics with fills, strokes, gradients, blend modes, and so on. It's not production-ready yet, but I'm excited about the roadmap.

you made it on lobste.rs

Fascinating!

Thank you very much! This is a fascinating, informative and fun read that I will be bookmarking, rereading, and using as a reference. And definitely not too long! I love history, and I love footnotes, so a very pleasant way to spend an evening. Again, thank you.

Few years ago I had an "Intro to Computer Graphics" class at uni. We did a lot of WebGL (because not having to install anything means is the easiest platform to develop to).

For the final project I ended up doing a FLAM3 renderer on WebGPU. It was really crappy (just atomic incremenrs on a big buffer) but it worked incredibly well!

Initialization headaches aside WebGPU and WGSL are really nice to use. Even when comparing them to WebGL. It's kind of incredible that the low~ish level API feels better than the high~ish level one.

Also GPUs are amazed me with how fast they are. Even for crappy code.

If I may add one more piece of info, regarding SPIR-V and WGSL specifically: Google has a bi-directional SPIR-V<->WGSL compiler called Tint ( https://dawn.googlesource.com/tint ), which is used in Chrome's WebGPU vulkan backend and seems to be quite feature complete. Not sure of any work specifically on that front, but with enough "convincing" you could likely run it using WebAssembly, and thus ship SPIR-V with your WebGPU applications. (Or write your shaders in HLSL/GLSL, compile them to SPIR-V and then back to WGSL for web deployment)

That was a really good read! I havent been involved much in any shader shenanigans just yet (web or not) so I am somewhat intimidated by the Hello World sizes but this does kind of tempt me to delve into shaders

Disclosure: Some edits I have made to this post since posting: Clarified the timeline of Metal vs Vulkan; clarified the bit about AZDO to prevent implying the AZDO talk itself inspired all those graphics APIs, which would be pretty implausible considering the timeline of Metal and Mantle; fixed the diagram images for visual glitches and to make it clear render passes are created on views, not textures; wrote out names for the threejs alternatives in the footnote; typos.

Also the "sample Rust repo" linked was initially missing a commit which was present in the "compiled form running in a browser" linked in the same paragraph. The license was missing. But that's pushed now.

2023-05-12: Corrected an error in footnote 6.

i will probably never use any of these skills. great post.

I've been using WebGPU as a library in standalone / not-in-the-browser Rust and it's pretty great. Just a thin, flexible layer with Vulkan-like semantics that abstracts away all the nasty stuff you'd have to abstract away anyway, so you don't have to reinvent the wheel.

This all still looks so terrifying, but also super-cool, and it makes me want to lean into graphics programming with Rust even though it scares the hell out of me.

If you don't like WebPack, that implies you know enough about JavaScript you already know how to replace the WebPack in the example with something else.

haha

I haven't seen this mentioned, so I'll just add that the lowest friction method I've found for playing with this stuff on Android is to load Chrome Canary and enable

chrome://flags/#enable-unsafe-webgpu

edit primus: it's probable you can also just do this on chrome, but i usually don't use chrome for anything and compile my own chromium apk to be able to run apps that require chrome.

however, the build is a bit of a bother, so i haven't done it yet.

edit secundus: firefox nightly for android now seems to have webgpu enabled by default

Super interesting read, even for someone like me with almost no experience with any of these libraries. Thank you!

just to let you know, your post has made it onto sidebar sorry that your post is so good that you just keep on getting an unstoppable deluge of attention.

sorry for necroposting, but regarding Apple and patents, have you seen this piece of history?

https://www.khronos.org/files/ip-disclosures/webcl/Apple-WebCL-Disclosure-Jan14_clean.pdf

(I don't know why Apple is so hostile to collaboration at this level, and it's sad because at times e.g. some of the Apple-driven compromises in WebGPU make it really feel more like WebMetal than "safe Vulkan")