-
Notifications
You must be signed in to change notification settings - Fork 45
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
Comments
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 |
We could at least expose the non-blocking "tick" as a bad but working "solution" |
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). |
I think a non-blocking "tick" is what 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. |
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? |
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. |
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 |
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. |
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. |
Forgot we had this issue filed, for some reason! I'm planning to solve this in #199. Closing this to centralize tracking there. |
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.The text was updated successfully, but these errors were encountered: