A Word on Drivers and Compatibility

As we mentioned earlier, Ubuntu and the Linux kernel are open source projects, particularly under the GPL license. In large part due to the philosophies of the GPL, compared to Mac OS X and Windows, Linux handles drivers in a notably different fashion.

In a nutshell, the developers of the Linux kernel believe in the open source movement and wish for all related software to be open source. Furthermore they do not like the implications of attaching a closed source “binary blob” driver to the Linux kernel, because if something goes wrong it can be impossible to debug the issue if it occurs in the driver for which they do not have the code for. As such they have moral and technical objections to the Linux kernel supporting external drivers and actively prevent the creation of such drivers. This is done through mechanisms such as not having a fixed API for external drivers, and by not artificially keeping themselves from making changes to the kernel that would break external drivers. Drivers that they do have the code for can usually just be recompiled against the new kernel and are unaffected as a result. The result is that “binary blob” drivers are systematically opposed.

For the most part, this works fine. Not all hardware is supported under Linux because not everyone is willing to share the specifications and data needed to make a driver, but more than enough device manufacturers are willing to share such data that Linux generally supports non-esoteric hardware quite well. There is one class of notable hold-outs here however, and that’s the GPU manufacturers, namely ATI and NVIDIA.

Compared to other drivers, GPU drivers are different for two reasons. First is the sheer complexity of the drivers - besides interfacing with the hardware, the drivers are responsible for memory management, compiling/optimizing shader code, and providing a great deal of feedback. This in essence makes GPU drivers their own little operating system – one that its developers aren’t necessarily willing to share. The second significant difference here is because of the above, GPU drivers are among the only drivers that have a compelling reason to be updated regularly; they need to be updated to better support newer games and fix bugs in the complex code that runs through them.

Complicating matters further is that some intellectual property in GPUs and drivers is not the property of the company who makes the GPU. AMD doesn’t own everything in their Universal Video Decoder, and just about everyone has some SGI IP in their drivers. In the interest of protecting that IP, it is difficult to release the code for those drivers containing other companies’ IP.

Because of all of this, manufacturer-supplied GPU drivers are not always open source. Intel and S3 do well in this respect (largely because they have few tricks to hide, I suspect), but hyper-competitive NVIDIA and AMD do not. AMD has been looking to rectify this, and back in 2007 we discussed their starting work on a new open source driver. Development has been progressing slowly, and for the R6xx and R7xx hardware, the open source driver is not yet complete. Meanwhile NVIDIA has shown no real interest in an open source driver for their current hardware.

So if you want to use a modern, high-performance video card with Linux, you have little choice but to also deal with a binary blob driver for that card, and this becomes problematic since as we mentioned Linux is designed to discourage such a thing. Both AMD and NVIDIA have found ways around this, but the cost is that installing a binary driver is neither easy, or bug free.

The fundamental method that both use for accomplishing this is through the use of a kernel shim. Both analyze the headers for the kernel to identify how the kernel is organized, then they compile a shim against that kernel. The shim resolves the issues with the lack of a stable API, and the other end of the shim provides the stable API that NVIDIA and ATI need.

Ubuntu in particular takes this one step further, and in the interest of promoting greater out of the box hardware compatibility, includes a version of the binary drivers with the distribution. This is unusual for a Linux distribution and has earned Ubuntu some flak since it’s not strictly adhering to some open source ideals, but it also means that we were not forced to play with driver installers to get Ubuntu fully working. Ubuntu had no issues with both our AMD 2900XT and NVIDIA 8800GTX cards, both of which were picked specifically because we wished to test Ubuntu on suitably old hardware which would exist in time for Ubuntu to include support for it. With that said, the drivers Ubuntu includes are understandably old (once again owing to the idea of a stable platform) which means we can’t avoid installing drivers if we want better performance and application compatibility.

And this is where “easy” comes to an end. We’ll first start with AMD’s installer, the easier of the two. They have a GUI installer that puts in a driver along with a Linux version of the Catalyst Control Center. It’s Spartan, but it gets the job done.

NVIDIA on the other hand does not have a GUI installer – their installer is a text mode installer that requires shutting down the X server (the GUI) in order to install. It’s difficult to understate just how hard this makes driver installation. Not only is doing all of this completely non-obvious, but it requires interfacing with the CLI in a way we were specifically trying to avoid. It’s something that becomes bearable with experience, but I can’t call it acceptable.

Driver upgrades are an issue on both sides, because the installers are not completely capable of finding and eliminating older versions of the binary drivers. In one instance, for the NVIDIA drivers we had to track down a rather sizable shell script that automatically deleted the old drivers before installing the new ones, as that was deemed the “right” way to install the drivers. We had less of an issue with ATI’s drivers, but to be fair the primary card I used for my time with Ubuntu was the 8800GTX. I can’t confidently say that there are not other issues that I may have not run in to.

The Ubuntu community does supply tools to help with GPU driver installations, Once such tool is EnvyNG, which reduces the driver installation process to selecting what driver you want to install and it does the rest. This is a far easier way to install drivers, in the right situation it’s even easier than it already is under Windows. But it suffers from needing to have the latest driver data hardcoded in to it, which means you can only use it to install drivers it knows about, and nothing newer. It’s not regularly updated (as of this writing the latest driver versions it has are NV 173.14.12 and ATI Catalyst 8.6) so it’s good for installing newer drivers, but not the newest drivers.

The other tool is access to Ubuntu’s Personal Package Archives, which are a collection of user-built binaries that can be installed through the Ubuntu package manager (more on this later). It’s harder to use than EnvyNG, but anyone can build a PPA, which makes updates more likely. As it’s user-generated however, this still means that there won’t always be the latest drivers available, which means we’re still back to using ATI and NVIDIA’s installers.

