Wgpu-rs: Compute test hangs

[kvark]

Just run cargo test and observe the hang. Mine was on macOS, 100% reproducible.

[kvark]

Could be related to #214, cc @lachlansneff

[lachlansneff]

By compute test, you mean hello-compute?

I worked on my machine, so I’m not sure what’s going on here.

[kvark]

Also, unfortunately the test was not built or ran for a while, so it's not clear which change broke it.
Just doing cargo run --example hello-compute sometimes runs for me, sometimes hangs.
Running just cargo test always hangs so far. It runs a test in examples/hello-compute.

[aloucks]

It's always going to deadlock because there isn't anything driving it. I tried to explain this on the PR.

Right now if I try to map a buffer asynchronously and use .await on that future, it's going to immediately deadlock because there isn't anything that can wake the waker (and we should not call Device::maintain / wgpu_device_poll from the future for the reasons described above).

[lachlansneff]

@alouks, in hello-compute, there is something driving it. The future isn’t awaited upon until after the device is polled in a blocking fashion.

[kvark]

Debugging async code is somewhat painful, unless I'm doing it wrong :) the call stack has pretty much nothing useful.

[aloucks]

This is only calling Device::poll once. If that one crank didn't cause your future to resolve, it's going to deadlock.

Because there is nothing driving the event loop here you'll need to call Device::poll repeatedly until buffer_future.poll() returns Poll::Ready.

https://github.com/gfx-rs/wgpu-rs/blob/0751806044ae74e99df795655581eed41008b49b/examples/hello-compute/main.rs#L107-L113

Can we rename Device::poll to Device::tick or Device::maintain -- something that indicates that it's not the same as future polling? The difference is subtle but the underlying concepts are different. Future::poll is to check state, execute an action and return. Where as Device::maintain is a cranking mechanism.

[lachlansneff]

In this case, the device is polled in a blocking fashion. This should block the thread until all asynchronous mappings currently installed complete.

Regardless, it's not working, so something is going on here.

[kvark]

fwiw, I agree that poll(true) is not really a poll()

[lachlansneff]

@kvark Maybe something along the lines of device.process(Poll/Wait)?

[kvark]

Actually, it's already device.poll(wgpu::Maintain::xxx);. Perhaps, poll needs to be renamed, or a separate wait function introduced.

[aloucks]

Perhaps, poll needs to be renamed

Yes, this was my suggestion. Dawn uses tick. Maybe use the same name? maintain would also work and that matches the core function name.