WebGPU native (C header/API) backend for wgpu-rs

[kvark]

Is your feature request related to a problem? Please describe.
wgpu-rs currently has 2 backends: direct (for wgpu-core) and web (for WebGPU on wasm32 target).
We need to add a 3rd backend: native, for implementing https://github.com/webgpu-native/webgpu-headers

Describe the solution you'd like
Adding this backend should be straightforward. We would dynamically link with an implementation, be it wgpu-native or Dawn library.

Describe alternatives you've considered
Using the C API as the main target, and then adding a backend for wgpu-core. We irreversibly changed this direction a while ago.

Additional context
servo/pathfinder#306 (comment)

[Gordon-F]

Does this also meaning, that this backend would have blazing fast compile time for native targets? It should have only one dependency - libloading.

[kvark]

Yes, that's right. Given the stable C API, it should be very fast to build. As fast as the Web backend.

[Gordon-F]

These might be a game-changer for users who avoid using Rust and wgpu because of compile time. Maybe miniquad users, for example, will take a look at wgpu.

[zicklag]

Would it make sense to have like a WebGPU Rust trait that would have implementations for both web_sys and for the C API?

Then users could also bring their own WebGPU trait implementations if they wanted to do something like network rendering ( one of the use-cases mentioned in the pathfinder issue ).

[cwfitzgerald]

We already basically have this. We have a unified trait in wgpu-rs that has all the appropriate backends.

I'm not entirely convinced there is good reason to make that trait fully switchable. That being said it would allow for a bunch of clever things such as wgpu plugins that work through intercepting calls to the backend.

[cwfitzgerald]

I don't think there exists an amazing reason to have this right now and the likelyhood of anyone doing this is pretty low.

If someone has a good use case for it, please file a new issue.