Signal fences on CPU to reduce delays on muxed queues #2082
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Suppose we have two virtual queues
A
andB
both sharing the samevkd3d_queue
, and the application does something like this:then actually signaling the fence may be delayed until work submitted to
B
completes, which can delay both app threads waiting on the fence as well as command submissions to any queues that wait on said fence. To solve this, we instead queue up a CPU-side wait on the last submission performed by the signaling command queue and signal the fence manually.This also takes the early signal idea from #2075 and queues up a CPU signal in case the virtual queue has no pending submissions.
This expands upon the per-queue submission tracker introduced in 5ac0781, which now needs to be updated for all submissions made from d3d12 scope (waits, sparse binding, 11on12 interop stuff, etc) for correctness.