This resource taught me WebGPU a couple years ago. I can recommend it. It's the best WebGPU tutorial I've found. (The Rust one is quite good as well.) I used what I learned to make this simple game: https://alexpop11.github.io/Spec-Hops/ (space to drop bombs) and I have eliemichel to thank for that!
That's a fun read. I use WGPU, but from Rust, which has a roughly similar library.[1]
There are three levels of shims between the user application and the GPU - WGPU, the Vulkan library, and the Vulkan driver for the GPU. This varies a bit with the platform.
None of these do much work. They mostly move data around.
To draw something, with modern basic 3D graphics, the application creates a mesh object, which is a few big arrays. There are vertices with X, Y and Z coordinates, triplets of vertex indices to define triangles, and some other info. You create texture objects, which are just 2D pictures in memory.
Each object has a transform, a 4x4 matrix that transforms it into world space, and finally there's a camera transform which projects the scene onto the flat screen. And you provide some shader programs which run on the GPU to process that data.
All that data is moved, usually unmodified, into the GPU. Or placed where the GPU can reach it, in systems with "integrated graphics". The GPU's hardware and firmware then take that data and draw it.
So what are WGPU and the Vulkan layers doing? Managing memory, time and safety. They're responsible for allocating GPU memory, interlocking against changing data in the GPU while the GPU is doing something with it, and preventing cross-process memory accesses by keeping the GPU from doing things to memory of another process. This is more like the job of an operating system than a graphics program. These levels of the graphics stack don't do much graphics. The application says what to do in formats the GPU hardware understands.
There's a lot of cross platform stuff going on. WGPU can support quite a few graphics back ends. Its native language is Vulkan, but Direct-X is supported to keep Microsoft happy, Metal is supported to keep Apple happy, Android is supported to keep Google happy, WebGPU is supported to keep browsers happy, and OpenGL is supported to keep people with old hardware happy. There are some lowest common denominator problems; Android and WebGPU use subsets of Vulkan and run a few years behind desktop. The back end is not hidden from the application. Some special cases have to be handled, one of them being "integrated graphics". Also, Vulkan has a huge list of optional features, many of which are not available on older platforms. WGPU doesn't hide that; it tells the application what's available and the application has to handle it or say it can't.
Nicely built resource, found a couple of nits but pretty good starting point.
Although I feel like unless you need to specifically target web or extensive cross platform support, a better alternative for a higher level framework/library is nvrhi. Especially for C++ developers.
And I feel like if you are making for cross platform or web you are likely using Rust or writing your own game engine/library maybe I view of the ecosystem is skewed.
nvrhi is pretty freaking awesome but it doesn’t work on Mac. WebGPU can using Metal, nvrhi would need MoltenVK layer on Mac. Other than that, yes nvrhi
I mean it officially works with MoltenVK on Mac, they have been open to accepting fixes and patches regarding Apple/Mac specific stuff. So I don't think the won't work on Mac argument works.
But it's definitely not very mobile devices ready, you can get it to work though.
nvrhi looks really cool. However, I think the vast majority of use cases today do target web. The main exception is software which is too big to be quickly downloaded. Almost all other software benefits so much from web distribution that it's crazy not to do it. For example, in another comment I shared the game I made with webgpu. Because it's a website, someone here may play it. If you had to download a binary instead, I don't think anyone here would give it a try.
To be frank a vast majority of webgpu projects are going to require fairly massive download sizes, even moderately large games or things that could truly utilize webgpu over webgl2 which are much more widely available on devices.
I feel like at the moment the kinds of things webgpu is good for unless it has to be a website it's better done with a native library.
Because otherwise webgl2 is much more broadly available for broadly supported platform set.
I maybe be a complete moron not familiar with Github, but I wanted to have a look at the code and it took me solid 5 minutes of going through the website searching for a link to the repository, and the only one I eventually found was when I scrolled to the bottom and clicked the Github icon. Removing the path from https://eliemichel.github.io/LearnWebGPU/index.html leads to 404, no idea why that doesn't just lead to https://github.com/eliemichel. Don't know if it's just me, but I get unreasonably frustrated by things like this.
Pretty sure it's because GitHub allows the user to put content at the root of that URL. And it's an entirely separate domain to avoid cookie stealing or whatever.
It's a very useful guide, I used it when working on torch-webgpu some time ago. Elie also published few packages that help with using some WebGPU related things, I don't remember exactly what was that but I recall it saved me lots of time
This resource taught me WebGPU a couple years ago. I can recommend it. It's the best WebGPU tutorial I've found. (The Rust one is quite good as well.) I used what I learned to make this simple game: https://alexpop11.github.io/Spec-Hops/ (space to drop bombs) and I have eliemichel to thank for that!
That's a fun read. I use WGPU, but from Rust, which has a roughly similar library.[1]
There are three levels of shims between the user application and the GPU - WGPU, the Vulkan library, and the Vulkan driver for the GPU. This varies a bit with the platform. None of these do much work. They mostly move data around.
To draw something, with modern basic 3D graphics, the application creates a mesh object, which is a few big arrays. There are vertices with X, Y and Z coordinates, triplets of vertex indices to define triangles, and some other info. You create texture objects, which are just 2D pictures in memory. Each object has a transform, a 4x4 matrix that transforms it into world space, and finally there's a camera transform which projects the scene onto the flat screen. And you provide some shader programs which run on the GPU to process that data.
All that data is moved, usually unmodified, into the GPU. Or placed where the GPU can reach it, in systems with "integrated graphics". The GPU's hardware and firmware then take that data and draw it.
So what are WGPU and the Vulkan layers doing? Managing memory, time and safety. They're responsible for allocating GPU memory, interlocking against changing data in the GPU while the GPU is doing something with it, and preventing cross-process memory accesses by keeping the GPU from doing things to memory of another process. This is more like the job of an operating system than a graphics program. These levels of the graphics stack don't do much graphics. The application says what to do in formats the GPU hardware understands.
There's a lot of cross platform stuff going on. WGPU can support quite a few graphics back ends. Its native language is Vulkan, but Direct-X is supported to keep Microsoft happy, Metal is supported to keep Apple happy, Android is supported to keep Google happy, WebGPU is supported to keep browsers happy, and OpenGL is supported to keep people with old hardware happy. There are some lowest common denominator problems; Android and WebGPU use subsets of Vulkan and run a few years behind desktop. The back end is not hidden from the application. Some special cases have to be handled, one of them being "integrated graphics". Also, Vulkan has a huge list of optional features, many of which are not available on older platforms. WGPU doesn't hide that; it tells the application what's available and the application has to handle it or say it can't.
It's all plumbing.
[1] https://github.com/gfx-rs/wgpu
So Sony and Nintendo are sad?
Right. No console support.
On consoles, you need few shim layers, because there's only one possible graphics device. The game code often goes directly to the hardware.
Nicely built resource, found a couple of nits but pretty good starting point.
Although I feel like unless you need to specifically target web or extensive cross platform support, a better alternative for a higher level framework/library is nvrhi. Especially for C++ developers.
And I feel like if you are making for cross platform or web you are likely using Rust or writing your own game engine/library maybe I view of the ecosystem is skewed.
Nvrhi sadly doesn't support metal. I use QtRhi and that gives metal, d3d11/12, Vulkan, OpenGL and even works on wasm
nvrhi is pretty freaking awesome but it doesn’t work on Mac. WebGPU can using Metal, nvrhi would need MoltenVK layer on Mac. Other than that, yes nvrhi
I mean it officially works with MoltenVK on Mac, they have been open to accepting fixes and patches regarding Apple/Mac specific stuff. So I don't think the won't work on Mac argument works.
But it's definitely not very mobile devices ready, you can get it to work though.
nvrhi looks really cool. However, I think the vast majority of use cases today do target web. The main exception is software which is too big to be quickly downloaded. Almost all other software benefits so much from web distribution that it's crazy not to do it. For example, in another comment I shared the game I made with webgpu. Because it's a website, someone here may play it. If you had to download a binary instead, I don't think anyone here would give it a try.
To be frank a vast majority of webgpu projects are going to require fairly massive download sizes, even moderately large games or things that could truly utilize webgpu over webgl2 which are much more widely available on devices.
I feel like at the moment the kinds of things webgpu is good for unless it has to be a website it's better done with a native library.
Because otherwise webgl2 is much more broadly available for broadly supported platform set.
I maybe be a complete moron not familiar with Github, but I wanted to have a look at the code and it took me solid 5 minutes of going through the website searching for a link to the repository, and the only one I eventually found was when I scrolled to the bottom and clicked the Github icon. Removing the path from https://eliemichel.github.io/LearnWebGPU/index.html leads to 404, no idea why that doesn't just lead to https://github.com/eliemichel. Don't know if it's just me, but I get unreasonably frustrated by things like this.
> no idea why that doesn't just lead to https://github.com/eliemichel
Pretty sure it's because GitHub allows the user to put content at the root of that URL. And it's an entirely separate domain to avoid cookie stealing or whatever.
github.io is not a forge, it's static site hosting. Completely different product than github.com, but integrates with it nicely.
People use github.io to host sites that are developed on github.com or around projects hosted on github.com.
It's a very useful guide, I used it when working on torch-webgpu some time ago. Elie also published few packages that help with using some WebGPU related things, I don't remember exactly what was that but I recall it saved me lots of time
https://github.com/jmaczan/torch-webgpu
It irks me greatly that we landed on the term WebGPU for technology that is not bound to the web.
[dead]