Wgpu: C-first versus Rust-first approach

[kvark]

Currently, the library exposes extern C API functions. A possible (strongly typed, nicer) Rust wrapping is expected to base on it, but it would have to operate on Handle things instead of placing the actual sub-structures where it needs. This is a possible (even if minor) performance hit that we are likely OK with (since Rust clients using wgpu are not the most demanding in terms of CPU perf).

Another benefit of C-first approach is increased chance from Gecko contributors who don't care much about Rust ecosystem wrappers. Still, the issue is open for discussion, since gfx-portability took a different approach (Rust-first) by basing on gfx-hal.

[msiglreith]

+1 for C-first
Mainly because the target API is defined in C and the Rust API will mostly follow this API. If I see it correctly the IDL still changes quite a bit so having to maintain an additional layer doesn't seem to be worth it at the moment in my eyes, considering the main user will be currently firefox only. Looking at the first bits of implementation, adjusting parts of the C-API seems to be quite straightforward.

The story with HAL is a bit different as VkPI wasn't in scope when our API was defined. The design decisions (middleground between all APIs) still bite us today like acquiring cmd buffers from pools :<

[grovesNL]

considering the main user will be currently firefox only

I think a Rust API would be used for applications which want to run both native and wasm targets. So the native target would use the C externs provided by wgpu-native, and the wasm target would use wasm host bindings for the WebGPU API. Although either approach (C- or Rust-first) would still work with that use case.

[kainino0x]

I'm personally interested in someday having a nice rustic API for WebGPU that works on Web, gfx-rs, and maybe Dawn. However there's no reason that couldn't be a thin shim over a C-like wgpu-native.

[kvark]

Interestingly, as I was implementing #13 , it occurred to me that we'll have an internal Rust layer anyway. We already do for things like Device, since it helps us to draw the generic backend boundary:

• internal Rust abstractions are generic over backends
• wgpu_xxx() functions and XxxId work with a concrete backend

So essentially, the Rust layer may just need to be exposed to the outside instead of being re-implemented as a wrapper on top of the C layer. I wonder if that is actually a requirement to extract any perf benefits from BAL.

Mainly because the target API is defined in C and the Rust API will mostly follow this API

Actually, WebGPU isn't defined in C, it's defined in WebIDL. C bindings are rather arbitrary. It's still unclear if we actually need those in order to target WASM (which was the incentive originally for me), given things like wasm-bindgen.

[kvark]

Correction to my previous statement: the internal Rust layer is neither complete or isolated:

• part of the essential logic is still inside the wgpu_xxx() functions, even though we could technically move it into methods of our internal structures
• we need to keep around things like DeviceId (see #16), which makes the internal abstraction totally depend on the C interface

In other words, it doesn't appear to be feasible now to try exposing this internal abstraction. We'll keep an eye on it. In the meantime, having Rust layer wrapping around C methods is the way to go.