Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Waiting for asynchronous operations to finish (polling) #91

Closed
athas opened this issue Jul 26, 2021 · 10 comments
Closed

Waiting for asynchronous operations to finish (polling) #91

athas opened this issue Jul 26, 2021 · 10 comments
Labels
async Asynchronous operations and callbacks

Comments

@athas
Copy link

athas commented Jul 26, 2021

wgpu's compute example uses wgpuDevicePoll to block until the memory is mapped. This works, but wgpuDevicePoll is wgpu-specific. The JS API returns a promise that can be used for blocking here, but I cannot see how something similar can be done using just webgpu.h. Some mechanism for blocking until asynchronous operations are done should probably be added.

@Kangz
Copy link
Collaborator

Kangz commented Jul 26, 2021

This is a common pain point. Likewise in Dawn, people use wgpuDeviceTick to the same effect. However it is a constraint of the web platform at this moment that the browser can only fire promises (so the result of mapAsync) when control is yielded back to it. Fixing this would require more than a webgpu.h change, it would need so core JS event loop change to allow pumping the loop from inside JS/WASM execution.

There no effort started around this yet and it's not clear if it would be something W3C would be interested in. CC @kainino0x

@kvark
Copy link
Collaborator

kvark commented Jul 26, 2021

We could at least expose the non-blocking "tick" as a bad but working "solution"

@athas
Copy link
Author

athas commented Jul 26, 2021

What is a non-blocking tick?

I think exposing a synchronise-the-world operation is a fine stopgap solution. It's not efficient, but it is simple to understand, and does not block more elaborate mechanisms from being added in the future (and one could even argue that such crude synchronisation is useful for debugging).

@austinEng
Copy link
Collaborator

I think a non-blocking "tick" is what wgpuDevicePoll is if you set the force_wait argument to false? This is what Dawn's wgpuDeviceTick does.

I thought we had previously discussed but moving it to the instance as wgpuInstanceProcessEvents. It would be responsible for checking any callbacks and calling them if they have finished, in a non-blocking manner.

@athas
Copy link
Author

athas commented Jul 27, 2021

Ah, so wgpuDeviceTick will let WebGPU do something, although not necessarily everything, and then I can call it in a loop until the callback for the event I am interested in has been run?

@Kangz
Copy link
Collaborator

Kangz commented Jul 27, 2021

In native this works with Dawn, but it won't work when running in WebAssembly because you need to yield back control to the browser.

@athas
Copy link
Author

athas commented Jul 27, 2021

Sure, it'd just be a stopgap solution for now. It would still be nice with a solution that works for both wgpu and Dawn, but I suppose I can #ifdef my way out of it.

@eliemichel
Copy link
Collaborator

eliemichel commented Feb 24, 2023

A workaround that works for both Dawn and wgpu-native is to submit an empty command buffer:

bool done = false;
// [...] Call wgpuBufferMapAsync with a callback that turns done to true

while (!done) {
    // Do nothing, this checks for ongoing asynchronous operations and call their callbacks if needed
    wgpuQueueSubmit(queue, 0, nullptr);
}

edit: As noted bellow, this does no longer work since Dawn stopped checking callbacks when submitting an empty queue.

@unvestigate
Copy link

To spare you the same confusion I was going through I'd like to mention that right now, for Dawn, you have to call the wgpuDeviceTick() function to have your callbacks fire.

@kainino0x kainino0x added the async Asynchronous operations and callbacks label May 24, 2023
@kainino0x
Copy link
Collaborator

kainino0x commented Aug 3, 2023

Forgot we had this issue filed, for some reason! I'm planning to solve this in #199.

Closing this to centralize tracking there.

@kainino0x kainino0x mentioned this issue Aug 3, 2023
3 tasks
@kainino0x kainino0x closed this as not planned Won't fix, can't repro, duplicate, stale Aug 3, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
async Asynchronous operations and callbacks
Projects
None yet
Development

No branches or pull requests

7 participants