DirectX 12 exposes command queues for either graphics (called "Direct"), compute or copy tasks. In terms of provided functionality, each one is a super-set of the following one. The specification states that command queues can be executed concurrently by the device. However, the API does not limit the number of command queues in any way (at least I am not aware any limitation).
Apparently, different vendors handle this very different:
- Intel states in a recent presentation (slide 23) that currently their GPUs are not able to handle Graphics & Compute in parallel and that the copy engine has a weak throughput. They advise against the use of multiple graphics/compute queues.
- AMD started long time ago to advertise the use of queues / "asynchronous shaders" starting with Mantle and the current gen consoles. There are also some developers (example) that confirm significant performance gains by executing compute and graphics tasks in parallel.
- There has been recently some fuss about Nvidia not supporting asynchronous shader in the hardware: Using separate Graphics and Compute queue at once seems to make things slower which indicates driver emulation. Parallel copy operations, on the other hand, have been supported by CUDA for a very long time, which makes it clear that the DMA engine can work independently.
Is there any way to decide at runtime if it is meaningful to commit CommandLists to multiple CommandQueues instead of a single one? (given that former case does not involve much engineering-overhead)
While I can easily see how it is useful to perform memory operations parallel to compute/graphics operations, it strikes me as unnecessarily complicated to run multiple compute and graphics processes in parallel (unless there is no major perf. benefit). It is also not clear to me, how this can lead to significantly better performance anyways; except for pathological cases where many small sequential tasks are not able to generate enough GPU load.