Last week I got an interesting email the day after NVIDIA dropped their 182.06 GeForce drivers to coincide with the launch of FEAR 2. To sum up the relevant bits of the email, the question was “Why are NVIDIA’s drivers so big?”

Although the most immediate answer to that is not particularly interesting – they’re as big as they need to be because they must be – this made for a great excuse to do some exploratory dissection. The latest GeForce Windows Vista 64 drivers weigh in at 100MB, which is not necessarily huge given that broadband is (mostly) plenty and disk space is cheap, but none the less it’s a bit of an infamous mark to hit if only because it wasn’t that long ago that 100MB was the size of an entire operating system. Just to be clear we’re not knocking NVIDIA here (we’ll get to why everything is so big in a moment) but the size of their drivers does make for an interesting discussion. What’s in a 100MB driver?


NVIDIA 182.06

We’re not going to list every single file (there are 59 of them, most of which are small files we don’t care about) but we’ll hit the highlights. Right off the bat, we run in to the matter of redundancy. Anyone who has seen the structure of Vista 64 has seen that there are a number of seemingly redundant applications and libraries. The reason for this being that Vista 64 needs both 64bit and 32bit versions of most libraries so that it can run native 64bit applications and run 32bit applications through WoW64. This kind of redundancy sneaks in to video drivers too due to the way the OS is structured. All told the Vista 64 driver package is 18MB larger than the Vista 32 package due to the need for a separate 64bit OpenGL driver (nvoglv64), a separate 64bit Direct3D driver (nvd3dumx), and finally due to general binary bloat (64bit binaries are slightly larger due to the larger instructions).

Next on the list we have the NVIDIA control panel, which is spread amongst several files. We’ll call it 15MB, but it’s probably a bit larger than that. We’ll follow that up with the Vista kernel driver (nvlddmkm) at nearly 5MB, the 32bit OpenGL driver (nvoglv32) at 4.5MB, the display server (nvDispS) at 3.5MB, and the CUDA driver (nvcuda) is well down the list at 1.2MB. There are a few other files bigger than this, and many more smaller than this, but it quickly adds up.

The single biggest file however is PhysX_9.09.0203_SystemSoftware, which as the name implies is the PhysX installer. The PhysX software is for all intents and purposes its own beast; it’s a CUDA application that doubles as its own drivers and libraries. Of the 100MB for the entire GeForce driver package, 40MB of that is just for PhysX. As for why it’s so big, most of this is due to the structure of the PhysX drivers as inherited by NVIDIA upon their purchase of AGEIA last year. Every version of the PhysX middleware requires its own version of the PhysX core library (PhysXCore) along with some object code for the still-supported AGEIA PCI and PCIe PPUs. There are 25 versions of the middleware included in NVIDIA’s PhysX drivers at this moment, which is what leads to large size of the PhysX installer.

Finally, there is the matter of the compressed and installed size of NVIDIA’s drivers. So far we’ve been quoting the compressed size of everything since that’s how the driver is downloaded, but it’s worth mentioning the installed (uncompressed) size of the drivers too. This isn’t quite as easy to track and add up as with the compressed drivers, but we’d estimate the total size is in the ballpark of 250MB. This is roughly split evenly between the GPU drivers and the PhysX drivers. Also keep in mind that this doesn’t include NVIDIA’s optional System Tools software needed for GPU overclocking, GPU monitoring, etc. That’s another 82MB compressed.

We also took a quick look at some previous GeForce driver packages for Vista 64, to get an idea of how much the drivers have grown over the past couple of years. Drivers are like any other software: more computing power and more space eventually leads to everything getting a bit bigger, so there’s no real surprise here that they grew in size.


NVIDIA 163.75


NVIDIA GeForce Driver Installer Size (Vista 64)
Version
PhysX Installer
Total Size
163.75 N/A 43MB
175.19 N/A 50MB
178.13 50MB 103MB
180.48 35MB 91MB
182.06 40MB 100MB


The 163 drivers are from November of 2007, so this covers roughly a 1.25 year time span. The big leap in size with the 178 drivers is when NVIDIA started including the PhysX installer with the GeForce drivers, which actually made those drivers slightly bigger at 103MB (due in large part to a 50MB PhysX installer). Excluding the PhysX installer, there’s no specific pattern in growth - between 163 and 182 virtually every driver file got bigger. The control panel and OpenGL drivers are the biggest culprits here due to their large size in the first place. As for the PhysX installer, the aforementioned need for it to include several versions of the PhysX libraries makes it an outlier. NVIDIA did beat 15MB out of it for the 180 drivers (down to 35MB) only for it to jump up to 40MB for 182. While we only have a short window of time to judge from, so far it’s the single biggest reason that NVIDIA’s GeForce drivers are growing as much as they are, and it looks like that will be continuing in to the future.

Not to be left out, we also cracked open ATI’s latest Catalyst 9.2 drivers to take a look at their size. The 62MB driver package is a bit bigger on the driver side than the control panel side (40MB/22MB or so) and we’d estimate the total installed size is around 140MB, although it’s even harder to gauge than NVIDIA’s drivers. This makes them roughly as big as NVIDIA’s own GPU drivers and control panel; the difference between the two comes down to the PhysX software.

And for those of you curious about platform differences, the latest NVIDIA GeForce drivers for Linux x64 (180.29) are 20MB.


