It's not just about concurrent kernel execution. Kepler can already do that and probably all other DX12 capable hardware. Main advantage is running compute kernels in parallel with graphics rendering. As has already been mentioned for example doing some ROP heavy rendering and running a compute heavy compute shader at the same time.
Is that a possible source of slowdowns, that might be driver-correctable?
As far I know, talking about current NV hardware, only Maxwell 2.0 should take advantage of executing compute works and graphics works in concurrency.. All other hardware (Fermi, Kerpler, Maxwell 1.0) should not notice any sensible performance improvement (nor any sensible performance downgrade).
On all GCN compute and graphics share many hardware resources, so to take full advantage of asynchronous operations the engines should do complementary works in concurrency (ie: do graphics and computes on the same resources at the same time is not a great idea). Thanks to the great public documentation, I am not so sure about Maxwell 2.0 (but I guess it is something similar).
And this is why I've always felt it was an oversight not to allow queries for programs to see what kind of async functionality is available. In the long run all architectures will have oodles of async support, but right now not even Gen9 supports everything, and meanwhile Kepler + Maxwell 1 is going to be with us for a long time to come.
So multiple dispatches yes and graphics + compute is just as expected graphics + compute (not async).
What kind of workloads are you running on each thread? It is super easy to contruct workloads with zero potential gains.
What he claimed is that nVidia asked them to disabled it because their current implementation is very slow.
It was late and added to dx11 fast semantics in 2014. It does not require dx12 to be exposed I think. I could be wrong. But pretty fairly confident from reading the leaked SDK documentation
