3 ms·
> This can be used to target Dawn, wgpu, and others, easing the creation of bindings for languages using C FFI I wish we could agree on something slightly more
by tormeh 3y ago
> This can be used to target Dawn, wgpu, and others, easing the creation of bindings for languages using C FFI
I wish we could agree on something slightly more ergonomic than a C FFI. The largest common denominator has to be slightly more advanced than C (if we decide to not accommodate C).
- flohofwoe 3y agoThe "ergonomic" API is the Javascript API. Of course that is only usable from Javascript (ok, and Typescript). If you want to use WebGPU from as many languages as possible, a C API is pretty much the only option. There's also a C++ API, but just as with the JS API, this is limited to a single language. For usage from Rust you can also use gfx-rs/wgpu, which has a Rust-idiomatic API (e.g. see: https://github.com/gfx-rs/wgpu/blob/trunk/examples/hello-triangle/src/main.rs https://github.com/gfx-rs/wgpu/blob/trunk/examples/hello-tri... - which to be honest doesn't look more "ergonomic" than the C API to me). Also, it's not like the C API is "unergonomic", it works with C99 designated initialization which makes it quite nice to use. The only downside is COM-style manual lifetime management via ref/release calls, but if you are used to Direct3D that's a no-brainer (it works exactly the same), and the C++ API has RAII wrappers for this stuff.
- bobajeff 3y agoYes but until we have this "more better thing" please continue to expose your libraries to the c FFI. Also, please make sure it's actually better before telling everyone to use it. Thanks.