DeviceQueues

Remarks

What a frame on two queues should use. Where the device has timeline semaphores each segment is submitted with the points of the segments it waits on, and the waiting is the device's: the calling thread hands the work over and goes on recording. Where it does not, this is SerialisedQueues — the producing queue is drained, which is correct and slow.

⚠ The frame is the same frame either way, and that is a property to be tested rather than believed. Which path was taken changes what goes *between* the submissions and nothing that is in them: the same passes, in declaration order, recorded into the same segments, with the same barriers. UsesWaitValues says which path a given device took, so a test can run both against one graph and compare the recordings.

⚠ Neither path overlaps anything on a device with one queue family, which is every device this engine has been developed on. There the schedule is a single segment before any of this is reached — see Async.

Fields and properties (1)

• public bool UsesWaitValues

  Whether waits are enforced by value rather than by draining a queue.

Methods (4)

• public DeviceQueues(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 what the last frame did.

Used by (1)

• TimelineSubmissionTestsVixen.Graphics.RenderGraph.Tests