WebGPU

[Scott_Arm]

Really interesting read. I'm just getting through the API history and one of the more interesting things that's claimed is that Vulkan was not designed to be targetted by programmers broadly. The expectation seemed to be that most game devs would use middleware like UE, Unity and those middleware would leverage the APIs directly.

Literally. Khronos does not want you to write Vulkan, or rather, they don't want you to write it directly. I was in the room when Vulkan was announced, across the street from GDC in 2015, and what they explained to our faces was that game developers were increasingly not actually targeting the gaming API itself, but rather targeting high-level middleware, Unity or Unreal or whatever, and so Vulkan was an API designed for writing middleware. The middleware developers were also in the room at the time, the Unity and Epic and Valve guys. They were beaming as the Khronos guy explained this. Their lives were about to get much, much easier.

...

Khronos did not forget about you and me. They just made a judgement, and this actually does make a sort of sense, that they were never going to design the perfectly ergonomic developer API anyway, so it would be better to not even try and instead make it as easy as possible for the perfectly ergonomic API to be written on top, as a library. Khronos thought within a few years of Vulkan⁸ being released there would be a bunch of high-quality open source wrapper libraries that people would use instead of Vulkan directly. These libraries basically did not materialize. It turns out writing software is work and open source projects do not materialize just because people would like them to⁹.

I want to talk about WebGPU

WebGPU is the new WebGL. That means it is the new way to draw 3D in web browsers. It is, in my opinion, very good actually. It is so good I think it will also replace Canvas and become the new way to draw 2D in web browsers. In fact it is so good I think it will replace Vulkan as well as normal...

cohost.org

Seems like this will go on to suggest WebGPU as a general alternative API, not just for web.

Edit: So WebGPU is basically Metal for web browsers, because Apple got their way, but Metal is generally well liked by devs for being the most pleasant to use. You can use WebGPU in standalone apps written in Rust or C++. It basically has standalone libraries for that purpose that match the web implementation. If you use it with standalone apps it sounds like SPIR-V might be an option instead of using the new WGSL. WebGPU basically gets translated into a native API (Metal, Vulkan, D3D) depending on which platform you are using. So WebGPU is the high-quality wrapper library that Vulkan had hoped would show up, it just took a long time to appear.

WebGPU spec https://www.w3.org/TR/webgpu/
WGSL spec https://www.w3.org/TR/WGSL/
Rust tutorial https://sotrh.github.io/learn-wgpu/
C++ tutorial https://eliemichel.github.io/LearnWebGPU/

Edit:
Found this cool blog post comparing graphics APIs. This blog in general looks very good.

A Comparison of Modern Graphics APIs

Low level Graphics APIs such as DirectX 12, Vulkan, Metal, and WebGPU are converging to a model similar to the way GPUs are currently built. In this article we'll review modern graphics APIs and how they compare with older graphics APIs such as OpenGL in their design and data structures.

alain.xyz

 

[DavidGraham]

Wow, just wow, the story of of these supposedly better lower level APIs keeps unraveling, and not for the better I must say.

 

[Scott_Arm]

Wow, just wow, the story of of these supposedly better lower level APIs keeps unraveling, and not for the better I must say.

The logic of it actually makes sense. The API is designed so that it can be leveraged by pretty much any programming language that has any memory model, and it's designed to leverage the hardware more than it is designed to be simple to use. That makes sense for large game engines, whether it's UE, Unity or some internal game engine that would used by multiple studios to develop Call of Duty every year etc. You have technical experts that handle the renderer and that renderer is leveraged by many games. Where it starts to fall apart is AA games, indie games, graphics researchers, hobbyists. Vulkan has failed in the sense that the barrier to entry is very high. You really have to have a good understanding of graphics and graphics hardware before you can get started, or it'll be very difficult to understand what's going on. They probably should have had an official high-level API built on top of Vulkan to be more broadly usable by all skill levels or project sizes.

WebGPU looks like it might strike a nice balance in terms of offering some of the advantages of a low level API while being easier to get started with. If I get back into trying to learn this stuff it's probably where I'll start.

 

[DegustatoR]

