WebGPU – All of the cores, none of the canvas | Hacker News Reader

WebGPU – All of the cores, none of the canvas

surma.dev

393 pointsjasim134 comments

I've busted my ass on webgl a few times, and I am not really seeing how WebGPU is a substantially better API looking at the samples in the wild:

https://webkit.org/demos/webgpu/scripts/hello-triangle.js

The advantages of WebGPU vs WebGL probably make sense to experts in this area, but I still find most of it to be completely impenetrable at first glance as a relative novice.

I think one of the big changes will allow for async gpu uploads. Currently those happen on the main thread and lock UI.

WebGPU is better in many dimensions, but also worse in others people might care about. More appropriately, in this case, WebGPU is in many ways less approachable for novices.

One of the expected advantages of WebGPU is exposing the inner workings of the hardware's GPU support in a more explicit manner. This leads to really verbose code. This is similar to API movements seen in DirectX, Vulkan, and Metal.

WebGL was never exactly easy to read either, but you could get started more easily. It tried being something in-betweenm though, and ended up never being the best at either providing explicit behavior, nor being friendly.

The idea of WebGPU going forward is that it will make it easier for other libraries to use it in a more deterministic fashion. If you know how the metal works, you'll be able to optimize the sh*t out of it. But for novices, you'll end up using some library or engine that abstracts away a lot of the hardcore functionality like "let's get an adapter that supports this specific texture extension" or "let's reuse a binding group layout to save 2ns when binding uniforms". In the same way most people on the web use Three.js (instead of WebGL), you'll see libraries like Babylon or Three.js making use of WebGPU without really having to know about all that stuff. And that's the right solution.

Anecdotally, I had the opposite experience. I've wanted to dabble in parallel/gpu programming for a while but the fact that all the material forced me to care about triangles and matrix transforms for nontrivial case examples turned me off.

