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

<p>I suspect the performance is highly dependent on <strong>how</strong> 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.</p>

<blockquote>
  <p>"...command queues can be executed concurrently by the device..."</p>
</blockquote>

<p>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 <strong>should</strong> also solve it using what they know. I mean for crying out loud, the fallback is something they have already implemented; synchrounous execution. </p>

<p>Hardware is enough voodoo as it is for us developers.</p>

CC BY-SA 3.0
2016-05-04T22:38:30.980Z
2016-05-04T22:38:30.980Z
Andreas
<p>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 <a href="https://msdn.microsoft.com/en-us/library/windows/desktop/dn899124%28v=vs.85%29.aspx">specification</a> 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).</p>

<p>Apparently, different vendors handle this very different:</p>

<ul>
<li>Intel states in a <a href="https://software.intel.com/sites/default/files/managed/4a/38/Efficient-Rendering-with-DirectX-12-on-Intel-Graphics.pdf">recent presentation</a> (slide 23) that currently their GPUs are not able to handle Graphics &amp; Compute in parallel and that the copy engine has a weak throughput. They advise against the use of multiple graphics/compute queues.</li>
<li>AMD started <a href="http://amd-dev.wpengine.netdna-cdn.com/wordpress/media/2012/10/Asynchronous-Shaders-White-Paper-FINAL.pdf">long time ago</a> to advertise the use of queues / "asynchronous shaders" starting with Mantle and the current gen consoles. There are also some developers (<a href="http://fumufumu.q-games.com/archives/TheTechnologyOfTomorrowsChildrenFinal.pdf">example</a>) that confirm significant performance gains by executing compute and graphics tasks in parallel.</li>
<li>There has been recently <a href="http://www.guru3d.com/news-story/nvidia-wanted-oxide-dev-dx12-benchmark-to-disable-certain-settings.html">some fuss</a> 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.</li>
</ul>

<p><strong>Is there any way to decide at runtime if it is meaningful to commit CommandLists to multiple CommandQueues instead of a single one?</strong> (given that former case does not involve much engineering-overhead)</p>

<p>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.</p>

CC BY-SA 3.0
2015-09-10T23:46:30.187Z
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.
MJP
CC BY-SA 3.0
2015-09-11T01:26:37.987Z
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.
v.oddou
CC BY-SA 3.0
2015-09-11T07:52:22.560Z
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.
Wumpf
CC BY-SA 3.0
2015-09-14T02:03:50.897Z
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.
v.oddou
<directx12><api>
How many Direct/Compute/Copy Queues are meaningful?
Wumpf
# How many Direct/Compute/Copy Queues are meaningful?

(Asked by: username_0 on 2015-09-10)

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](https://msdn.microsoft.com/en-us/library/windows/desktop/dn899124%28v=vs.85%29.aspx) 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](https://software.intel.com/sites/default/files/managed/4a/38/Efficient-Rendering-with-DirectX-12-on-Intel-Graphics.pdf) (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](http://amd-dev.wpengine.netdna-cdn.com/wordpress/media/2012/10/Asynchronous-Shaders-White-Paper-FINAL.pdf) to advertise the use of queues / "asynchronous shaders" starting with Mantle and the current gen consoles. There are also some developers ([example](http://fumufumu.q-games.com/archives/TheTechnologyOfTomorrowsChildrenFinal.pdf)) that confirm significant performance gains by executing compute and graphics tasks in parallel.
* There has been recently [some fuss](http://www.guru3d.com/news-story/nvidia-wanted-oxide-dev-dx12-benchmark-to-disable-certain-settings.html) 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.

**Tags:** directx12, api

> **Comments:**
> **username_1**: 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.  
> **username_2**: 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.  
> **username_0**: 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.  
> **username_2**: 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.  

---

## 1 answers

### Answer by username_3 on 2016-05-04. Score: 1

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.


---

