Shouldn't the drivers be always as optimized and bugles as possible for a given moment. I mean doesn't releasing this new version of drivers, for almost every popular title, indicates that code wise and optimization-wise drivers are in some kind of mess ?
No, this is just a fundamental trade-off for abstracted hardware because your generic compatibility driver is always going to be the most verbose and inefficient to help ensure compatibility among multiple ASICs and architectures. In a worst case scenario, the compatibility driver has rendering errors that show up as anomalies or artifacts.
However, drivers can be tuned for specific code so if one piece of hardware can come to the same result in fewer instructions compared to another piece of hardware, those types of deviations need to be profiled and included as driver optimizations.
We're actually going to be seeing a lot more of this with DX12, as drivers can be even more explicit and expose the capabilities of different target hardware, which puts even more burden on the IHVs to support their hardware in a timely manner.
Exactly, that's what makes something like GeForce Experience even more important (compared to Windows Update that lags and will be similar to compatibility driver), as you can get drivers specific to your GPU in a more timely manner.
No, the point is you'd get Betas and even specific arch updates through GE while Windows Update might stick to the generic WHQL compatibility driver. There's even been times WU doesn't have the latest WHQL for whatever reason.
The "unified drivers" already contain seperate optimizations and code paths for different chip architectures. They're only unified from the end user perspective and do all the house-keeping internally - and it would be dumb to deviate from this.
Yes that is the case now, but the point is that might become an untenable situation in the future as DX12 will put even more emphasis on IHVs to be more explicit with their drivers for target hardware, meaning you could have even more driver-level extensions to expose capabilities in DX12. Nvidia (and AMD drivers) are already in the 300MB range, if you keep growing that you can see it might make more sense to split them up at some point for specific ASICs or uArchs. We'll see.
A better solution than seperate downloads would be a unified setup which downloads only the needed routines. This would suffice for most and there could still be the complete package for those who want it.
I think they already kind of have that, GeForce Experience already does most of this, inventorying and checking for new game profiles and drivers based on your hardware and allowing you to choose to install updates, or not.
I don't pretend to know the details of current video driver design, but obviously the only thing that matters here (in terms of size) is how much RAM the driver consumes at run-time. The size of the download isn't that important. The costs of nVidia tracking and maintaining a bunch of different versions for various architectures would be much worse for both nVidia and the end user.
I find it very hard to believe nVidia isn't utilizing the smart code-loading techniques that have available for a long time now. In other words, they're not wasting RAM. Your ~disastrous proposal is what video driver designers intelligently got away from years ago!
No one said anything about RAM, not a single time lol. I am talking about new lines of driver code that increase the size of drivers 2-3 fold for each arch supported, from the current 300MB you are looking at possibly 1GB worth of drivers. Bandwidth from someone like Akamai isn't exactly cheap, basically you are digitally distributing what used to be an entire game a decade ago millions of times a month, sometimes more.
This makes sense as long as they can find an easy way to implement it. Different products/architectures should have different driver streams. Even better would be to have the shared part be a different piece than the device-specific part so that each can be updated individually. I honestly have no clue how drivers work; I'm just thinking about this from a programming perspective.
Huh? Unlike the previous "GeForce Game Ready Driver for Grand Theft Auto V" these are not specifically released for one game but called the usual "GeForce Game Ready Driver". That kind of makes me hope that it is not as much of a half-assed version like the GTA one...
Is this the driver that makes sure my 780's run Witcher 3 like dogshit so Nvidia can keep pretending like Maxwell was some huge improvement in efficiency?
So I guess all the reviews that show Nvidia managed to extract 1.6x more perf and 2x perf/w on Maxwell with nearly the same transistor count, die sizes and wattage compared to Kepler were all a lie huh?
When those comparisons are made against their own GPU's, I find it decidedly convenient for their perf/watt statistics that games started suddenly running like dogshit on Kepler around the time Maxwell launched.
You never considered for a moment that the actual games are evolving and taking of some of Kepler's weaknesses and Maxwell's strengths? Next-gen games from next-gen consoles and all that good stuff? I mean as sad as it is that old archs aren't running new games as well as older games, that's kind of par for the course I guess and why we eventually upgrade is it not?
Why don't pure graphics benchmarks show this? Why is AMD's 4 year old architecture not showing this? Maxwell was not a significant architectural change, and there is certainly nothing about games that have been released in the last year that are a huge departure from previous games that Kepler demolishes (Frostbite 3 anyone?). The only thing that has changed is that Gameworks was introduced last year.
AMD's GCN has actually always been better at compute than Kepler, you can go back to the Dirt games with Global Illumination to see Nvidia falling behind, but not without cost, as AMD has always been weaker at Tesselation and that shows too. Kepler was also saddled with a lot of unused compute, and ofc as we know, Maxwell necessarily stripped this and focused completely on gaming.
As for not being major differences, you may want to check again and read up on the Maxwell Part 2 review (980 review). Not only does Maxwell have 2x the ROP to mem controller ratio as Kepler, it also has fewer shared resources for each SM, meaning you can get more granularity from each SM when running parallel but less similar code like compute. They said in some cases they were seeing 90% increase in utilization per SM....kinda makes sense in this context doesn't it?
Again, you acknowledge the fact Nvidia kind of formalized all of these next-gen features and libraries into GameWorks, but then reject the idea that their next-gen architecture was designed to run that type of code better, while also rejecting all of the benchmarks that show Maxwell is 1.6x or faster than Kepler at least, and possibly more in workloads that favor Maxwell arch.
We’ve updated our terms. By continuing to use the site and/or by logging into your account, you agree to the Site’s updated Terms of Use and Privacy Policy.
Facebook
Twitter
RSS
28 Comments
Back to Article
imaheadcase - Monday, May 18, 2015 - link
Mm contains a new PhysX driver as well, that is a first time in a long time for a update to that.fthf - Monday, May 18, 2015 - link
Shouldn't the drivers be always as optimized and bugles as possible for a given moment. I mean doesn't releasing this new version of drivers, for almost every popular title, indicates that code wise and optimization-wise drivers are in some kind of mess ?chizow - Monday, May 18, 2015 - link
No, this is just a fundamental trade-off for abstracted hardware because your generic compatibility driver is always going to be the most verbose and inefficient to help ensure compatibility among multiple ASICs and architectures. In a worst case scenario, the compatibility driver has rendering errors that show up as anomalies or artifacts.However, drivers can be tuned for specific code so if one piece of hardware can come to the same result in fewer instructions compared to another piece of hardware, those types of deviations need to be profiled and included as driver optimizations.
We're actually going to be seeing a lot more of this with DX12, as drivers can be even more explicit and expose the capabilities of different target hardware, which puts even more burden on the IHVs to support their hardware in a timely manner.
close - Monday, May 18, 2015 - link
They'll probably split the driver into more branches dedicated to certain series of GPUs instead of a single driver that covers the last 3 series.chizow - Monday, May 18, 2015 - link
Exactly, that's what makes something like GeForce Experience even more important (compared to Windows Update that lags and will be similar to compatibility driver), as you can get drivers specific to your GPU in a more timely manner.MrSpadge - Monday, May 18, 2015 - link
Windows update gives you the same WHQL drivers as nVidias, just a bit later. They're not any more or less compatible, just maybe tested better.chizow - Monday, May 18, 2015 - link
No, the point is you'd get Betas and even specific arch updates through GE while Windows Update might stick to the generic WHQL compatibility driver. There's even been times WU doesn't have the latest WHQL for whatever reason.MrSpadge - Monday, May 18, 2015 - link
The "unified drivers" already contain seperate optimizations and code paths for different chip architectures. They're only unified from the end user perspective and do all the house-keeping internally - and it would be dumb to deviate from this.chizow - Monday, May 18, 2015 - link
Yes that is the case now, but the point is that might become an untenable situation in the future as DX12 will put even more emphasis on IHVs to be more explicit with their drivers for target hardware, meaning you could have even more driver-level extensions to expose capabilities in DX12. Nvidia (and AMD drivers) are already in the 300MB range, if you keep growing that you can see it might make more sense to split them up at some point for specific ASICs or uArchs. We'll see.coburn_c - Monday, May 18, 2015 - link
The words make it sound like you understand what you're talking about, but you pretty clearly haven't a clue. Please shut up.chizow - Monday, May 18, 2015 - link
Feel free to take your own advice.MrSpadge - Monday, May 18, 2015 - link
A better solution than seperate downloads would be a unified setup which downloads only the needed routines. This would suffice for most and there could still be the complete package for those who want it.chizow - Monday, May 18, 2015 - link
I think they already kind of have that, GeForce Experience already does most of this, inventorying and checking for new game profiles and drivers based on your hardware and allowing you to choose to install updates, or not.DCide - Monday, May 18, 2015 - link
I don't pretend to know the details of current video driver design, but obviously the only thing that matters here (in terms of size) is how much RAM the driver consumes at run-time. The size of the download isn't that important. The costs of nVidia tracking and maintaining a bunch of different versions for various architectures would be much worse for both nVidia and the end user.I find it very hard to believe nVidia isn't utilizing the smart code-loading techniques that have available for a long time now. In other words, they're not wasting RAM. Your ~disastrous proposal is what video driver designers intelligently got away from years ago!
chizow - Monday, May 18, 2015 - link
No one said anything about RAM, not a single time lol. I am talking about new lines of driver code that increase the size of drivers 2-3 fold for each arch supported, from the current 300MB you are looking at possibly 1GB worth of drivers. Bandwidth from someone like Akamai isn't exactly cheap, basically you are digitally distributing what used to be an entire game a decade ago millions of times a month, sometimes more.Kegmeister - Tuesday, May 19, 2015 - link
This makes sense as long as they can find an easy way to implement it. Different products/architectures should have different driver streams. Even better would be to have the shared part be a different piece than the device-specific part so that each can be updated individually. I honestly have no clue how drivers work; I'm just thinking about this from a programming perspective.Daniel Egger - Monday, May 18, 2015 - link
Huh? Unlike the previous "GeForce Game Ready Driver for Grand Theft Auto V" these are not specifically released for one game but called the usual "GeForce Game Ready Driver". That kind of makes me hope that it is not as much of a half-assed version like the GTA one...hawtdawg - Monday, May 18, 2015 - link
Is this the driver that makes sure my 780's run Witcher 3 like dogshit so Nvidia can keep pretending like Maxwell was some huge improvement in efficiency?MrSpadge - Monday, May 18, 2015 - link
No.hawtdawg - Monday, May 18, 2015 - link
So I guess Kepler was just such a shitty architecture that a 780 is suddenly about on part with a 7970 with recent games.chizow - Monday, May 18, 2015 - link
Kepler was good for what it was expected to run for its time.chizow - Monday, May 18, 2015 - link
So I guess all the reviews that show Nvidia managed to extract 1.6x more perf and 2x perf/w on Maxwell with nearly the same transistor count, die sizes and wattage compared to Kepler were all a lie huh?hawtdawg - Monday, May 18, 2015 - link
When those comparisons are made against their own GPU's, I find it decidedly convenient for their perf/watt statistics that games started suddenly running like dogshit on Kepler around the time Maxwell launched.chizow - Monday, May 18, 2015 - link
You never considered for a moment that the actual games are evolving and taking of some of Kepler's weaknesses and Maxwell's strengths? Next-gen games from next-gen consoles and all that good stuff? I mean as sad as it is that old archs aren't running new games as well as older games, that's kind of par for the course I guess and why we eventually upgrade is it not?hawtdawg - Monday, May 18, 2015 - link
Why don't pure graphics benchmarks show this? Why is AMD's 4 year old architecture not showing this? Maxwell was not a significant architectural change, and there is certainly nothing about games that have been released in the last year that are a huge departure from previous games that Kepler demolishes (Frostbite 3 anyone?). The only thing that has changed is that Gameworks was introduced last year.chizow - Monday, May 18, 2015 - link
AMD's GCN has actually always been better at compute than Kepler, you can go back to the Dirt games with Global Illumination to see Nvidia falling behind, but not without cost, as AMD has always been weaker at Tesselation and that shows too. Kepler was also saddled with a lot of unused compute, and ofc as we know, Maxwell necessarily stripped this and focused completely on gaming.As for not being major differences, you may want to check again and read up on the Maxwell Part 2 review (980 review). Not only does Maxwell have 2x the ROP to mem controller ratio as Kepler, it also has fewer shared resources for each SM, meaning you can get more granularity from each SM when running parallel but less similar code like compute. They said in some cases they were seeing 90% increase in utilization per SM....kinda makes sense in this context doesn't it?
http://www.anandtech.com/show/8526/nvidia-geforce-...
And now look at the Compute synthetics....kinda mirror GameWorks games performance doesn't it?
http://www.anandtech.com/show/8526/nvidia-geforce-...
Again, you acknowledge the fact Nvidia kind of formalized all of these next-gen features and libraries into GameWorks, but then reject the idea that their next-gen architecture was designed to run that type of code better, while also rejecting all of the benchmarks that show Maxwell is 1.6x or faster than Kepler at least, and possibly more in workloads that favor Maxwell arch.
chizow - Monday, May 18, 2015 - link
Edit: 1st para should read: Kepler was also saddled with a lot of unused *DP* computedarkfalz - Monday, May 18, 2015 - link
I hope this fixed the bug where G-sync was on even during desktop.