Open-Source NVIDIA Driver Approaches Stable State
This article has new benchmark results of Nouveau versus the official NVIDIA driver for a range of tests on GPUs going back to the GeForce 8 series. In general from the many graphics cards I go through, I'm still finding the best Nouveau driver support to be with the GeForce 9 series in terms of stability, performance relative to the official driver, feature-completeness, and reliability.
With NVIDIA providing no public documentation / register specifications nor any other form of open-source support, all of these driver features have been implemented by first clean-room reverse-engineering of the official NVIDIA Linux driver. NVIDIA's official stance on the Nouveau driver project is that they will not actively do anything to support or hinder this free software project. NVIDIA did have the 2D-only xf86-video-nv open-source driver that was UMS-only and rather useless, which the Nouveau driver killed when it went mainline in the Linux kernel. NVIDIA ended up abandoning work on this next-to-useless driver and just referred Linux users to running the VESA driver until they could install the NVIDIA binary blob.
In having been closely monitoring the Nouveau project for years and running the driver on a whole range of cards quite often in the latest driver state, this work has indeed come a long way. In recent years, it would even be like a game of Russian Roulette as to whether a graphics card would work on a given Linux kernel release or with the current Git state of the Mesa/Gallium3D drivers, but that has improved greatly with far less regressions being introduced. It was just last year that Canonical enabled the Nouveau Gallium3D (OpenGL acceleration) support by default in Ubuntu Linux.
One of the most interesting achievements out of the Nouveau driver camp came just last month. Besides announcing their plans to move out of the kernel's staging area, they managed something quite interesting: same-day Kepler support in their DRM/KMS driver. A few Nouveau developers managed to get their hands on the NVIDIA GeForce GTX 680 shortly in advance of the public debut and managed to reverse-engineer the support and get the basic display up and running in time for the 22nd of March launch. From a driver perspective the latest-generation Kepler architecture ended up not being too different from the GeForce 400/500 "Fermi" generation and so the Nouveau developers didn't have to write a new driver from scratch but just a surprisingly small number of changes to their existing code-base. I've tried the kernel mode-setting on the NVIDIA GeForce GTX 680 I'm testing for a few days and was surprised to see that Nouveau KMS is indeed working for this latest high-end NVIDIA graphics card.
One of the biggest problems with the Nouveau driver in terms of performance is its lack of re-clocking support by default. The Nouveau driver in its stock state is just leaving the clocks for the GPU core, video RAM, and shader at whatever frequency/voltage they were left at when the system was booted. This behavior is done since the re-clocking for some GPUs are still being reverse-engineered, this is the safest approach, and that if upping these clock speeds but the fan management support is not good the GPU could overheat.
For most hardware, the re-clocking can be done manually (there isn't yet any dynamic power management for switching between performance levels like is done with PowerMizer in the NVIDIA binary blob) by first booting the Linux kernel with a special parameter for the Nouveau kernel module so that it supports re-clocking and then writing values to a special sysfs interface. For full details about this with the Nouveau driver read: Nouveau Reclocking: Buggy, But Can Boost Performance. Re-clocking support has come together a lot in the past few months but it is still ongoing.
While Linux support is the focus of the Nouveau developers, there have been efforts to port this open-source driver to Solaris and *BSD operating systems too, but in no other operating system is Nouveau currently supported by default.