The Open-Source Linux Graphics Card Showdown
Earlier this week I provided Intel Core i7 3770K Linux benchmarks for the Ivy Bridge launch-day followed by initial Ivy Bridge Linux HD 4000 graphics benchmarks compared to the Intel HD 2000/3000 Sandy Bridge graphics under Linux and to AMD Fusion on Catalyst and Gallium3D. In this article are more benchmarks of the HD 4000 Ivy Bridge graphics under Linux with Intel's open-source driver, but in this article it is a much larger comparison. This is a full showdown of the Core i7 3770K graphics compared to several discrete NVIDIA GeForce and AMD Radeon graphics cards when they're using their respective open-source Gallium3D drivers. What graphics hardware is best if you want to use an open-source GPU driver? Find out now.
Besides looking at the raw performance of various Intel, NVIDIA, and AMD graphics processors on their respective open-source Linux graphics drivers, the power efficiency of each configuration was also monitored. The Phoronix Test Suite monitored the overall system AC power draw via a USB-based WattsUp power meter when the MONITOR=sys.power environment variable was set, the power efficiency for each result was also recorded via with the PERFORMANCE_PER_WATT=1 environment variable being set.
In making the results more interesting and optimal for open-source, the Radeon and Nouveau drivers were tested in their "optimized" state. Out-of-the-box the Intel Linux graphics driver is set to run properly with great performance thanks to the driver being able to take advantage of all features, unlike the Radeon and Nouveau drivers struggling with proper re-clocking for some hardware or experimental features like color tiling, etc. The Intel driver basically "just works" under Linux sans hitting any new bugs.
- The Radeon hardware was tested with the following non-stock options: disabling swap buffers wait from the xorg.conf (SwapbuffersWait), enabling 2D color tiling (ColorTiling and ColorTiling2D in xorg.conf), and enabling PCI Express 2.0 support (radeon.pcie_gen2=1 as a kernel command-line parameter). It is silly that these non-default options are still needed for the open-source driver that AMD officially supports, but that is how it stands right now.
- With the Nouveau driver the main performance-boosting item at this point is forcing the graphics card manually into its highest performance level / clock state. The Nouveau driver continues to leave the graphics core / memory / shader clocks at whatever the video BIOS to sets them at when initializing, unlike the NVIDIA binary driver that dynamically changes the performance levels based upon GPU load and other factors. Therefore, with most modern NVIDIA hardware having multiple performance levels, to get the GPU at the correct frequencies for 3D use you need to manually force them to the higher state. Meanwhile you need to hope that the NVIDIA driver properly supports re-clocking for your GPU and that once re-clocked you don't experience any rendering corruption or stability problems. Re-clocking involves loading the Nouveau DRM driver with a special command-line parameter and writing the desired performance level to a sysfs node. This information is covered in detail in Nouveau Reclocking: Buggy, But Can Boost Performance. I long for the day when the Nouveau driver properly supports re-clocking across all modern NVIDIA GPUs and can be enabled by default to be done automatically.
The Intel Linux graphics driver does not require any changes like this for Ivy Bridge on a modern kernel / Mesa / xf86-video-intel DDX.
On the software side, the i7-3770K "Ivy Bridge" system was running Ubuntu 12.04 LTS x86_64, but the graphics components were updated to their latest Git master state. The new components were pulled in mid-April and included the Linux 3.4 development kernel, xf86-video-intel (2.18.0-Git), xf86-video-ati (6.14.99-Git), xf86-video-nouveau (0.0.16-Git), libdrm, and Mesa 8.1-devel git-e44089b. The proprietary NVIDIA and AMD drivers are not being tested in this article but only the open-source Mesa/Gallium3D graphics drivers. Another -- and more extensive -- comparison will come at a later date.