The logic of it actually makes sense. The API is designed so that it can be leveraged by pretty much any programming language that has any memory model, and it's designed to leverage the hardware more than it is designed to be simple to use. That makes sense for large game engines, whether it's UE, Unity or some internal game engine that would used by multiple studios to develop Call of Duty every year etc. You have technical experts that handle the renderer and that renderer is leveraged by many games. Where it starts to fall apart is AA games, indie games, graphics researchers, hobbyists. Vulkan has failed in the sense that the barrier to entry is very high. You really have to have a good understanding of graphics and graphics hardware before you can get started, or it'll be very difficult to understand what's going on. They probably should have had an official high-level API built on top of Vulkan to be more broadly usable by all skill levels or project sizes.

Except the reality shows that it's mostly the opposite - i.e. D3D12/VK do "fine" (worse than DX11 did performance wise often but without glaring issues at least) when they are being used by an "AA game" which takes what is supplied by a 3rd party engine, adhere to its requirements and don't add or tweak anything on top of it.

Once we move into AAA production all the issues start to explode (or implode, whatever) because you really can't do a AAA game with whatever is supplied within the engine license itself and you're very likely to customize that to some degree, either because you want more from graphics or because your gameplay doesn't fit the default engine well.

The main idea that there would only be a dozen of engines and every game will just use them with whatever default shaders they ship with has always smelled suspiciously misaligned with the real world use cases. Now it is backfiring in pretty much every new AAA release to the point where none of the so called "advantages" of these new APIs are actually showing up in shipped code. CPU usage? Broken most of the time, in both threading and utilization. GPU usage? Still lower than what DX11 shows when there's a compare option.

I dunno if WebGPU being an API running on top of an API running on top of an emulation layer will ever be used for any sort of a serious game release but the general idea that an API should in fact be suitable for use by any graphics programmer (as opposed to those select few who "gets it"; albeit we don't really see many of those even in graphical powerhouses like Epic apparently) to be "good" seems like a solid foundation for any future development of D3D and VK. Now everyone just needs to figure out how to make it "good" without losing whatever advantages the new APIs have (or rather promised as we don't really see these advantages in actual shipping titles often if at all).

 

[Scott_Arm]

@DegustatoR I don't want to turn this into another Vulkan D3D performance thread. I think one of the main issues with Vulkan is that even the most technical people find it difficult to use. Nobody likes the syntax. It's designed the way it is for a reason, but it's incredibly "verbose." The amount of lines of code you have to write to put a triangle on screen is much higher than other APIs. The design of WebGPU is intended to be relatively easy for all levels, like Metal. It's nothing to do with performance, so much as just being able to figure out how to draw to the screen, or being able to build small things more rapidly. Vulkan probably should have shipped with an additional API similar to WebGPU to give people a simpler starting point. People who are trying to learn 3D rendering have a difficult choice at the moment, where some people recommend starting with OpenGL or D3D11 because it's just way easier to get going, but then they're investing time in something that's obsolete, so some say to bite the bulllet and go straight to Vulkan, which is a tough hill to climb.

 

[TopSpoiler]

https://twitter.com/x/status/1769744539777106032

 

[TopSpoiler]

GitHub - Scthe/nanite-webgpu: UE5's Nanite implementation using WebGPU. Includes the meshlet LOD hierarchy, software rasterizer and billboard impostors. Culling on both per-instance and per-meshlet basis.

UE5's Nanite implementation using WebGPU. Includes the meshlet LOD hierarchy, software rasterizer and billboard impostors. Culling on both per-instance and per-meshlet basis. - Scthe/nanite-webgpu

github.com

This project contains a Nanite implementation in a web browser using WebGPU. This includes the meshlet LOD hierarchy, software rasterizer (at least as far as possible given the current state of WGSL), and billboard impostors. Culling on both per-instance and per-meshlet basis (frustum and occlusion culling in both cases). Supports textures and per-vertex normals.

 

[digitalwanderer]

So did WebGPU ever become a thing? I've still barely heard of it.

 

[TopSpoiler]

So did WebGPU ever become a thing? I've still barely heard of it.

It will quietly replace WebGL in the near future. Even though WebGPU is developing, I don't expect commercial games to be released due to the open nature of the web.

 

[Scott_Arm]

So did WebGPU ever become a thing? I've still barely heard of it.

I think Apple still has it in preview in Safari, and not all implementations are feature complete yet. Just taking time.