In regards to the boilerplate: Yes, for the first draw you require a lot, but after that, it quickly becomes almost neglible.
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.
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
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.
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++.
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.
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.
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.