I've recently been playing with WebGPU and while it's still a bit of a boilerplate nightmare (which I wouldn't presume to know how to do better).. it was far more approachable.

Wrapping my head around buffers and layouts, and the fact that wgsl is a huge pain in the neck to debug, took a while.

I've built myself a really rudimentary perlin noise generator using compute shaders, and managed to pipe that into a rendering shader that uses two triangles to render part of the noise field onto a canvas really smoothly.

Trying to do some fancier compute stuff now, and overall the primitives are relatively straightforward. It's just that the documentation around the binding types and layouts, resource limits, and command-encoder/pipeline operational semantics are poor right now.

I’ve always been interested in CG. Back in the day, I played with OpenGL 1.x, D3D5, lived through the introduction of shaders. Now I’m toying with Vulkan and it’s incredible how simple it feels compared to the old-school APIs. Everything basically reflects what the GPU is really doing, you just acquire a drawing surface, set the state, bind some buffers and execute the shaders. There is very little hidden state.

I admit this is a little bit more involved than calling glClear followed by glDrawTriangles, but once you reach the stage where you’re ready to apply textures and write shader code, the new way seems much more straightforward.

>The advantages of WebGPU vs WebGL probably make sense to experts in this area

Think of it as going much lower level like doing your stuff in x86 assembly language, so, sure it's going to be a PITA to get something running but for that very special need where every bit of performance matters it's going to work well.

    I still find most of it to be completely impenetrable at first glance as a relative novice

There's a lot of boilerplate code involved in setting up even the simplest of programs. I think one descent way to get started learning is to skip the boilerplate at the start and just play with the GPU part, like shadertoy.com lets you do.

For those looking for a complete 3D engine already supporting WebGPU and with a WebGL fallback if needed, there is BabylonJs (you'll need the 5.0 version still in the release candidate state) : https://doc.babylonjs.com/advanced_topics/webGPU/webGPUStatu...

ThreeJs is alwo working on its WebGPU renderer

Im excited for Bevy engine too. It uses wgpu, which has many backends, including webgpu.

https://bevyengine.org

https://hn.algolia.com/?q=bevy

I've only heard great things about Bevy, and their community is awesome. Highly recommend looking into it if you like Rust! They also just had a huge gamejam with something like ~70 submissions. Impressive stuff!

I'm super excited about WebGPU and think it will be a winning strategy for game engines going forward.

I'm working on a (very early stages) game engine in Zig called Mach[0] and am using Google Chrome's implementation of WebGPU as the native graphics abstraction layer, so Zig's C++ compiler builds it all, you get cross-compilation out of the box. It's quite fun!

[0] https://devlog.hexops.com/2021/mach-engine-the-future-of-gra...

For any developers interested, our team at Wonder Interactive is working on WebGPU support for Unreal Engine 4 and Unreal Engine 5.

Games and real-time 3D applications in the browser will form the basis of the open metaverse.

You can register here on our website for early access - https://theimmersiveweb.com/

just so you know, images don't even work on your site. Using safari

I'm going to bet you're using a mac running an older version of OSX, I ran into this exact issue, only Safari on macos 11+ supports webp.

luma.gl is also working on a new version to support WebGPU: https://luma.gl/docs/v9-api

If anyone wants to play with webgl/webgl2/webgpu/high-perf js, we're looking for a graphics engineer for all sorts of fun viz scaling projects (graphs used by teams tackling misinfo, global supply chains, money laundering, genomics, etc.): https://www.graphistry.com/careers

Agreed with other folks here: We see opportunities to advance over what we did with WebGL (opengl es 2.0 from 10-20 years ago)... but as far as we can tell, still a puzzle to work around missing capabilities relative to what we do with modern opencl/cuda on the server. So definitely an adventure!

Am I understanding this right, that websites can now run a crypto miner in the background when I visit them?

always has been

Already a thing, it's just been CPU based and now can be GPU based. Firefox (and probably other browsers) have systems to attempt to block them. https://blog.mozilla.org/futurereleases/2019/04/09/protectio...

The people sneaking this shit into webpages don't care if it burns $1 of electricity and destroys your battery to generate $0.0000001 of Monero because all of those costs are paid by someone else.

Is there a toggle extension like I have for JS?

I'm keeping an eye out too. I've seen a few vulnerabilities mentioned already for this tech. This site (https://hacks.mozilla.org/2020/04/experimental-webgpu-in-fir...) suggests that setting the options “dom.webgpu.enabled = true” and “gfx.webrender.all = true” to false (where needed) could prevent it from running. I'm also guessing it's use will depend on javascript which I block by default.

If you're using Chrome Canary with the "Unsafe WebGPU" flag turned on, yes. And it'll be a lot faster/more power hungry than before. Otherwise, nothing beyond the normal CPU based miners have been enabled.

Adaptation is the cost of progress. Browser vendors will almost certainly implement a way to prevent unauthorized use of such hardware (either by prompt like webcams or automatic detection) before this stuff becomes publicly available.

We'll also have to start measuring websites by how much power they consume.

No. Crypto miners have always been possible and WebGPU does not make them faster than they would be in WebGL 2 which has been available for a long time already.

I’m not up to date on the latest mining algorithms but is it true that they’re all embarrassingly parallel to the point the WebGPU makes no difference? Fast inter-thread communication is the big addition here.

I guess it depends on the specific cryptocurrency. I don't think the big ones would benefit. Maybe some niche ones could see some kind of benefit, but making mining somewhat more efficient isn't going to change the incentives for drive by miners that much because efficiency doesn't matter when it's someone else's electricity you're wasting.

Yup, though you’ll probably notice your fans spin up (or coil whine if it’s my PC).

Browsers really need to put direct GPU access behind a permission prompt, just like they have for webcam or mic access.

So now there are three incompatible graphics APIs in the browsers which are also incomplete in different ways. Each of them is a huge chunk of code that needs to maintained and updated.

yes

There's at least five now: DOM, canvas, SVG, webgl, webgpu. Could maybe make an argument that fonts are an entirely separate rendering engine with quirks and issues too. CSS Houdini might even be another new one.

If I was developing a new browser today, my graphics abstraction would be WebGPU and all other graphics would be built on it. WebGL, Canvas 2D, SVG, and even DOM rendering would be unprivileged libraries on top and only WebGPU would be able to touch the actual hardware. I wouldn't be surprised if some browsers moved that way in the long term.

I find your ideas intriguing and I wish to subscribe to your newsletter.

More seriously, yes, if you were starting a browser completely from scratch, this would probably be a good approach. There are some subtleties, but probably nothing that couldn't be solved with some elbow grease.

If anyone is seriously interested in exploring this direction, one thing that would be very interesting is a port of piet-gpu to run on top of WebGPU (it's currently running on Vulkan, Metal, and DX12). I've done quite a bit of pre-work to understand what would be involved, but don't personally have the bandwidth to code up the WebGPU port. I would be more than happy to work with somebody who does.

By "work with somebody", do you mean your team at Google is hiring for this, or are you looking for community contributors?

At the moment, I am talking about community contributors. But if you have a credible plan for getting this done and the thing that would hold it back is funding, let's talk.

I have no credible plan and I would need some mentoring before I could even be productive. Sounds like you probably want someone with more relevant experience.

I wouldn't start a browser from scratch, it's too big and compatibility is a never ending quagmire. I think it would be cool to do a new portable app platform with bits and pieces of the web platform like WebGPU, combined with new stuff, kind of like how deno is using web APIs outside the web. Maybe combined with the ideas from the redbean server.

Doesn't WebGPU require a DX12-level GPU? If so, that would make your browser incompatible with a ton of systems out there.

Writing a new browser would take many years and those systems would be obsolete :) But there's also an intention to produce a more compatible restricted subset of WebGPU at some point.

GPUs aren't particularly good at vector graphics rendering especially at smaller sizes. You'd want a CPU emulator of the GPU code and that seems strictly worse than doing it native.

https://sluglibrary.com/ says otherwise

Games aren't a good system performance workload because nobody cares if they scale down, only if they scale up.

Nothing constrains Slug to games. Adobe has licensed it for example.

Eh, that's a good sign for Unicode support but otherwise it's pretty similar. Photoshop and games are both foreground apps, Acrobat less so, but browsers and system UI are closer to utilities you don't want using all your resources.

The perf issues are mainly latency (CPU<>GPU communication) and power (turning the GPU on) on discrete GPUs, integrated/mobile GPUs are better off there but memory use can be a problem.

Other issues:

- skipping the DOM and system font API loses you copy-paste, translation, and screen readers

- subpixel AA and hinting usually get lost, although they're doable

- it just looks weird when your app uses a different font renderer from everyone else, or even from other text in the same window

> skipping the DOM and system font API loses you copy-paste, translation, and screen readers

Browsers implement their own copy/paste, accessibility, and translation. WebGPU being used for rendering affects none of that.

> subpixel AA and hinting usually get lost, although they're doable

Subpixel AA is a technology of the past and a new forward looking browser should not bother supporting it. Tons of complexity and compromises for small gains on bad screens only.

> it just looks weird when your app uses a different font renderer from everyone else, or even from other text in the same window

This can probably be minimized with some effort. To the extent that it can't be identical, web content is so obviously not native already that I think it doesn't matter.

> Browsers implement their own copy/paste, accessibility, and translation. WebGPU being used for rendering affects none of that.

That's why I said skipping the DOM, as in using canvas or WebGPU yourself. Browsers do handle that properly but unfortunately games or game-like apps don't even if they display lots of text.

> Subpixel AA is a technology of the past and a new forward looking browser should not bother supporting it. Tons of complexity and compromises for small gains on bad screens only.

Apple is the only vendor of highres desktop displays, I think? The reason subpixel AA doesn't work on OLEDs is because they're worse (PenTile instead of RGB) not better.

Safari indeed doesn't do subpixel on HiDPI displays, but that leaves hinting and some other text rendering tricks with similar constraints that a naive renderer would forget about.

In the comment you're replying to I did not propose skipping the DOM, I proposed rendering the DOM via WebGPU. As an implementation detail of the browser, not as something websites should do themselves.

Um, Apple is far from the only vendor of high res displays. And not all OLEDs are PenTile. The trend in all displays is to higher resolution where subpixel AA is unnecessary complexity, and especially on mobile which is more important than desktop these days and where nobody ever does subpixel AA, even on relatively low resolution displays that could support it.

> In the comment you're replying to I did not propose skipping the DOM, I proposed rendering the DOM via WebGPU. As an implementation detail of the browser, not as something websites should do themselves.

Hmm, I guess so, but writing the browser based on WebGPU seems limiting? You can use native code there.

> Um, Apple is far from the only vendor of high res displays.

There's stories on here every day about how they are.

https://news.ycombinator.com/item?id=30604375

https://news.ycombinator.com/item?id=30631288

> And not all OLEDs are PenTile.

Meant to say "mobile OLEDs" if you insist. There's no desktop OLEDs, people don't seem to enjoy using RGBW TVs as displays. Couldn't say why.

> There's stories on here every day about how they are.

There's stores about their high res displays, but to the extent they claim Apple is the only vendor that's just plain false.

If I developed a new browser today, my baseline graphics abstraction would be CPU-side pixel buffers manipulated by compiled (WASM/native) code. CPU rendering works equally well on past, present, and future CPUs, works with working and buggy and missing GPU drivers, works on every computer made in the last few decades, will never be obsoleted like Glide and DX7-9 and OpenGL, and is plenty fast enough outside of 4K or 144FPS rendering.

No need to develop a new browser, you can easily configure yours to disable GPU rendering. If you like things to be slow and inefficient. Personally I'm never buying any display under 1440p 120 Hz again and I prefer to run workloads where they're efficient, so I'll continue to use GPUs for graphics.

This is off-topic but I instantly started reading the article in Surmas voice. I mean this as a compliment. Surma and Jake's HTTP203 on YouTube is superb content.

Is this API going to have a permissions lock, like access to the video camera or microphone APIs do?

If it doesn't, I'm not looking forward to the future where every website I visit tries to pull a big chunk of my graphics card to mine cryptocurrencies without my explicit authorization.

It's already the case. Any web page can use WebGL1/2 for general computation. As the author said:

> Using GPUs for calculations of any kind is often called General-Purpose GPU or GPGPU, and WebGL 1 is not great at this. If you wanted to process arbitrary data on the GPU, you have to encode it as a texture, decode it in a shader, do your calculations and then re-encode the result as a texture. WebGL 2 made this a lot easier with Transform Feedback

True, but this API will make that use case simple and obvious. Given the tradeoffs, probably worth it for user agents to permission-gate it.

You can always disable hardware acceleration in your browser.

That's a big red lever that disables all sites' ability to use WebGL also, isn't it? That kind of thing is the kind of thing I imagine one would want at site-by-site granularity.

I'm still hoping that someone will revive uMatrix and add new columns for GPU access and other webshittery.

I don’t want to disable it, I want websites to have to ask permission before they get access to even more hardware resources.

I think the problem is presenting this to users in terms they’ll all understand. “This site wants to do a special kind of processing”? “Use more resources”? I can’t think of many good answers. Anything involving the term “GPU” is immediately going to confuse most.

While I understand why it's necessary, I feel that the UX of security needs a serious overhaul. It seems like an increasing share of the time I spend using technology involves jumping through hoops.

There is a push-and-pull because the ideal of how the web should work slammed head-on into the reality of how the worst actors will exploit the ideal.

Ideally, the web is a fabulous location-destroying architecture. The common protocol for both communications and content rendering really flattened the universe of data sources; doesn't matter if you're on CNN, Fox, Wikipedia, Google, or Hacker News, they all "feel" the same. Common top-level UX metaphor (underneath which customizations can be built), common language under-the-hood; the web really became a sort of global operating system for transactional communications.

In practice, letting arbitrary actors run arbitrary code on your machine at the speed of the web can be arbitrarily bad, so we tacked on a permissions architecture based on data source (delegating to the domain name service plus secret certificates to tell us who the data source is). And because the proper level of paranoia for strangers online is "zero trust by default," every domain you visit is a new trust relationship with its own security story to wrangle.

So these two features (flat experience where domain doesn't matter and zero-trust security model where domain matters a bunch) are directly at odds with each other. Sucks but it's the best we've got right now (how to improve? Hypothetically, we could add a meta-trust layer... "Here's an allow-list of sites that are trusted, so sayeth Goodsites.com". But nobody's written that spec yet).

GDPR-compliant cookies, as a concrete example, are a huge pain-in-the-ass because we retrofitted them onto site internal code itself instead of adding the concept of "required" vs "optional" cookies to the cookie jar design, which would have allowed user agents to put optional cookies behind a trust barrier like your microphone or video. But cookies are a legacy web feature and making changes to the implementation is hard (and, of course, there's the human element... I'm not 100% sure the people who hold the reigns of the W3C are on the same page with the people who hold the power to create and enforce the GDPR vis-a-vis goals).

Couldn't you make the same argument about being able to perform computation on the CPU?

You definitely could (and, indeed, I can imagine beneficial use cases for a "renice" feature in a browser like Chrome with its Task Manager).

But there's less of a significant need for it. Main CPU performance is too poor on hashing datasets to much benefit from salami-slicing user CPU at scale. That trick is much likelier to get you a solved block in the blockchain if you can tap user GPUs on a couple million users.

Yes, hence why extensions like NoScript and uMatrix exist(ed).

Question for someone with gpu programming experience: is it feasible to analyze time series data (eg.: run a trading algorithm through a series of stock prices) in parallel (with the algorithms receiving different parameters in each core)?

If not then what is the limiting factor?

Probably possible, but you would really need some more concrete information.

For some easy experimentation with GPUs I would advise looking at Futhark. It's super easy to setup and get started.

https://futhark-lang.org/

This depends on the algorithm. If it has lots of branching and control flow, then it's unlikely to run well. If it's based on something like FFT or any sort of linear algebra really, then it should run really well.

WebGPU is accessible enough maybe you should try it! You'll learn a lot either way, and it can be fun.

Isn't there something like SciPy which you can run on WebGPU?

At this point, there are very few tools actually running on WebGPU, as it's too new. One to watch for sure is IREE, which has a WebGPU backend planned and in the works.

There is wonnx a rust based webgpu enabled onnx runtime for ml stuff.

https://wgpu-py.readthedocs.io/en/stable/guide.html :

> As WebGPU spec is being developed, a reference implementation is also being build. It’s written in Rust, and is likely going to power the WebGPU implementation in Firefox. This reference implementation, called wgpu-native, also exposes a C-api, which means that it can be wrapped in Python. And this is what wgpu-py does.

> So in short, wgpu-py is a Python wrapper of wgpu-native, which is a wrapper for Vulkan, Metal and DX12, which are low-level API’s to talk to the GPU hardware.

So, it should be possible to WebGPU-accelerate SciPy; for example where NumPy is natively or third-partily CUDA-accelerated

edit: Intel MKL, https://Rapids.ai,

> Seamlessly scale from GPU workstations to multi-GPU servers and multi-node clusters with Dask.

Where can WebGPU + IDK WebRTC/WebSockets + Workers provide value for multi-GPU applications that already have efficient distributed messaging protocols?

"Considerable slowdown in Firefox once notebook gets a bit larger" https://github.com/jupyterlab/jupyterlab/issues/1639#issueco... Re: the differences between the W3C Service Workers API, Web Locks API, and the W3C Web Workers API and "4 Ways to Communicate Across Browser Tabs in Realtime" may be helpful.

Pyodide compiles CPython and the SciPy stack to WASM. The WASM build would probably benefit from WebGPU acceleration?

Since you mentioned FFT, I wondered whether GPU-based computation would be useful for audio DSP. But then, lots of audio DSP operations run perfectly well even on a low-end CPU. Also, as one tries to reduce latency, the buffer size decreases, thus reducing the potential to exploit parallelism, and I'm guessing that going to the GPU and back adds latency. Still, I guess GPU-based audio DSP could be useful for batch processing.

Yes. Probably the single most effective use of the GPU for audio is convolutional reverb, for which a number of plugins exist. However, the problem is that GPUs are optimized for throughput rather than latency, and it gets worse when multiple applications (including the display compositor) are contending for the same GPU resource - it's not uncommon for dispatches to have to wait multiple milliseconds just to be scheduled.

I think there's potential for interesting things in the future. There's nothing inherently preventing a more latency-optimized GPU implementation, and I personally would love to see that for a number of reasons. That would unlock vastly more computational power for audio applications.

There's also machine learning, of course. You'll definitely be seeing (and hearing) more of that in the future.

Already on it! https://github.com/webonnx/wonnx - runs ONNX neural networks on top of WebGPU (in the browser, or using wgpu on top of Vulkan/DX12/..)

Depends what you do the analysis with. The state of the art is a neural network, and the best there are transformers which do parallelize (as opposed to the previous generation, LSTMs which don't parallelize as well)

The limiting factor is usually parallelism, to utilize a GPU well you need to be running something on the order of 10000 threads in parallel.

Yes, in fact GPUs are perfect for this. Here is a Monte Carlo financial simulation I built in WebGL 2. https://james.darpinian.com/money/ (Warning, programmer UI) It performs one million Monte Carlo runs instantly every time you move a slider. Each run is one execution of a pixel shader and they all happen in parallel.

WebGPU will make this kind of thing more accessible. It's kind of a pain to do it in WebGL, but even so it's still totally possible and worthwhile because you can easily get 20 times the performance in many cases and handily beat native CPU code even on the web.

Hmm the UI is super unresponsive for me. As in, I try to move a slider, I can't tell where it's moving to... then I let go and it's somewhere I didn't expect.

Latest Firefox, Windows 10, Radeon RX 6700XT 16GB.

Do other WebGL 2 demos work well for you? Does it work in Chromium?

I haven't tested the code extensively so I'm sure it's broken in some configurations. It's just a proof of concept demo for now.

Ah sorry - disregard. I had a background process gobbling up GPU, and now I can use it in Firefox or Edge.

I do find it confusing, as I can put in numbers that get me well below a 3% withdrawal rate, but still have only 40% success rate. But I'm probably misunderstanding some of the mortgage sliders.

Yeah, it's confusing for sure. One day hopefully I'll have time to put a real UI on it. Right now it's assuming you buy a house with a mortgage (and property tax and yearly maintenance costs) at the same time as you retire. Put the house price to zero to eliminate all that. Also the expenses slider is before tax, so the tax rate slider influences how large your withdrawals actually are. The total withdrawal per year is displayed near the bottom.

I'm on Windows 11 with a Radeon RX570 8gb and it runs fine under Edge.

On Firefox it's way laggier but still usable.

GPUs are largely best suited for providing high throughput for doing similar computations across wide datasets. So if you can break down your algorithm into a series of steps which are largely independent and have limited flow-of-control it might be well suited to the task. If you need to have a lot of random access, or branching logic, it may not work so well. But often times it's possible to re-structure an algorithm designed for CPU to perform better on GPU.

But how many stocks even are there? You might not even have enough parallel operations to saturate a modern GPU.

Out of curiosity, why use WebGPU for this? If you're really trying to do something high performance, why not reach for something like CUDA?

We have a few examples of time series data processing in Hal9 with WebGL (no support for WebGPU just yet):

- Simple regression with TensorFlow.js: https://hal9.com/hal9/historic-temperature-analysis - LSTM with TensorFlow.js: https://hal9.com/hal9/bitcoin-prediction - ARIMA with Pyodide.js: https://hal9.com/hal9/ai-fundamentals-arima

If you have question or would be open to considering using Hal9 to do time series analysis in JavaScript, let me know! You can find me in Twitter at https://twitter.com/javierluraschi

If I'm already familiar with Rust, how is WebGPU as an introduction to graphics programming if you aren't already familiar with any of the backends that it wraps? Should I try just learning Vulcan first? Is the abstraction layer just going to introduce additional confusion for a newbie?

"Is the abstraction layer just going to introduce additional confusion for a newbie?"

As a newbie you probably don't want to deal with WebGPU directly, but rather use (wait for) a framework, that takes care of the details.

depends on your objective, doesnt it? if you eant to learn how things work & what the fundamnetals are, im not sure that a big engine or framework "taking care of the details" is going to be as illuminating.

also, from the article, some poditive reinforcement about trying WebGPU:

> I got my feet wet and found that I didn’t find WebGPU significantly more boilerplate-y than WebGL, but actually to be an API I am much more comfortable with.

sometimes, there aint nothing like going to the source, finding out for yourself. is it the fastest way to get a job done? perhaps not. but the school of lifelong learning & struggles has it's upsides, can be a path towards a deeper mastery.

"depends on your objective, doesnt it? "

Sure, thats why I said "probably".

Anyone who wants the most performance and raw power needs to get to the source.

But most people using WebGPU are probably fine with a framework, that hides all the details. Like threejs did for webGL.

Exactly. It's going to be much more productive for someone totally new to 3D graphics to play with three.js and learn all about models, meshes, textures, shaders, coordinate spaces, cameras, etc. If you're starting with webgpu or even webgl you're going to get mired in eccentricities of buffer management, byte formats, etc. which are important plumbing but just that--plumbing.

I think one of WebGPU's greatest strengths is learning, as you can get started pretty easily, and you actually learn a modern approach to GPU. Vulkan requires a significant amount of boilerplate just to establish a connection to the GPU and set up basic resources like the ability to allocate buffers. In WebGPU, the latter is one or two lines of code.

That said, there are some really nice learning resources for Vulkan as well, so if you're motivated and determined, it's also not a bad way to learn modern GPU.

Is WebGPU ready? It's been a bit, but last time I looked it was pretty unstable and not well supported.

It's still in origin trials on Chrome and behind flags in Firefox and Safari. That said it's pretty stable at this point, for reference Chrome plans on enabling it for all sites and users by default towards the end of May.

So I just went through this process and I have to slightly disagree. I'm coming from literally no knowledge of low-level graphics programming. My most relevant experience is writing against Canvas2D, which is not relevant at all.

I first tried WebGPU, and was so overwhelmed with detail that it was nearly impossible to connect the dots. So I went back and decided to learn WebGL first. I know that it's very different, but the whole state machine thing makes it so much easier to understand, at a conceptual level, what you're trying to do.

It didn't even take that long, just a couple of weekends and I was already familiar with the basics. I'm not going to waste time trying to become super proficient, but it gives me enough context to go back and try WebGPU again.

Could you share what resources you used to learn the essentials of WebGL enough to tackle WebGPU?

I read so many different articles that it's difficult to remember exactly which ones. One very good resource is this person: https://www.youtube.com/watch?v=9WW5-0N1DsI

The video is more about shaders in Unity, but she explains the context behind what shaders are so much more clearly than anyone else I've come across.

Start with WebGPU. There's a great resource here: https://sotrh.github.io/learn-wgpu/.

Unless you live in windows ONLY, start with wgpu (a Rust library that supports WebGPU). It'll work with Metal/Vulkan/Web.

WebGPU is very similar to Vulkan, near a 1:1 in concepts. A lot of the new libraries (Metal, DirectX) are similar in fact, so learning WebGPU will get you extremely prepared for any of those.

I don't see why you wouldn't also use wgpu on Windows

Re: compute vs. Graphics pipelines: “and also considerably understates that these pipelines are physically different circuits in your GPU”

Wait what?? Can someone fill me in? Why would they have different hardware? Compute is compute, even if the computer is mostly good at triangles.

Render pipelines use the same compute cores for running the shaders as of long ago. However, they also involve fixed-function pieces (some implemented in hardware) that compute shaders don’t have access to. Such as: rasterizer, blending, depth/stencil testing.

WebGPU, all the bare metal crashes/exploits and none of the broad support. Browsers should not be operating systems and the move to make them so will end up making them just as exploitable as your host OS only much slower due to the additional abstraction layers.

That ship has long sailed.

Doesn't mean people can't drop anchor and get off the boat. Lots of terrible ideas were popular and later became uncommon.

One benefits is that web browsers have to respect a standard set of APIs which abstract the hardware and makes them all inter-operable (except the usual incompatibilities obviously).

Now POSIX was arguably successful, but it was limited in scope (not including the UI aspect of things). Also: Windows...

Additionally, the absence of that big global state which is the filesystem makes the development of portable applications way more easier. There's always been limitations to what browsers can do, but personally I don't regret iTunes, Outlook or all those desktop app advantageously replaced by SPAs. I can log from any computer/smartphone and I get my apps. No installation process, configuration, the usual missing/corrutped library/dlls, etc.

And the problem of data ownership is not a technical problem. If we didn't have browsers, software companies would have moved those data away from you and have desktop app access them remotely anyway.

I get that abstraction levels suck. But only if the cost/benefits ratio is bad. Java applet had awful UX AND they were slow. Now SPAs can be quite responsive and some of them a pretty cool to use.

>WebGPU, all the bare metal crashes/exploits

It's a goldmine. Think of all the future jailbreak entrypoints this will make possible.

WebGPU is not significantly more "bare metal" than WebGL is. There are still going to be several layers of abstraction between user code and the GPU in all cases. No operating system implements WebGPU or WGSL directly so there's always a translation and verification layer in the browser, and then there's the OS API layer, and then the driver layer (and probably multiple layers inside each of those layers). In fact, on operating systems that implement OpenGL, WebGL is actually closer to the OS/driver interface than WebGPU is.

WebGL has been around for a long time and the feared exploits never materialized. It's been no worse than other parts of the browser and better than many.

There's very little that GPUs can do that CPUs can't do so far as exploitation is concerned. The GPU driver runs in a sandboxed userland process just like the browser engine does, and the GPU respects process isolation just like the CPU does. There is no “bare metal” here!

Now, sure, there must be plenty of memory-safety issues in GPU drivers, but why find an exploit in a driver only some users have installed, when you can find an exploit in the browser everyone has installed? The GPU driver exploit doesn't give you higher privileges.

The main difference is that it's a lot easier to crash GPU drivers (eg with a 100% busy loop) or slow down UI rendering. There are shader verifiers to avoid some of this.

The driver runs in ring 0, and talks over PCI bus to some blackbox that is running random source code your web browser just compiled...

WebGPU has the same sandboxing in place as WebGL, e.g. despite the name there is no "direct GPU access" (minus any implementation bugs of course, which will hopefully be ironed out quickly).

With the "fun" to rewrite all WebGL shaders into WGSL.

You can use the SPIR-V compiler toolchain to just transpile from GLSL to WGSL :)

Minor nitpick: this translation happens in separate libraries/tools which just make use of the SPIRVTools library for some SPIRV processing tasks, but not the actual translation to WGSL.

Tint (Google, implemented in C++): https://dawn.googlesource.com/tint/

Naga (Mozilla(?), implemented mostly in Rust): https://github.com/gfx-rs/naga

Both are a bit similar to SPIRV-Cross, except that they also support WGSL.

Naga (a community project) translates GLSL directly into WGSL, unlike other tools.

Ah alright, thanks for the correction :)

Yes I know, even more fun dealing with additional kludges, because 3D on the Web versus native doesn't have enough of them already.

Will there be an http203 episode about this? ;-)

great writeup!

For those interested, I was only able to get the demos running in Chrome Canary with "Unsafe WebGPU" enabled.

Another thing to turn off in FireFox. Already have WebRTC, WebGL, WASM, ServiceWorkers etc disabled. Most sites are so much faster without all this junk

How is wasm worse than JS?

I'm with you. It's obnoxious to have to disable a long list of things with every install, but if Firefox didn't support something everyone else does they risk driving people who want that functionality away. I don't mind the bloat as long as it's easily disabled and they go out their way to notify users of the risks when they don't have it disabled by default.

I want firefox to keep giving people the option to do whatever they want, I just don't want them forcing anything on people, making them more vulnerable by default, or not being clear about things they've added support for.

WebGPU is a textbook case of Embrace Extend Extinguish performed by Apple to kill Kronos and SPIRV, and everybody is cheering it on. Crazy.

The WebGPU spec is currently edited by two Google employees and one Mozilla employee. I am not sure how to make sense of your accusation.

The WebGPU Shading Language spec is edited by Google and Apple, Mozilla were the ones proposing straight SPIRV and are not among the editors in this case.

Still doesn't make any sense but it has nothing to do with who the editors are.

The author list and W3C document are pretty much irrelevant, the actual working group is what counts.

After thinking about it some more, I've come to the conclusion that I've actually not been strong enough in my initial accusation, and that Apple is trying to smother any threat that WebGPU poses to its native App supremacy.

The story is essentially:

Apple wants SPIRV dead. Mozilla wants SPIRV alive. Google wants SPIRV alive.

Google developed a human readable text version for SPIRV, which is isomorphic to the binary version, akin to WASM <-> WAT.

Mozilla wants SPIRV, which Apple fully rejects (because of some legal dispute with Chronos, where Apple probably tries to get a patent for something that Chronos has as prior art or something), but they are open to googles proposal of a textural intermediary, which is isomorphic.

Mozilla and Google agree, because they'll all compile down to SPIRV anyways, except for Apple which will target Metal.

This decision is captured in the W3C proposal which to this day contains the Isomorphism property.

That's the Embrace, WGSL is born.

Apple convinces Mozilla and Google that WGSL should be even more human readable, since user readable formats are the backbone of the open web. But for more convenience WGSL will need more features. Extend.

Apple convinces Mozilla and Google that now that the language has grown anyways they should make it much more compatible with other shading languages in general, SPIRV will not be the only target, so while it should be compilable to SPIRV, that's by no means a primary goal. Isomorphism is abandoned. Google tries a last ditch effort to keep the isomorphism with a proposal literally called: "Preserving developer trust via careful conversion between SPIR-V and WGSL".

The proposal is rejected, the working group decides that the isomorphism property will no longer hold (I can only assume malevolence that they haven't removed it from the spec yet, probably to keep dev support.). Extinguished.

https://docs.google.com/presentation/d/1ybmnmmzsZZTA0Y9awTDU...

Why is that isomorphism so important? Because it's near impossible to develop truly high performance shaders with a load of compiler optimisations between your hardware and your tooling. Apple is successfully giving us GLSL in new clothes, and developers are cheering them on, because they just read the W3C spec and ignore the realities of the standard.

---

Apple: "Having an isolated focus on SPIR-V is not a good perspective, we have MSL etc. to consider too"

...

Apple: "Extreme A is no interaction with SPIRV?, extreme B is very tightly coupled to SPIRV, we should find a middle point"

...

Google: "We take all targets into consideration. We can allow developers do runtime probing and maybe branch according to that. Optimization occurs in existence of uncertainty. Dealing with fuzziness is a fact of life and we should give the tools to developers to determine in runtime."

From https://docs.google.com/document/d/15Pi1fYzr5F-aP92mosOLtRL4...