As it stands, installing new GPU drivers on Ubuntu is between an annoyance and unbearable, depending on how many hoops you need to jump through. It’s certainly not easy.

The other problem with GPU drivers is that they do not always stay working. Among the issues we encountered was ATI’s driver failing to work after installing an Ubuntu update, and an NVIDIA driver that kept rebooting the system during testing for reasons we never determined (once we wiped the system, all was well).

Our final issue with the state of GPU drivers on Ubuntu is their overall quality. With a bit of digging we can come up with issues on both sides of the isle, so it’s not as if either side is clean here. But with that said, we only ended up experiencing issues with ATI’s drivers. We encountered some oddities when moving windows that was eventually fixed in the Catalyst 9.3 drivers. It turns out that the problem was that ATI’s drivers lacked support for redirected OpenGL rendering; Linux guru Phoronix has a great article on what this is, including videos, that explains the importance of this change.

Ultimately we hate to sound like we’re beating a dead horse here, but we can’t ignore the GPU driver situation on Ubuntu (and really, Linux as a whole). The drivers have too many issues, and installing newer drivers to fix those issues is too hard. Things could be worse, Ubuntu could only distribute driver updates with OS updates ala Apple, but they could also be better. For the moment it’s the weakest point for Ubuntu when it comes to installing it on a high-end system.

What’s the Value of Technical Support, Anyhow? The Package Manager – A Love/Hate Relationship
Comments Locked

195 Comments

View All Comments

  • LittleMic - Wednesday, August 26, 2009 - link

    http://en.wikipedia.org/wiki/NTFS_symbolic_link">http://en.wikipedia.org/wiki/NTFS_symbolic_link
    Well, Windows 2000 had symbolic links for a long time :-p (only for directory until Vista though)
  • ekul - Wednesday, August 26, 2009 - link

    ntfs has symlinks but the windows shell can't create or manipulate them. Pretty pointless. MS can (and does) use them in vista/7 but you can't make your own
  • Eeqmcsq - Wednesday, August 26, 2009 - link

    "hint: symlinks are your best friend. My home dir is littered with links to places on the filesystem I visit a lot to avoid a lot of clicking/typing"

    I use Gnome's bookmarks for that. Those bookmarks even include SMB shares on my other computers.
  • ekul - Wednesday, August 26, 2009 - link

    gnome bookmarks are very handy I just find symlinks to be more flexible since they work regardless of gnome vs kde, gtk vs qt and gui vs cli. Even wine can take advantage of them
  • jigglywiggly - Wednesday, August 26, 2009 - link

    one more thing you should have covered is battery life on laptops. Linux in general is pretty awful at managing battery life. Just web browsing 4 hrs on Vista on my vostro 1310(not using 7) but with Ubuntu 2 1/2. It's a huge difference, but oh well.
  • Ryan Smith - Wednesday, August 26, 2009 - link

    Laptops are out of our domain, that would be Jarred. If this two-part series is successful, I'll see what I can do about talking him in to putting some Ubuntu (or any Linux for that matter) battery benchmarks in. But I'm told a complete workup takes a while.
  • strikeback03 - Wednesday, August 26, 2009 - link

    On my Thinkpad T43, battery life is essentially equal between XP and Ubuntu. Ubuntu may even be slightly better, though I have never bothered with a formal test to put real numbers on both. Have you looked at whether the processor is throttling down properly or not while in Ubuntu?
  • sprockkets - Wednesday, August 26, 2009 - link

    "Now we have yet to touch on hardware accelerated playback, which is something we’re going to hold off on until we take a look at Ubuntu 9.04. Linux does not have a common media framework like Windows and Mac OS X have DirectShow/DXVA and QuickTime respectively. Rather the desktop environment that Ubuntu is based off of (GNOME) includes a lesser framework called GStreamer, which is closer to a basic collection of codecs and an interface to them. As such hardware accelerated playback is not as easy to do under Ubuntu as it is under Windows and Mac OS X. We’ll take look at the APIs and the software for this in our look at Ubuntu 9.04."

    Well, not exactly. There is this: http://en.wikipedia.org/wiki/VaAPI">http://en.wikipedia.org/wiki/VaAPI, which is not exactly widespread yet. nVidia's VDPAU, which provides hardware acceleration for h.264 and if you have the latest version of PureVideo in your card, it does VC-1 as well. It can work with this or alone as well.

    Also, while it is wacky that bin or binaries are in one spot, and lib or libraries are in another, and anything you install is in a /usr/lib/local, it does keep all related files in one spot. Keeping all your libraries registered as packages also makes it easy to repair.

    Also, one click installs are possible on openSuSE as well, though it does involve a small gui process and adding a repository as well. But doesn't any program require this?

    Also, I believe your problem with SMB shares is something I run into as well, but only on GNOME. On KDE, browsing shares is quite normal. Since I never bother mounting the share, I can't directly access it without KDE caching the file locally.

    Isn't /home/$Your Name$ intuitive as to where your stuff would be? That is very nice, as I can keep my stuff separate from the OS, thus I can reformat the OS partition without having to touch my data. Imagine reinstalling Windows and finding all your apps working exactly as before with no work. Can OSX do that (not rhetorical)?

  • Ryan Smith - Wednesday, August 26, 2009 - link

    VDPAU is something we'll specifically be covering in the Part 2; in fact it's what I'm working on at this moment.
  • GeorgeH - Wednesday, August 26, 2009 - link

    I'm sure the comment section will quickly be swamped with quibbles, so I just wanted to say that I found this article to be very informative, accurate (WRT my own Ubuntu experiences), and thorough. Kudos - now it's time to ask for a raise. :)

Log in

Don't have an account? Sign up now