Live data from Hacker News

Learn WebGPU for C++

eliemichel.github.io

11–17 of 17 posts

Re: Learn WebGPU for C++

#11
post #2

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…

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.

Re: Learn WebGPU for C++

#12
post #2

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…

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 inste…

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.

Re: Learn WebGPU for C++

#13
post #2

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…

Nvrhi sadly doesn't support metal. I use QtRhi and that gives metal, d3d11/12, Vulkan, OpenGL and even works on wasm

Re: Learn WebGPU for C++

#14
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

Re: Learn WebGPU for C++

#15
post #14

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…

So Sony and Nintendo are sad?

Re: Learn WebGPU for C++

#16
post #15
post #14

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…

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.

Post reply on HN