14
$\begingroup$

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.

Improve this question
$\endgroup$
4
  • 1
    $\begingroup$ I don't think that there's any meaningful way to make that kind of judgement call at the moment, aside from checking who makes the GPU. Ultimately there's more factors than just "can the hardware execute commands from multiple queues simultaneously", and D3D12 abstracts away those details. In fact D3D12 doesn't even distinguish between hardware that might execute queues concurrently and those that might do it sequentially, the docs just say that their abstraction allows for concurrent execution. $\endgroup$
    – MJP
    Commented Sep 10, 2015 at 23:46
  • 1
    $\begingroup$ good question ! i also feel it would be special to gain perf to exec compute and shading concurrently. maybe gains can happens thanks to the same facts that makes hyperthreading somehow faster. interleaving operations when some units are busy for the other queue. like shaders clogging the texture units, which are not used by the compute stage, which itself clogs the FPU or DPU. $\endgroup$
    – v.oddou
    Commented Sep 11, 2015 at 1:26
  • $\begingroup$ Hm too bad. Maybe then "aside from checking who makes the GPU, no" counts already as answer if there is not more to it. After reading all those AMD marketing stuff I'm glad to hear that I'm not alone with my confusion. $\endgroup$
    – Wumpf
    Commented Sep 11, 2015 at 7:52
  • 1
    $\begingroup$ You know just to lift a bit of weight into the importance (actually UNimportance) of this matter. The PS4 SDK has a bug that doesnt allow emitting to any other queue than queue 0. I think if it was so crucial it would have been fixed faster. $\endgroup$
    – v.oddou
    Commented Sep 14, 2015 at 2:03

1 Answer 1

Reset to default
1
$\begingroup$

Ship your application with a benchmarking sequence testing the actual platform. (Possible answer for many questions I guess...)

I suspect the performance is highly dependent on how you use the hardware. Since the hardware is unlikely to somehow instrument your application backwards, telling you what to do, I´d go with whatever looks good in your design.

"...command queues can be executed concurrently by the device..."

Keyword is CAN. I see no reason why any vendor would screw this up. In the end it is the platform provider (Intel/AMD/Nvidia) who is responsible of making you a good enough driver for you not to consider switching vendor. If they do have a "know issue" with this functionality (which by the way has no functional meaning, only performance) then they should also solve it using what they know. I mean for crying out loud, the fallback is something they have already implemented; synchrounous execution.

Hardware is enough voodoo as it is for us developers.

Improve this answer
$\endgroup$
1
  • $\begingroup$ AMD's GCN will execute graphics and compute concurrently even when both are issued on the graphics queue, but generally not across multiple command buffers (multiple draw calls might even be sketchy). The driver (or application - I think in DX12 or Vulkan) must check for data dependencies and block between draw (graphics) and dispatch (compute) if needed. Multiple command queues would probably be useful if you have compute that is truly asynchronous from graphics (like physics for the next frame), but I have no direct experience with this. $\endgroup$
    – user2500
    Commented May 5, 2016 at 0:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.