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)

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

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