Describe the pull request

The current implementation uses three integrated queues that it allocates when starting a backend. This is fine for applications that allocate commands in the order they need to be executed (after all Unity also uses only one queue), however it prevents more advanced GPU-side parallelism. For example, two queues could execute workloads in parallel until their results are required by a third queue. Additionally, it is now possible to use different dedicated transfer queues for host-device and device-host transfers. To support this, queues are now dynamically allocated and a new synchronization mechanism can be used to wait for fences on foreign queues.

The default queue interface has been removed and replaced with a newly unified method defaultQueue, that takes a QueueType and returns a pointer to a queue:

auto transferQueue = m_device.defaultQueue(QueueType::Transfer); // was: m_device.bufferQueue();
auto graphicsQueue = m_device.defaultQueue(QueueType::Graphics); // was: m_device.graphicsQueue();
auto computeQueue = m_device.defaultQueue(QueueType::Compute); // was: m_device.computeQueue();

Internally the queues are managed in a way, that they are allocated, depending on device capabilities. If no dedicated queues are available, the pointers could all point to the same queue. This is most important for two queues of one type, where creating does not guarantee to return two distinct queues, if the device does not support it.

auto graphicsQueue = m_device->createQueue(QueueType::Graphics); 
auto otherQueue = m_device->createDevice(QueueType::Graphics); // Can be the same as `graphicsQueue`, if device does not support multiple queues of type `Graphics`.
auto computeQueue = m_device->createQueue(QueueType::Compute); // Can be the same as `graphicsQueue`, if the device does not support dedicated `Compute` queues.

This is totally opaque to the caller, so use multiple queues, if you want to, but don't expect them to execute in parallel under all circumstances.

For synchronization, an additional overload for waitFor is available on a queue, that takes a reference to another queue and causes the queue to wait for a certain fence on the other one. This is a non-blocking call, meaning the program flow will immediately continue. However all submitted commands after the wait will be blocked, until the other queue has passed the provided fence.

auto fence = computeQueue->submit(computeBuffer);
graphicsQueue->waitFor(computeQueue, fence); // Blocks `graphicsQueue` until `computeQueue` has passed `fence`.

Render passes can now also be initialized on a certain queue instance. This allows for parallel render-graph implementations.

auto renderPass = makeUnique<RenderPass>(device, graphicsQueue);

// Alternatively:
UniquePtr<RenderPass> renderPass = device.buildRenderPass().executeOn(graphicsQueue);

With multiple queues flying around, it can be hard to track which command buffer needs to submit to which queue. To streamline this process, a command buffer now remembers the queue it has been created on and provides an submit method on its own:

auto commandBuffer = device.defaultQueue(QueueType::Graphics).createCommandBuffer(true);
commandBuffer->submit();

Related issues

• Closes Introduce present and post-processing queues. #58. Since dedicated queue allocation and inter-queue synchronization is now a thing, this can be implemented by clients.