If more compute tasks are used than DX11 can handle, then it does. DX12 isn't magic. The door swings both ways. DX12 sees improvements on this front because it allows those compute tasks to get processed faster, so they don't have to sit and wait. If a DX12 game is written correctly, it will rely on that to happen. It'll no longer be a boost but the normal. This will lose performance with less capable async compute implementation.
A. There's no limit on the number of compute tasks DX11 can handle.
B. A game can't rely on a task being processed in some set time on PC.
You're talking about execution latency which will only be different if a GPU is able to execute some compute tasks in parallel in DX12 and can't in DX11. If it can't execute them in parallel in any API due to h/w limitations there won't be any difference in execution time between these APIs.
DX12 QB was written to run on Xbox One. If Remedy wanted to maximize their compute tasks and there were CPU bound tasks that could be moved, they could have moved tasks that were CPU bound on the DX11 version over to the GPU because DX12 allows for more tasks to be completed in a cycle since the GPU no long has to complete the cycle before more compute tasks can be added.
What cycle? You can't just move tasks from CPU to GPU, it doesn't work like this, if some task would be theoretically more efficiently executed on the GPU than on CPU this will be true for any API this task is being run through. Async compute changes the execution order between graphics and compute filling the gaps in the graphics pipeline, it doesn't make a GPU magically more suited for compute than under DX11. In fact, it doesn't affect GPU's compute capability at all.
If they did this, then poor compute scheduling could cause a bottleneck.
For the third time - no, it can't. There's no "poor compute scheduling" in DX12 with or without async compute running concurrently.
And again, since I seem to have to keep reminding you, I'm not saying that this is what's happening in QB. So please stop acting like I am.
I'm not talking about QB, I'm talking about your false claim that running DX12 renderer with async compute on a h/w which can't run async compute concurrently can make it run worse than the DX11 renderer performing same tasks would.
Since it's a future looking speculation we would think about all features you potentially could embrace with DX12 in comparison to DX11-
You probably know for yourself that with explicit resource managemant, ExecuteIndirect and bindless resources developers could enhance or implement new rendering methods, improving performance without Async Compute.
Going into the future with Shader-Model 6.0 there will be directly new operations for improving the GPU-Performance.
I've yet to see any example of a better resource management by DX12 renderer than what is there in DX11 so excuse me if I don't hold my breath over this providing any benefit, ever. It's also hardly something unlocking a hidden GPU potential.
ExecuteIndirect is mostly a CPU side API optimization, not sure what it has to do with GPU either.
Bindless models and SM6 are not exclusive to DX12 and are there in DX11.x too.
It's likely true for the RX480 too, since the raw power is also nearly 40% higher but there is of course a better DCC and more L2$.
In the end there are different bottlenecks, maybe the game is bottlenecked by a weak geometry-frontend, maybe it's more starved because of the bandwidth and the ALU:Bandwidth ratio is always important.
The gains from Async Compute are in Ashes of the Singularity not smaller or bigger for the RX480 in comparison to the 380(X):
https://www.computerbase.de/2016-06/radeon-rx-480-test/11/#diagramm-ashes-of-the-singularity-async-compute_2
I wouldn't use AotS as a good indication of async gains as it's a rather unorthodox renderer and it have (had?) some strange pipeline changes between async on and off.
Smaller gains from async on 480 can be seen in a number of games now, although all of them can be explained by something else of course. It's however a bit strange to try to debunk this as the simple fact of Polarises better graphics pipeline natively lead to less headroom for running compute alongside it - so in theory this must happen in some cases anyway, even if doesn't actually happening in QB.
