Multithreading guarantees?

[PJB3005]

I'd like to know the exact rules around cross-thread object usage for the library.

Obviously, I assume things like separate command encoders can be used from different threads. How things work for resource management (device creation etc) is however less clear to me.

I saw that the exact rules for this were "decided aren't going to solve right now" on the WebGPU spec side of things, which isn't a great start, but I guess that was also for web workers and stuff which I don't know heads or tails of.

I'm a little rusty on the Rust side of things, but I assume that due to Rust's guarantees, structs like Device can only be used from one thread at the same time (so you'd need to at the very least mutex it).

If the Rust rules can be extrapolated to the C side (being careful, obviously) then that would mean I'd just need to wrap a mutex around objects like device and call it a day. That would however be more restrictive than APIs like D3D11 or (IIRC) Vulkan, which allow concurrent access to at least the device for resource creation.

Do I have these correct? Or is it more or less strict?

[cwfitzgerald]

It's thankfully much less strict. All types in wgpu-native are Send and Sync meaning they can be freely moved across threads. Additionally, most types operate on shared references, meaning you can use the concurrently without mutexes. The only exception is CommandEncoder/RenderPass which operate on unique references, meaning you need to synchronize access across threads.

webgpu-native is, on paper, the same, but I don't know what dawn's situation with threading is right now.

Threading on the web is a lot more complicated, so it makes sense they punted it off of v1

[PJB3005]

Ahh I missed that most operations operate on non-mut references so they can be shared. Great!