You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Current fences use a combination of Mutex + Condvar, keeping a hold of a bool signifying the signaled state. The waiting code is a bit non-trivial and incorporates the best practices of Condvar usage.
I was thinking that it might be easier to instead track the last submitted command buffer:
Now, resetting a fence just puts it into Idle state. Submitting with a fence makes it remember the last command buffer in flight (with a strong reference, so it's not reused by the queue in the meantime).
Waiting for 0 time is now equivalent of checking the command buffer status for completion. Checking for infinite time is equivalent to waitUntilCompleted.
The only non-obvious part is waiting for an arbitrary amount of time. I was thinking that we may just pick a number (say, 1ms) and sleep on it then check again. I don't expect many apps to be very precise about waiting for a fence. At least, Dota doesn't use any numbers other than 0 or infinity.
The gains from this change are small but visible:
no more condvar magic, straightforward antidote use
less callbacks being assigned
The text was updated successfully, but these errors were encountered:
2254: Metal deferred command buffer optimizations r=grovesNL a=kvark
Fixes#2252Fixes#2238
~~I'm not 100% convinced this is a good thing to fix, but had to try it anyway, so might as well file the PR :)
Please take a (critical) look.~~
PR checklist:
- [ ] `make` succeeds (on *nix)
- [x] `make reftests` succeeds
- [x] tested examples with the following backends: metal
- [ ] `rustfmt` run on changed code
Co-authored-by: Dzmitry Malyshau <kvarkus@gmail.com>
Current fences use a combination of
Mutex
+Condvar
, keeping a hold of abool
signifying the signaled state. The waiting code is a bit non-trivial and incorporates the best practices ofCondvar
usage.I was thinking that it might be easier to instead track the last submitted command buffer:
Now, resetting a fence just puts it into
Idle
state. Submitting with a fence makes it remember the last command buffer in flight (with a strong reference, so it's not reused by the queue in the meantime).Waiting for 0 time is now equivalent of checking the command buffer status for completion. Checking for infinite time is equivalent to waitUntilCompleted.
The only non-obvious part is waiting for an arbitrary amount of time. I was thinking that we may just pick a number (say, 1ms) and sleep on it then check again. I don't expect many apps to be very precise about waiting for a fence. At least, Dota doesn't use any numbers other than 0 or infinity.
The gains from this change are small but visible:
antidote
useThe text was updated successfully, but these errors were encountered: