Nvidia Has a Driver Overhead Problem, GeForce vs Radeon on Low-End CPUs
- Thread starter badsykes
- Start date
acroig
Just another Troll
That's not really the case.
The reason why NV has always had better DX9/11/OpenGL performance than AMD is because their drivers do a lot more behind the scenes to optimise their GPU performance.
So the draw call the app does ends up being sent to effectively a 'server' process which will be doing things like on-demand shader recompiling, caching, draw call rewriting and reordering (per game/engine), and correcting mistakes/issues that can happen.
AMD does a lot less of this aggressive optimisation which is why their performance on DX9/11/OpenGL has been traditionally lower, or doesn't increase like NVs would so often do.
This is also the reason why DX12/Vulkan saw AMD suddenly jump up performance wise, the driver basically got 'out of the way' and NV lost their 'server' advantage as those APIs are very much "do what I say" where as previous APIs are a bit more "do what I mean" - and NV has also been far more forgiving in that regard; my rule of thumb tends to be if it works on NV and not on AMD I've done something wrong, if it works on AMD and not on NV then NV have an optimisation which has done something wrong.
That's not to say that the drivers don't make a difference, however how much of a difference they can make and when they can do it is now heavily constrained.
Anyway, the point of all that is that this isn't "poorly optimised", it's just doing a lot of useful work which, yes, on lower performance CPUs might cause an issue.
The latest NV driver package is ~630MB. No bloat there.
Large size != high CPU usage.
I could write a tiny program which burnt CPU time for no reason at all if I felt the need.
The large package is likely due to all the various driver profiles, which is likely to include both code and custom shaders and other support things for games.
The thing that matters is the code which executes on the critical path while it is doing work.
Not really, because it's all setup work that is being carried out before the commands are written to the command queue that the front end consumes.
An example would be if a game was to issue say four draw calls; it might issue them in the order 1,2,3,4 but via profiling NV might know that for their hardware (and maybe even just a particular generation of GPU) doing 4,3,1,2 yields better results, so they have to cache everything for the first 3 draw calls before doing them in that order - that's something you'll do CPU side as it's more efficient to do it there vs trying to jam more logic and resources into the GPU.
Nagorak
Well-known member
I wonder if on an 8 core processor like a 2700X or 1800X if this would be less of an issue since you'd have the two more cores to spread the load out to? Maybe all the talk about games not utilizing more than 6 cores wouldn't really turn out to be true once you take into account driver overhead on a slower system? If so, the 2700X might turn out to have been a better buy than the 2600X.
I guess I should look and see if HU has already run the 8 core Ryzen tests, since that should answer my question.
I guess I should look and see if HU has already run the 8 core Ryzen tests, since that should answer my question.
No it is a mole out of a mountain hill.
I mean, it sure as **** ain't a new thing; back in 2011 I was working on a game/tech demo which was scaling across cores (and doing so well for the time) and we used one less thread than core count so we'd stay out of the way of NV's driver process.
I'm not sure what the current job system at the place I work is doing, but I wouldn't be surprised if we do the same thing too.
demo
space cadet
Pax, Nvidia have taken this approach for DX11 and earlier where there are significant gains, while in DX12 their software approach is a burden because the API handles it. In DX12 it 'gets in the way'.
They probably haven't changed the driver stack completely just for a handful of DX12 games, when DX12 drawcalls are already through the roof by virtue of API.
They probably haven't changed the driver stack completely just for a handful of DX12 games, when DX12 drawcalls are already through the roof by virtue of API.
Once DX9/DX11 are completely phased out, I could see NV re-working their driver package and removing the software scheduling and/or coming up with a new solution. As it stands right now, I prefer it the way it is.
I remember when DX12 first came out and everyone said "Why is NV performing worse?! Why is AMD seeing so much more performance compared to DX11?!" and no one stopped to think, that maybe NV's drivers were just that god damn good in DX9/DX10/DX11, and with DX12 taking that ability away, it evened the playing field.
I would have never guessed the software scheduler ate up that many CPU cycles, but either way, I'd still prefer it the way it is right now.
I remember when DX12 first came out and everyone said "Why is NV performing worse?! Why is AMD seeing so much more performance compared to DX11?!" and no one stopped to think, that maybe NV's drivers were just that god damn good in DX9/DX10/DX11, and with DX12 taking that ability away, it evened the playing field.
I would have never guessed the software scheduler ate up that many CPU cycles, but either way, I'd still prefer it the way it is right now.
demo
space cadet
Yes exactly. I wouldn't be surprised if they make some improvements in the near future though.
I'll post this again. As you can see in DX11 where it's critically needed, Nv show around 60-80% gains, while in DX12 where drawcalls are through the roof and not an issue, they're 20-30% behind.
Have to admit I'm surprised by Vulkan results. /shrug
Last edited:
I do notice that Vulkan routinely performs better than DX12 on my 3080. RDR2 benchmark is 3-4FPS higher, and even Path of Exile runs smoother for me when the screen gets really crazy.
That's a really good catch. I figured it was more engine dependent on the Vulkan > DX12 performance in those two games, but I wonder if it's actually just Vulkan performs better than DX12 for NV across the board.
That's a really good catch. I figured it was more engine dependent on the Vulkan > DX12 performance in those two games, but I wonder if it's actually just Vulkan performs better than DX12 for NV across the board.
It's an interesting thought, because I thought Vulkan handles drawcalls the same way DX12 does, in that it's agnostic and isn't influenced by drivers?
I would love a good "School of Bob" post
