wgpu: webgpu.h backend

[rajveermalviya]

The wgpu crate currently has two backends wgpu-core and web-sys (wasm), this is to add another backend that targets the webgpu.h C API. Having such an implementation would allow users to have an option to test/use their Rust app with other webgpu implementations, Dawn (Chromium) and maybe WebGPU.framework (WebKit).

One of the main goal of this backend is to provide better testing infrastructure for wgpu-native's C bindings. Additionally, it hopefully would also allow testing those tests against Dawn & WebGPU.framework implementations.

For wgpu-native, in addition to better testing it would also allow us to better track inclusion of new extensions and exposing current missing ones. Unifying the list of features exposed between wgpu-native and the Rust API.

Roadmap

• webgpu-sys crate (Raw (generated) Rust->C bindings targetting webgpu.h)
• Initial prototype of webgpu-sys backend for wgpu crate, gated behind a feature.
• webgpu-sys: generate bindings for impl specific extensions exposed via wgpu-native.
• Test against wgpu-native, and fix any failures.
• Test against Dawn.
• Try testing against WebGPU.framework (WebKit).
• Setup CI job for testing wgpu-native backend. (Not really sure if we should test against Dawn in CI, we would have to setup Dawn builds elsewhere)
• Implement and expose all the wgpu-core native extensions in wgpu-native.
• Call the webgpu-sys backend GA.
• Investigate impl specific extensions exposed via Dawn & WebGPUExt.h (WebGPU.framework).

[waywardmonkeys]

This sounds like it might help for something I was thinking about for my own use cases.

I currently have a C++ application that is using wgpu-native. I was thinking about wrapping parts of vello in a C / C++ API, but since it renders via wgpu, I wasn't sure yet how I was going to map all of that to a decent build and linking strategy, but if wgpu had a webgpu.h backend, it would be able to call back into my separately linked wgpu-native and its copy of wgpu, right?

[rajveermalviya]

If the goal is for the C/C++ app is to use vello as well as interact with wgpu api directly, that does seem like a valid usecase, it would help avoid depending on multiple copies of wgpu.