Idea: auto-generated bindings for webgpu-native

[Korijn]

We could consider "splitting" the webgpu-native backend in 2 parts, one being autogenerated direct python bindings, and one being the translation layer to the IDL-standardized webgpu API, I documented this idea here. Idea originates from #480

We can combine the following tools to automatically generate bindings for webgpu-native:

• pyo3 and maturin to build python bindings
• a python script generate pyo3 bindings, using cffi to parse wgpu.h

These bindings will be more performant since they don't rely on cffi at runtime.

This would need to be done in a separate lib, that we can then depend on in wgpu-py to layer the IDL based API on top of the bindings.

We would not be able to use the binary releases of webgpu-native though; we'd have to build the bindings ourselves directly from rust source. So that's a bit of a bummer but not impossible. Because of that, we have a few choices:

• fork the webgpu-native repo
• depend on webgpu-native with cargo (not sure if this is realistic)

There is one other project we can look at for inspiration that already autogenerates bindings for C++ here: https://github.com/eliemichel/WebGPU-Cpp/

[almarklein]

What if we go for C-API bindings instead? Then we can use the binary wgpu-native releases, and use simpler tooling (e.g. cython).

[Korijn]

What if we go for C-API bindings instead? Then we can use the binary wgpu-native releases, and use simpler tooling (e.g. cython).

So we take the binary, the header file, and then wrap with cython? I'm not sure I know how to compile something like that. Would we dynamically link to the binary then?

It would indeed be a lot simpler to set up, that's for sure. I strongly prefer going this route if we can.

[almarklein]

The answer to all questions is "I think so". I'm pretty sure ppl use Cython for this sort of thing. But perhaps there are other tools too.