Repository navigation
WaitAny on OnSubmittedWorkDone does not wait for submitted works' callbacks #513
Description
Activity
Hello, unfortunately, this is currently by design. The intention here is that if you need the result of the
MapAsync, you should beWaitAny-ing thewgpu::Futurereturned from it, not any otherwgpu::Futures. Your idea to use a different mode, i.eAllowSpontaneousorProcessEventsin theMapAsyncand thenWaitAny-ing theOnSubmittedWorkDonewould make sense, but that isn't implemented in Dawn at the moment. We can investigate that solution in the meantime. Note thatAllowSpontaneousis still very much a work-in-progress in Dawn because it isn't a high priority and comes with many technical difficulties... (looking at you Vulkan...).Thanks for answering! I'll stick with
WaitAnyfor now.As for
AllowSpontaneous, I think it would be more useful if the API actually specifies the timing when callback is called. Using my above example, it would be great if the callback is guaranteed to be called in the thread whereWaitOnlyis called forOnSubmittedWorkDone, however the documents give me a feeling that the callback could even be called in device threads on some platforms.it would be great if the callback is guaranteed to be called in the thread where
WaitOnlyis called forOnSubmittedWorkDone.If you want this garranty, I think you can simply not use
AllowSpontaneous. Then of course your (only) thread needs to hand the execution to the WebGPU instance from time to time to let it run the callbacks, which is whatProcessEventsis for.Collecting all futures and then pass them all to WaitOnly is also not practical because number of futures WaitOnly can take is quite small and even a linear regression program can exceed it.
I'm curious about the details of your regression program, if I may. The way I imagine it, you would mostly have to wait for 1 future, namely the one that maps the result back on the CPU.
Considering following code:
Intuitively I would assume the callback of
MapAsyncwould be called whenWaitOnlyreturns, but it does not because the future ofMapAsyncis not passed toWaitOnly.However collecting all futures and then pass them all to
WaitOnlyis also not practical because number of futuresWaitOnlycan take is quite small and even a linear regression program can exceed it.The options I have are:
WaitOnlybut instead of one single call I split the futures into multipleWaitOnlycalls.MapAsyncand then callProcessEventsafter callingWaitOnly. (Note that even withAllowSpontaneousI still need aProcessEventsto make the callback get invoked, I don't know if it is intended or a bug.)But:
WaitOnlyapproach is overkill and hard-to-use when I only want to wait for submitted work done.MapAsyncwould makeOnSubmittedWorkDone's callback get called beforeMapAsync's callbacks.