Hacker News Reader

Comment by flohofwoe | Hacker News Reader

Both APIs are not all that great, Vulkan has a steep learning curve and requires tons of boilerplate code to even get a triangle on screen, and OpenGL is 30 years of sediment layers all pressed into a single 3D API.

WebGPU is currently probably the best balance between:

- easy to learn

- easy to tinker with (in web browsers at least)

- modern concepts (close enough to Metal, Vulkan and D3D12 that what you learned carries over)

- platform-agnostic

If you are on Windows, D3D11 is also a good native option, as is Metal on macOS.

View on HN

>WebGPU

A massive shame that it's more or less bolted to the Sodom and Gomorrah of modern software development (Browsers and JS). Atleast in mindshare for sure.

There appears to be a non browser implementation of WebGPU now looking into it, but I can't find anyone using it or attempting to use it in production

https://dawn.googlesource.com/dawn

dawn is the WebGPU backend in chromium, while wgpu is the WebGPU backend for firefox written in Rust. wgpu is seeing a lot of use in non-browser uses; there are some examples on their website.

https://wgpu.rs/

Actually there is something great related to that.

Despite my usual rants on how they are outdated in regards to native APIs, there is a great plus for them, WebGL and WebGPU are the only 3D APIs designed from scratch for managed languages.

<webgpu/webgpu.h> is actually a very decent C API (it does have explicit lifetime control via 'reference' and 'release' calls like COM though, but that's okay-ish - same rules as D3D basically).

So far I have only bothered with the actual browser version in Chrome.

It goes beyond it, because CPU-GPU interfaces were also designed with JavaScript GC in mind.

Hence why on Android they are finally thinking about using WebPGU to expose Vulkan to app developers, as most keep using GL ES instead of downgrading their developer experience dealing with NDK, C and C++.

There's standardized C API which is both implemented by Dawn and wgpu.rs:

https://github.com/webgpu-native/webgpu-headers/blob/main/we...

...and this standardized API would also enable other independent native implementations (and shader compilation aside, it's actually not in the realm of the impossible to write a WebGPU implementation from scratch with a small team or even alone).

There's even thought put into the API being extensible via 'struct chaining', this is how the native implementations also accept SPIRV shader bytecode instead of just WGSL shader source code.

It's worth noting that both Dawn and wgpu (the two primary WebGPU implementations currently) disagree on key parts of that API - particularly around instance creation, and so they are not ABI compatible today.

If you're building an application, you'd better make sure you are using _the implementation's version_ of the webgpu.h header today.

Hopefully one day it does become fully standard.

> Vulkan has a steep learning curve and requires tons of boilerplate code to even get a triangle on screen

In regards to the boilerplate: Yes, for the first draw you require a lot, but after that, it quickly becomes almost neglible.

Hopefully, WebGPU will eat all its competition and we can finally have just one standard moving forward.

Nah, competition is good :)

E.g. without Metal as example of what a modern user-friendly 3D API can look like, WebGPU would probably look very different, and not in a good way.

My personal hope is that the concept of a "3D API" will eventually disappear into compilers like Clang and GCC and their standard libs.

E.g. WebGPU has a pretty big API surface just for ensuring that the CPU-provided data is compatible with what the GPU expects, and any mismatches manifest as runtime errors, not compile-time errors.

Most of this API surface would simply disappear if the same compiler can see both the CPU and GPU side code, integrated into the same compilation process.

Good luck convincing console vendors.

Reply on news.ycombinator.com