Hacker News Reader

Comment by ChadNauseam | Hacker News Reader

A middle ground is webgpu. It is much less verbose than Vulkan and is guaranteed to run anywhere, including the browser. At the same time, it has access to "modern" features like compute shaders which would not be available in webgl. It also doesn't have much legacy cruft leading to multiple ways of doing the same thing, unlike opengl. The main advantage is that it's new, so there are many fewer tutorials available for it, and that is a very serious disadvantage.

View on HN

Not to downplay it or anything, but I'm curious why webgpu is receiving so much attention? There have been many low-level cross-platform graphics abstractions over the years. The bgfx [1] project had its first commit ~12 years ago and it's still going! It's much more mature than webgpu. I'm guessing being W3C backed is what's propelling it?

[1] https://github.com/bkaradzic/bgfx

webgpu is a modern graphics API for modern GPUs to replace/complement these two APIs in the browser: WebGL (a very limited outdated subset of OpenGL) and Canvas (basically WinAPI drawing from 2000s)

It's heavily influenced by Metal (based on original work by Apple and Mozilla).

People are talking about it because it's on the web and it's finally something modern to work with.

> webgpu is a modern graphics API

TBF, WebGPU is at least a decade behind too. For instance it implements a Vulkan-style rigid render pipeline model which even Vulkan is moving away from because it turned out too rigid. So once WebGPU becomes mainstream it may very well be the most "awkward" 3D API.

Don't worry, browsers will then come up with a fourth graphics API to solve all the issues of the previous three :)

One remarkable feature of WebGPU is that it has no undefined behaviour, traditional 3D APIs are riddled with subtle UB. It also receives much better testing across all sorts of hardware and driver configs, just by being integrated with web browsers.

My perspective is it’s a couple things. Mainly because it’s backed by several implementations with market pressure to deliver high quality working implementations (wgpu in Firefox, Dawn in Chrome). Not saying bgfx or others are bad, but the Chrome team will be putting in a lot of work for you to make sure Dawn works well everywhere Chrome needs to be. That plus it’s super portable. First time in a long time that we could truly be looking at a “write once run anywhere” GPU API. It also fills OpenGL’s niche by being much more approachable than Vulkan. I guess this really just adds up to it being the “OpenGL 2” a lot of people have been wanting in light of Vulkan’s complexity and weaker portability.

Compute shaders aren't available in WebGL thanks to Google, OpenGL ES does them just fine.

WebGL isn't WebGPU. WebGPU has compute shaders: https://docs.rs/wgpu/latest/wgpu/struct.ComputePass.html https://www.w3.org/TR/WGSL/#compute-attr

(Edit: ah, I missed the bit in GP that you replied to.)

That doesn't invalidate what I said, rather that we could have gotten WebGL 2.0 Compute much sooner than WebGPU if it wasn't for bloody politics among browser vendors.

https://github.com/9ballsyndrome/WebGL_Compute_shader

https://github.com/9ballsyndrome/WebGL_Compute_shader/issues...

https://issues.chromium.org/issues/40150444

"Intel spearheaded the webgl2-compute context to provide a way to run GPU compute workloads on the web. At the same time, the WebGPU effort at the W3C aimed to design a new, lower-level graphics API, including GPU compute. The webgl2-compute approach encountered some technical barriers, including that macOS' OpenGL implementation never supported compute shaders, meaning that it wasn't easily portable. webgl2-compute has so far been used by customers for prototyping.

At present, WebGPU is close to shipment, and its shader pipeline is nearing completion. It's possible to run combined GPU rendering and compute workloads in WebGPU.

In order to reclaim code space in Chromium's installer that is needed by WebGPU, the webgl2-compute context must be removed."

Because webgl2-compute took soooo much space on the installer!

And it isn't as if Google isn't doing WebGPU compute on top of DirectX on Windows, but doing it on top of Metal on Apple, unthinkable!

By the way, where are the Safari and Firefox implementations of WebGPU compute, running on stable without browser flags?

I thought its browser support was pretty bad? https://caniuse.com/webgpu

Firefox and Safari don't support it yet. And how would you even deploy it to Steam (edit: or rather, make a desktop or mobile game with it)? Can you wrap it in a webview?

Doesn't seem mature...

There is a native API too, not just JS. You can link it into your game like any other library.

I'm confused now. I thought by definition it's a browser API that allows them to make Vulkan/OpenGL/DirectX calls, like an abstraction layer. Am I wrong?

Edit: wgpu is a reimplementation of the WebGPU api for use with desktop apps outside of browsers. See sibling thread by another poster for an explanation: https://news.ycombinator.com/item?id=40598416

