DX12 Performance Discussion And Analysis Thread
- Thread starter A1xLLcqAgt0qc2RyMz0y
- Start date
The discrepancy seems too significant to not have been noticed in some other context. The PS4 at least uses asynchronous compute, and if this scaling behavior were universal I think it would have been remarked upon. The latest version actually cut the compute load per kernel, and I am pretty sure they can generate more dispatches in a frame than what is being done here.
I wonder what is being missed here.
Some of the patches for HSA include discussion of the generation of run lists that the schedulers use to pick kernels to lanch, does this need an intermediate layer of analysis for DX12 for the ACEs?
The AMD GPU with the simplest front end seems to have the least difficulty with the increasing kernel count, is this because it takes less work to add to queues if there's less of a problem space to analyze?
Are the vendors consistent in how they are assigning dispatches to queues?
Oddly enough, the forced-synchronous execution mode has a stair-step pattern for GCN that actually matches the known number of simultaneously presented queues for the 8-ACE GPUs. Although Tahiti also has the same stride, for some reason.
That case would seem to have the least amount of prior analysis needed, given less choice is given to the driver or GPU.
It does seem like the trend line for Nvidia really flattened in the one case where we know it was off.
I think this needs to be tested both ways for both vendors to see if there is a pattern to this.
Asynchronous compute versus forced-synchronous.
It's the same workload, and not one that is trying something too exotic.So far it's been discovered that different workload types perform differently on different GPU architectures
GPU usage on Fury-X is odd.
Compute : ~10% all the time
Graphics only: 40%
Graphics + compute: ~10% all the time
Graphics, compute single commandlist: 80-90% (usage seems stable in afterburner, does spike like in many pictures; highest recorded usage by afterburner 91%)
Dunno how to get them all to screenshot, so just gave summary.
Compute : ~10% all the time
Graphics only: 40%
Graphics + compute: ~10% all the time
Graphics, compute single commandlist: 80-90% (usage seems stable in afterburner, does spike like in many pictures; highest recorded usage by afterburner 91%)
Dunno how to get them all to screenshot, so just gave summary.
How many compute queues are being set up with the latest test version?
I recall that it was a large number initially, but is it now one graphics and one compute for the mixed case?
I recall that it was a large number initially, but is it now one graphics and one compute for the mixed case?
Jawed
Legend
"Usage" is hard to define, because it's likely to be a number that measures multiple parts of the GPU to determine load. It's also likely to be measuring multiple points across some parts, e.g. the load on each shader engine (there's 4).
For example the shader engines might literally be busy 1/4 of the time in the compute run and perhaps core usage only counts for 40% of the entire "usage" metric.
The first test and the latest test have different parameters - they are two different scheduler/simultaneous command benchmarks. It isn't the point that they are technically pushing the same type of work through, it's that they are different in behavior of handling said work.
RedditUserB
Newcomer
Btw, Mahigan is suggesting the program isn't even designed to handle GCN properly which is why you see strange results and thus, interpreting it is silly-fest:
http://www.overclock.net/t/1569897/...ingularity-dx12-benchmarks/1710#post_24368195
Any credibility to that?
http://www.overclock.net/t/1569897/...ingularity-dx12-benchmarks/1710#post_24368195
Any credibility to that?
I should note that you should enable TDR again when finished benchmarking as leaving it disabled greatly increases the chance of system instability. And yes, enabling/disabling it requires a restart. Pro tip, running an infinite loop on your display gpu with tdr disabled = bad idea.
MDolenc, did you use the disable timeout flag? I wonder if it completely disables it or just extends the timeout.
Jawed
Legend
Multiple threads issuing work to the GPU?
The command list run is favourable to AMD. But it isn't exactly pretty, either.
It may well do, but I don't see how this test is illuminating in that regard. The numbers we're seeing are orders of magnitude wrong.
For example I can complete 128 kernel launches of SGEMM using 32x32 square matrices in 4.5ms with some OpenCL code I have lying around, on Tahiti. 512 kernel launches take 16.7ms.
If there's 8 ACEs and all the work in this test is going to a single ACE, maybe there's a problem getting work from a single ACE to the entire GPU? It doesn't seem logical to me, though, to have an architecture with this limitation, since surely this is the most common case.
I doubt there's analysis going on here. I think it's more likely there's a choice of allocation heuristics in the hardware and the driver tries to choose what it thinks is best.
D
Deleted member 2197
Guest
Benchmarked: Ashes of the Singularity
Sept. 1, 2015
Sept. 1, 2015
http://tools69.com/benchmarked-ashes-of-the-singularity/
RedditUserB
Newcomer
Big developers have the capability to make their own engines, small developers use engines already made. Since most of them are moving to DX12 support, it's a matter of how optimized the engines are for either architectures and the effects they support, no?
Let's keep this about D3D 12 performance.
D
Deleted member 2197
Guest
Yes, the article says DX12 may require manual optimizations to get the highest GPU performance possible and is something only Big developers will have resources for. Smaller developers won't have the resouces to spend alot of time optimizing and may focus more on getting the product to market and will spend less time writing GPU optimizations ... maybe an engine like the Unreal might be ideal for a small developer, and there are a few others.
Last edited by a moderator:
https://www.reddit.com/r/pcgaming/comments/3j87qg/nvidias_maxwell_gpus_can_do_dx12_async_shading/
Err I think Hallock doesn't understand what this little program does well at least parts of it lol. He is miss representing the single command list to prove his points
This is almost like a soap opera! With tech
Err I think Hallock doesn't understand what this little program does well at least parts of it lol. He is miss representing the single command list to prove his points
This is almost like a soap opera! With tech
D
Deleted member 2197
Guest
And generalizing:
Similar threads