ATI Catalyst 9.2

POST A COMMENT

33 Comments

View All Comments

  • UNHchabo - Monday, March 2, 2009 - link

    Not just memory usage: using "maximum" compression would also mean FAR more CPU time used to decompress the file.

    Personally, whenever I compress files, I do fairly light compression, so that any easily-compressed file gets compressed, and it saves huge amounts of CPU time on the customer's end.
    Reply
  • lassikin - Monday, May 2, 2016 - link

    the cards supported have 512mb+ ram recommendation.. and swap exists. compiled-html help files are now in the current 300mbyte package 80megs.. the .net installer is in the package more than once, many,many of the files are in the installer more than once. the physx is 170megs, and it has maybe 20 megs from duplicate files too. the physx version incompatibility is a big mess.

    theres a 7-zip uncompressor in there, in the install package, as well sooo.. biggest bloat to remove would be to just move the help online or give language specific downloads. it would save nvidia terabytes in costs. their frigging auto-updater _knows_ the system language as well so why is it downloading a package that has help files that haven't even changed. they could save maybe a million dollars per month from simple optimization.
    Reply
  • Rigan - Thursday, February 26, 2009 - link

    First, 6% is not overly impressive.

    Second, the lzma algorithm is weighted towards higher compression ratios at the expense of compression time. What zip (the algorithm not the tool) can do in 1 or 2 seconds often takes lzma 20 or 30. It's the trade off. There are much better compressors than even lzma, but they can takes hours to do what zip does in minutes.
    Reply
  • The0ne - Thursday, February 26, 2009 - link

    Because 7zip is not as widely known as your Winzip programs. Heck, I'm still using WinRAR since it's conception. Yea, I can use 7zip but it isn't that important to me to save a few Kilo, Mega of size for the longer processing duration (often times). Reply
  • ZoZo - Thursday, February 26, 2009 - link

    It's not about the .7z files, it's about the compression algorithm.
    Installshield could implement that compression algorithm for their package installer.
    Besides, 7zip can produce auto-extracting exe files: no need for 7zip on the destination computer.
    Reply
  • The0ne - Friday, February 27, 2009 - link

    Not to extend this semi-pointless discussion but that same thing can be said of other compression programs. Why a company doesn't "choose" the best algorithm, parts, PCs, or what have you could be due to many things. If people aren't aware of the program that started the algorithm they are STILL not going to know nor care. My co-worker here, a very intelligent design engineer among other things, don't even know about RAR. So how can he easily choose or say he like to use the 7zip algorithm for his files? Basically, he can't without more research.

    Now you take Winzip and older compression programs out there and he's already aware of them and he'll use them because it's convenient and easy to get going with. That's all there is to my point. History has shown us various types of good compression algorithms in the past with had little use because they were just not popular. Look at the pirated software world, still using RAR compression for their releases.
    Reply
  • notposting - Thursday, February 26, 2009 - link

    I was just wondering the same thing a few days ago about my HP AIO drivers. Granted it has fax, scanner, memory card reader, and printer functionality, but it was getting installed off the Vista specific driver disc (also had 2000/XP, and Mac discs which I also used) and needed 600MB (!!!) on the hard drive (and that was the required driver package, not extra software)! Hell of an optimization effort there...of course the last motherboard I got uses a DVD for everything it has. Reply
  • Lonyo - Thursday, February 26, 2009 - link

    One of the nice things about ATI (for those with slower connections), is that they offer drivers in individual packages (driver only, CCC only etc), as well as through a full bundle. While it may not seem like anything special to most people, it is nice when on a slower connection, as it means you can save a little time on downloading an update. Reply
  • Griswold - Friday, February 27, 2009 - link

    Its also a trouble saver for me. Ever since I stopped using the CCC package, I've had far fewer problems and itches with their product. Recently I thought, what the hell, give it a try.

    And Yesterday my trusty 3870 died. Ok, I'm not blaming CCC directly for that. I dont even know what exactly went wrong. The thing wasnt overclocked. But the fan behaved weird with CCC installed so I dumped it again and then it died (only garbage on screen at boot). ;)

    But other than that, CCC while doing fine what it does, always gave me a minor headache. The system boots slower, the desktop isnt ready right after logon etc. Its just a tad bit too unoptimized or bloated - and I can live without that and the CCC functionality.

    So, I'm grateful for the separate packages, indeed.
    Reply
  • Mr Roboto - Thursday, February 26, 2009 - link

    Why include PhysX in their standard driver package? It has support for what, five games in the last 3 years? Also the PDSetup.exe for AutoCAD isn't needed either. Both of those drivers should be downloaded separately as far as I'm concerned.

    Also if you want to use a CUDA application you have to download a special driver package from Nvidia "usually beta drivers". My point being soon they will add a useless CUDA driver to that 100MB download too.

    I've really only owned Nvidia cards in my life but I'm really starting to hate Nvidia with a passion. Everything they do lately seems to rub me the wrong way. From their card and chipset renaming spree and deceptive marketing to UMAP and the whole "Nvidia invented the GPU" egomaniac type behavior.

    I hope someone knocks them down a couple of notches, or better yet the GPU really does move to the CPU so they will go the way of 3DFX. I know that's not good for competition and for us consumers but that's the way they've got me feeling lately.
    Reply

Log in

Don't have an account? Sign up now