I don't consider myself knowledgeable enough to understand the implications of what we see in GPUView screenshots(or most people on this board and especially not on overclock.net). I do know that it's technically a D3D tool, and results from a Vulkan application might not even be accurate in the first place.
What is your CPU and speed? Your OpenGL results have much higher CPU times than Vulkan. Both are CPU limited in your screenshot.
MajinCry
Platinum Member
- Jul 28, 2015
- 2,488
- 560
- 136
Guess the diehards are going to cling to NVidia having better drivers, even when they have demonstrably worse 'uns. Meh.
And nae, the driver can use shader intrinsics in lieu of the shipped shaders themselves. Emphasis on most GPU-based driver optimizations being developer-made replacements of game shaders, and that shader intrinsics are, well, developer-specific shader functions.
Wee gander: https://developer.nvidia.com/reading-between-threads-shader-intrinsics
Nothing stopping NVidia from replacing the shader code, seeing as how they're dealing with actual high-level code, and not undocumented bytecode a la AMD and Gameworks.
And nae, the driver can use shader intrinsics in lieu of the shipped shaders themselves. Emphasis on most GPU-based driver optimizations being developer-made replacements of game shaders, and that shader intrinsics are, well, developer-specific shader functions.
Wee gander: https://developer.nvidia.com/reading-between-threads-shader-intrinsics
Nothing stopping NVidia from replacing the shader code, seeing as how they're dealing with actual high-level code, and not undocumented bytecode a la AMD and Gameworks.
That's the area that I benchmarked as well and got around a 150% increase. You'll see a much bigger difference between OpenGL and Vulkan if you point the camera towards the tower. The tower is a massive structure, so it requires lots of draw calls.
With OpenGL I was getting around 48-53 at 1440p max quality, and with Vulkan I was getting around 123-127 or thereabouts.
I don't know if the OpenGL renderer is just inherently weak or poorly optimized, because the frame rate drop in that area seemed to be caused by my CPU down clocking due to being too idle. It was down clocking to desktop speeds, which means 1.2ghz and very low voltage.
Before Vulkan was available, I would get around this issue by making my CPU run at 4.4ghz constantly by selecting the performance option in Windows..
Last edited:
The truth is that neither one of us have anywhere near the depth of knowledge to provide an accurate answer as to whether AMD's or NVidia's asynchronous compute solution is better. This would require advanced knowledge of GPU architectures, as well as access to patented and confidential information.
Yes, AMD's implementation results in a larger performance increase, but how much die space and wattage did they sacrifice for these hardware ACEs compared to NVidia's implementation? You have to attempt to look at this from the perspective of an engineer ie tradeoffs, if you want to be unbiased.
I haven't concluded anything, as ID haven't even released the update to enable AC on Pascal yet. I actually have faith in ID as they have a history of top notch software engineering.
But since Time Spy does give about a 7.5% boost on a GTX 1080 with AC enabled, then I would at least expect something similar with Vulkan.
Right, as if anyone in that thread can even read that graph...
People just want to believe what they want to believe. AMD fans were so against the notion that Pascal actually had concurrent asynchronous compute capability, that they came up with all sorts of conjecture that NVidia must be lying again.. And then Time Spy was released, and all of a sudden we had a method of gauging the performance of asynchronous compute enabled or disabled for Pascal, with Pascal evidently getting an increase with AC enabled as you would expect.
So now predictably, the benchmark itself is false because for some reason, only AMD is allowed to have concurrent asynchronous compute capability, let alone actually benefiting from it
1080 does appear to do work using async compute in doom: http://imgur.com/a/hbX8t
So there goes that theory.. guess async compute missing was driver related after all as well, along with the rest of the vulkan performance issues. Id had done the work and we were just waiting for Nvidia to release drivers...
Called it back in early august - https://forums.anandtech.com/threads/nvidias-performance-under-vulkan-api-explored.2482691/#post-38415169
Sounds like you guys all still owe id an apology for claiming they failed to support Nvidia cards, it was Nvidia themselves holding back their cards with lacking drivers.
^^ Nope!
Asynchronous compute is not enabled for Pascal in Doom. The developer already said as much on their website (I linked it a few pages back), that it was a work in progress which would eventually be implemented.
And none of the recent patches have mentioned AC for Pascal being turned on. So either you're reading the graph incorrectly, or the graph itself isn't showing accurate information..
Asynchronous compute is not enabled for Pascal in Doom. The developer already said as much on their website (I linked it a few pages back), that it was a work in progress which would eventually be implemented.
And none of the recent patches have mentioned AC for Pascal being turned on. So either you're reading the graph incorrectly, or the graph itself isn't showing accurate information..
In Doom async compute is vendor natural. It will run if the COMPUTE_BIT present in an independent queue.
But this won't help Pascal, because the post process overlap is a low latency implementation, and it will call the present from the COMPUTE_BIT. Pascal don't support this, so NV need a sync point first in the main queue with the GRAPHICS_BIT flag, and than they can do the present there. This will ad latency and minimize the performance gain. It doesn't really useful in the end, because you may gain 2-3% performance, but you get a lot ot additional latency with it.
But this won't help Pascal, because the post process overlap is a low latency implementation, and it will call the present from the COMPUTE_BIT. Pascal don't support this, so NV need a sync point first in the main queue with the GRAPHICS_BIT flag, and than they can do the present there. This will ad latency and minimize the performance gain. It doesn't really useful in the end, because you may gain 2-3% performance, but you get a lot ot additional latency with it.
If it wasn't enabled, the "Hardware Queue Compute_1" queue wouldn't exist at all.
The developer never said that it wasn't programmed for Pascal, just that it wasn't enabled yet.
That could simply mean they are helping Nvidia with their drivers. We've seen that their drivers were lacking and now the compute queue shows up and has work in it.
I've previously shown that async compute is completely vendor neutral with code snippets from DX12. I haven't done any vulkan work but I don't see why it would be vendor specific there.
Once again, it doesn't necessarily need a patch, just a driver that says it supports async compute, which is what appears to have happened.
Just now I realize how massive of a difference between FuryX and 980Ti as I got around 109fps at the same place with a stock FuryX at 1440p.
TRENDING THREADS
-
-
Discussion Intel current and future Lakes & Rapids thread- Started by TheF34RChannel
- Replies: 15K
-
Question 'Ampere'/Next-gen gaming uarch speculation thread
- Started by Ottonomous
- Replies: 5K
-
-
Question Intel i5 9400 vs. i9 9900K for internet browsing and watching video streaming- Started by Harry_Wild
- Replies: 17
Facebook
Twitter