4 ms·

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 yea

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.

Akronymus 3y ago
> 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.
hajile 3y ago
Hopefully, WebGPU will eat all its competition and we can finally have just one standard moving forward.
- flohofwoe 3y ago
  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.
- pjmlp 3y ago
  Good luck convincing console vendors.
no_time 3y ago
>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 https://dawn.googlesource.com/dawn
- crthpl 3y ago
  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/ https://wgpu.rs/
- pjmlp 3y ago
  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.
  - flohofwoe 3y ago
    <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).
    - pjmlp 3y ago
      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++.
- flohofwoe 3y ago
  There's standardized C API which is both implemented by Dawn and wgpu.rs: https://github.com/webgpu-native/webgpu-headers/blob/main/webgpu.h 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.

Akronymus 3y ago

> 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.

hajile 3y ago

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

flohofwoe 3y ago
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.
pjmlp 3y ago
Good luck convincing console vendors.

no_time 3y ago

>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 https://dawn.googlesource.com/dawn

crthpl 3y ago
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/ https://wgpu.rs/
pjmlp 3y ago
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.
- flohofwoe 3y ago
  <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).
  - pjmlp 3y ago
    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++.
flohofwoe 3y ago
There's standardized C API which is both implemented by Dawn and wgpu.rs: https://github.com/webgpu-native/webgpu-headers/blob/main/webgpu.h 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.