Closed attackgoat closed 1 year ago
To be clear, there is already synchronization of each resource, and they may be used on multiple threads today. What this PR adds is the ability to submit work concurrently on multiple threads. You may submit the same resource in two different RenderGraph
resolve operations (render_graph.resolve().submit(...)
) and that's fine, but you must wait for the submit(...)
function to return before calling it on another thread.
I hope the example will make it clear that doing things like loading resources on background threads and passing them to the main render thread, using application-provided synchronization, is supported now.
Adds the ability to support multiple queues on a
Device
. This enables submitting work on multiple threads simultaneously. This does not enable using the same resource on multiple threads simultaneously because the operation of setting internal state and submitting those resources to a queue is not atomic.I'm hesitant to implement any sort of locking or synchronization of the individual resources because simultaneous use can be safe as long as you follow the rule: wait until the submission completes before using elsewhere.
All device queues are in the same family and have the same priority.
TODO: