I'm not sure what Nvidia said but what Oxide says is true regarding there being no bug in the application. It is clear from the benchmarks (without MSAA) that this is not the reason why Nvidia scores so badly in DX12.
Because DX12 is slower than DX11 so it must be "async shaders" and not the "Multi-Threaded Performance" or "Explicit Frame Management" or "Updated Memory Management Design" or whatever?!So what else is it if not MSAA and not the async shaders? The obvious answer is it is the async shaders.
Not what I was saying.
Console games will have async in the amount of what the apu-gpu can handle, this will be way less than what even a middle class desktop gpu can handle.
Async shaders are a potential bottleneck on current gen Nvidia cards ONLY IF YOU DEVELOP TO PUSH THE BIGGEST OF DESKTOP CARDS,ashes is doing that (and after a year of optimizing until it comes out a lot will change) but a classic console port will not.
The fact that "async shaders" doesnt cost any performance on hardware which doesnt support it is still ignored by you...
Async shaders are a potential bottleneck on current gen Nvidia cards that devs will either have to remove to increase performance on Nvidia, or just leave it as it is and accept that Nvidia cards will perform less optimally. What do you think they'll do?
The fact that "async shaders" doesnt cost any performance on hardware which doesnt support it is still ignored by you...
If you understood the nature of asynchronous shaders, you would know that this is quite a ridiculous assertion..
I have to agree with sontin, there is no evidence for this at all.
If you understood the nature of asynchronous shaders, you would know that this is quite a ridiculous assertion..
I don't know anything about Maxwell's async compute implementation, but I know that GCN gets huge benefits from it.
Look at that graph from Carfax above, you can see even the 370 gains with DX12 and it only has 2 ACEs. There are no benchmarks showing lower fps on AMD in DX12. That probably means that Ashes is nowhere near pushing the maximum limit (8 ACEs) on later GCN cards.
It's a fact?
Yes it is. DX12 doesnt behave different to DX11. If the hardware doesnt support it the context switch is exactly the same. You dont get "negative performance" over DX11 because nothing changed. That's the reason why anyone is promoting it as a huge feature.
Page 32 - 34: http://on-demand.gputechconf.com/gtc/2015/presentation/S5561-Chas-Boyd.pdf
Yes it is. DX12 doesnt behave different to DX11. If the hardware doesnt support it the context switch is exactly the same. You dont get "negative performance" over DX11 because nothing changed. That's the reason why anyone is promoting it as a huge feature.
Page 32 - 34: http://on-demand.gputechconf.com/gtc/2015/presentation/S5561-Chas-Boyd.pdf
Well it certainly isn't "spare cycles".
DX12 performance for NV in Ashes.
1. No async shaders (no dynamic lights), draw call test = Big perf boost.
2. Heavy test with dynamic lights (which the devs CONFIRMED is via async compute) = Small perf drop. Across the Kepler & Maxwell series.
Ashes might be worst case but I don't think so. I think that when devs really start using async shaders ie pushing all 8 ACEs on a PS4 for example, then you'll start to see worst case for Nvidia.
Btw, does anyone have a video of Ashes running in DX11 mode? I wanna know if there's thousands of dynamic lights (all those units firing & explosions cast a light in DX12 via async compute), since I wonder how they actually do it (if its there) in DX11 at all.
@Carfax83
This is why I have asked if ANYONE has seen DX11 benching in action, I suspect the dynamic lights are DISABLED.
Because in DX12 mode, the CPU test (draw calls only), has no lights (some site found 80% gain for NV in this test). I've seen a screenshot of it in action already, confirmed no dynamic lights in that mode.
If we can see a screen of DX11 mode in action, we can confirm immediately. If its a pure draw call test like the DX12 CPU mode, then bang, there's the answer: NV is already excellent for draw calls in DX11, AMD is bad at high draw calls.
They didn't up to now?
They didn't have to worry about dx11 from the get go and they have low level access, if they didn't until now why should they in the future?
I believe the only reason why the ps4 has the level of performance that it has with such weak hardware is because they already use as much of it as they can,they already use all of these features and that's why the ports run so badly on PCs.
Yes,ps4 also has 6 x86 cores for running the game same as the fx-6xxx that doesn't mean that the ps4 has the same level of computing power as the fx-6.FYI, PS4 has 8 ACE (same as recent GCN SKUs), XBone has 2. So devs will have to tone down usage for the Xbone, PC will probably have sliders, no worries.
It's 20k calls per frame, you're right my math is off but so is yours
Already shown that it takes 1.2ms per frame spent on API calls on the 980, and 1ms on the 290, assuming 20k draws/frame.
Using that, the assumption is the game is running at 100fps. Lets say that is on the 290.
So the amount of time spent on the API calls is
980 : 100fps X 0.0012s/frame = 0.12s
290 : 100fps x 0.001s/frame = 0.1s
Those numbers are how much time doing draw calls they spent for all 100 frames, not for one frame. Another way of saying that is that during that second, the 980 will spend 20ms (0.020s) spread out across 100 frames more than the 290x is spending doing draw calls.
20ms (0.020s) is 1/50th of a second : 1000ms(x)=20ms solve for X= 0.02 or 2%
So in 1 second at 20k calls/frame and 100 frames/s , the 980 will spend 2% of its time (20ms) doing draw calls that the 290X is free to do other things during. The TOTAL time it will spend doing draw calls is 120ms vs the 290s 100ms.
So yes, that's more significant, but it still doesn't explain the huge performance drop-offs on this game. It would amount to ~2fps compared to a 100fps 290x (if all else is equal), pretty close to the 1.6fps you found.
In any case, my main point is that the ability of the GPU to handle parallel draw calls is not the hold-up here. The bottleneck is elsewhere.
Edit : This is where I messed up with the math in the earlier post -
That should read that the 980 is handicapped by spending an additional 20ms doing draw calls for 100 frames during that 1s, not .002 fps.
It didnt do anything performance wise for BF4 and Thief. Just adds more points to that AOTS is broken in its current state.
Do you accept that AMD's LiquidVR and Asynchronous shaders are better at removing latency than Nvidia's solution, which is unacceptable for VR as stated by established industry veterans?
BF4 on PC didn't use async shaders. Thief on Mantle shows big perf increases which may or may not be down to async shaders.
http://wccftech.com/mantle-api-directx-thief-benchmarks-direct3d-creamed/
http://www.legitreviews.com/wp-content/uploads/2014/03/Normal-645x305.jpg
You did not respond to my previous question yet,
I thought it was made clear I dont support your view.
"The standard VR pipeline from input in (when you move your head) to photons out (when you see the action occur in-game) is about 57 milliseconds (ms). However, for a good VR experience, this latency should be under 20ms. Presently, a large portion of this is the time it takes the GPU to render the scene and the time it takes to display it on the headset (about 26ms). To reduce this latency we've reduced the number of frames rendered in advance from four to one, removing up to 33ms of latency, and are nearing completion of Asynchronous Warp, a technology that significantly improves head tracking latency, ensuring the delay between your head moving and the result being rendered is unnoticeable.
Combined, and with the addition of further NVIDIA-developer tweaks, the VR pipeline is now only 25ms."