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