public sealed class SerialisedQueuesThe queues of a real device, with each segment's dependencies enforced by waiting for the queue it depends on to go idle.
Remarks
⚠ Correct, and slower than one queue. A wait for a queue to go idle is the biggest hammer the RHI owns, and using one per cross-queue edge means the second queue never overlaps the first — the frame does the same work in the same order and pays for the submissions on top. Nothing about the picture changes, which is the point: this is what makes the segmentation, the ownership transfers and the barriers reachable on a device that cannot express anything cheaper.
The primitive it does without is a timeline semaphore — one counter per queue, each submission signalling a value and each dependent submission waiting on the value its producer signalled. That exists now: TimelinePoint and Submit, used by DeviceQueues, which is what a frame should be given.
Still here, and still correct, for the two jobs it is better at. It is what DeviceQueues becomes on a device with no timeline semaphores — OpenGL, WebGPU, a Vulkan 1.1 driver that declines the feature — and it is the other arm of the A/B that proves the two paths draw the same frame. A golden image taken through it stays valid either way, because the frame is the same frame.
Methods (4)
public SerialisedQueues(IGraphicsDevice device)Creates one over a device's queues.
public ICommandList Begin(RenderGraphSegment segment)Opens a list for a segment.
public void Submit(RenderGraphSegment segment, ICommandList list)Takes a segment's list back, recorded.
public void Reset()Forgets which queues have been submitted to, for the next frame.
Used by (3)
- DeviceQueuesVixen.Graphics.RenderGraph
- QueueSchedulingTestsVixen.Graphics.RenderGraph.Tests
- TimelineSubmissionTestsVixen.Graphics.RenderGraph.Tests