wgpu isn’t a reimplementation of WebGPU, it’s Firefox’s WebGPU implementation. It also conveniently runs outside of a browser and is accessible with a Rust or C API. You can also do the same thing with Dawn, which is Chrome’s implementation of WebGPU.

Thanks for the correction!

It's a JavaScript API, it only runs in the browser. It's not real.

That's just not true. https://wgpu.rs/

I'm literally writing native code running on linux with winit and wgpu right now.

Wait, is that the same as using WebGPU? It says outside of browsers it uses opengl and vulkan and directx.

Yea, wgpu is basically an adapting layer between the WebGPU API and opengl, vulkan, directx. So it's the same† API.

But WebGPU in the browser is also an adapting layer between those technologies, it's just the browser that does the adapting instead of the wgpu library. For Firefox, WebGPU is adapted to those underlying systems by wgpu: https://github.com/gpuweb/gpuweb/wiki/Implementation-Status

† There are some "native-only" extensions beyond the WebGPU spec that gpu provides, so it does go a little beyond WebGPU. But for the most part, it's very similar.

Wait... so if webgpu (the API) is to allow browsers to use the underlying graphics libs... but desktop apps can access those directly... why would they want to go through the browser abstraction API instead? Better dev ex and ergonomics?

> why would they want to go through the browser abstraction API instead? Better dev ex and ergonomics?

That and portability. The ergonomics are always up for debate, but I find it a much more modern and nicer interface than OpenGL which feels...quite dated. How it compares to something like Vulkan or Metal is up for debate.

But for portability if I write my code using directx, then I can only run it on systems with directx. If I write it for vulkan, I can only target systems with vulkan. If I write for metal, I can only target systems with metal.

However, if I use wgpu and the WebGPU API, I can target any system that has directx or vulkan or metal or OpenGL. I can also target wasm and compile my application for the web.

So, I can really easily write code that will run natively on linux, on osx, on windows and the web and will use the graphics library native to that platform.

I see now. Thanks for explaining! That makes a lot of sense.

wgpu is not WebGPU. One is a Web specification, the other is a Rust library.

wgpu is also not a graphics API, it's a library that abstracts the underlying graphics API.

Even more confused now, lol.

(edit: thanks for editing your post. the revised version clears it up!)

Vulkan, Direct3D, Metal and OpenGL are graphics APIs - the implementation comes with your GPU driver, and they're as close as you can reasonably get to writing code "directly for the GPU". When you call a Vulkan function you're directly calling driver code.

wgpu is a regular library that uses the native APIs above and abstracts them from you. I don't like calling it a graphics API because it implies it's the same as the vendor-provided APIs - it's a completely different beast.

WebGPU and WebGL are Web standards that the browser implements, and you program them via JS. Similarly to wgpu, they're implemented on top of the native graphics APIs.

The relationship between wgpu and WebGPU is that they're basically made by the same people, and in Firefox WebGPU is implemented on top of wgpu.

But saying "WebGPU runs everywhere" is plain wrong - it's a browser-exclusive API, and on top of that, at the point of writing this it doesn't even run on all browsers (71% support according to https://caniuse.com/webgpu)

But clearly libraries like wgpu implement WebGPU while not requiring a browser. So WebGPU is not browser-exclusive.

> The relationship between wgpu and WebGPU is that they're basically made by the same people, and in Firefox WebGPU is implemented on top of wgpu.

I think that’s understating the relationship a bit. The wgpu API follows the WebGPU spec quite closely. It’s like saying “taffy isn’t flexbox”. You can make a technical argument that it’s not identical, and to be flexbox it must be in a browser, but anyone working with taffy will recognize that it’s implementing flexbox and will find that all their understands of flexbox apply to taffy.

Similarly, most of what I’m learning working with wgpu (outside of, maybe, threading), is directly transferable to WebGPU. And vice versa.

That's fair, my comment did understate their relation quite a lot. They are very closely linked, to the point stuff has been added to the WebGPU spec pretty-much because "eh, it's already in wgpu".

But the "knowledge is transferable to WebGPU" is key. Even when you're compiling your wgpu code to WASM, you're not using WebGPU directly - for every API call, you're going through generated bindings on the Rust side and then generated bindings on the JS side where the actual call is made. The JS wrappers aren't trivial either - Rust structs need to be converted to the nested JS objects required by WebGPU spec, numeric enums need to be converted strings, etc.

Considering that WebGPU is supposed to be the low-level graphics API for the Web, DX12/VK/Metal equivalent, all this is at least worth a mention, and "wgpu == WebGPU" brushes over a all that, to the point where we're now casually throwing statements like "[WebGPU] is guaranteed to run anywhere, including the browser".

Reply on news.ycombinator.com