webgpu: Use safe callbacks & try_recv_timeout

[sagudev]

It also removes the need for HashMaps and BufferMaps struct that keep data alive until it was used by C callback.

Callbacks now do not send request to self anymore so https://sagudev.github.io/briefcase/fastgame.html actually works now.

We now do try_recv_timeout instead of running loop continuously.

---

• ./mach build -d does not report any errors
• ./mach test-tidy does not report any errors
• There are tests for these changes in WebGPU CTS

[sagudev]

NOTE-TO-SELF: Ipc-channel created from response_async should only send one message back (wgpu runs callback also on failures at buffer map async).

[gterzian]

So I've looked a bit into https://docs.rs/wgpu-core/0.20.0/src/wgpu_core/device/global.rs.html#2391, and I'm wondering if we really need the callbacks for the map asyncs. It seems to just makes things more complicated, see for example the lock around webrender.

This is different from the closures of submitted work done, because those are actually called at a later stage from when they are submitted. But the map asyncs callbacks are just called right then and there.

I think https://docs.rs/wgpu/latest/wgpu/struct.BufferSlice.html#method.map_async only applies to when you are using the higher-level wgpu API. the wgpu-core buffer_map_async calls the callback synchronously.

If that is correct(I think it is, but let me know if you think otherwise), I would say we should remove the callbacks, and the locks.

[gterzian]

Can we not just call global.buffer_map_async synchronously, and then handle the result and do the webrender stuff?

[gterzian]

same here: do we need the callback?

[sagudev]

Callback is called synchronously only when result if there is immediate failure (mostly validation): https://docs.rs/wgpu-core/0.20.0/src/wgpu_core/device/global.rs.html#2388 (we currently handle this twice, see #32172)

I think I can see why you get confused by callbacks (I got too for few moments), but op (BufferMapOperation that contains callback) is passed to https://docs.rs/wgpu-core/0.20.0/src/wgpu_core/device/global.rs.html#2498 as described in https://github.com/gfx-rs/wgpu/blob/08efa72a83d0acdf25177408150e4c87933c1cd7/wgpu-core/src/device/life.rs#L222 and triggered on maintain (it's called by device_poll) here: https://github.com/gfx-rs/wgpu/blob/08efa72a83d0acdf25177408150e4c87933c1cd7/wgpu-core/src/device/resource.rs#L455 (later this function returns both submission and mapping closures, that are actually fired in poll functions).

So yeah I think callbacks are really needed (if they were not, they would not be in wgpu). You can always ask in wgpu matrix channel if my explanation is to messy.

[gterzian]

So yeah I think callbacks are really needed

Ok, I now see the callback is stored over at https://github.com/gfx-rs/wgpu/blob/bdf30fa45aa86b827749f7ee45ed342ce27b0fbb/wgpu-core/src/device/global.rs#L2498

LGTM!