Intel Ivy Bridge On Linux Two-Month Redux

It has been 66 days since Intel formally introduced their Ivy Bridge processors as the 2012 successor to Sandy Bridge. My views on Intel Ivy Bridge (specifically the Core i7 3770K model) back on launch-day were very positive in terms of the Linux compatibility, CPU performance, and the HD 4000 graphics capabilities. Since then I've conducted dozens of additional tests looking at the Core i7 Ivy Bridge on Linux in different areas from comparative benchmarks to Microsoft Windows, trying to run BSD operating systems on the latest hardware, looking at the virtualization performance, compiler tuning, etc. Here is a recap of this additional Ivy Bridge testing that has happened over the past two months of near constant benchmarking.

Within my launch-day Intel Core i7 3770K review I concluded:

"This is only one of many Intel Ivy Bridge Linux articles to be published on Phoronix, but from these results plus other numbers that are set to be published soon, the Ivy Bridge performance is terrific. The raw performance of the Intel Core i7 3770K is terrific as is the power-per-Watt compared to other Intel and AMD hardware, with this high-end Ivy Bridge winning in a far majority of the conducted benchmarks. While the Ivy Bridge HD 4000 graphics results under Linux are in another article, those numbers too are also fantastic for being an open-source driver and illustrate a huge improvement over Sandy Bridge.

As far as the Linux support goes for Ivy Bridge at launch, it is in terrific shape. I'm very happy with the level of support and anyone picking up one of the new Ivy Bridge processors (and even a new Intel 7-Series Panther Pont motherboard) shouldn't really have any Linux snafus to worry about for this Intel 2012 platform launch if using a modern Linux distribution. While any modern release will do, you generally want the latest compiler, kernel, and graphics packages for the best performance. Ubuntu 12.04 LTS has been tested the most and it has shaped up extremely well for this new Intel hardware."

Two months later, I continue to be extremely pleased with Ivy Bridge and the improvements over Sandy Bridge are evident. The Linux support for Ivy Bridge continues to be enhanced from graphics driver advancements to more mature compiler support. While the improvements continue to come, Ivy Bridge is not perfect and the Linux support is not without a few blemishes. Below is a recap of some of the articles published on Phoronix over the past two months as it pertains to Intel's latest-generation processors.

First, here are the less than stellar findings about Ivy Bridge on Linux:

- The Intel Windows OpenGL driver is generally much faster than the Linux driver. There is also talk of a revamped Windows OpenGL driver coming later in the year that may increase the margin to which Linux is behind.

- The Intel Windows OpenGL driver has moved onto supporting OpenGL 4.0 while the Intel Linux driver only complies with the OpenGL 3.0 specification. OpenGL 3.1 is not even expected within Intel's Mesa driver until 2013.

- Ivy Bridge supports OpenCL on its graphics core, but under Linux there is currently no open-source OpenCL implementation for Intel's IVB graphics hardware.

- For OpenCL running on the CPU, Intel has its closed-source OpenCL SDK that is supported under Linux. To some surprise, AMD's OpenCL APP SDK on the CPU is faster than Intel's OpenCL SDK with their own hardware.

- Outside of Linux, the Ivy Bridge support on BSD operating systems appears to be in bad shape. Solaris has yet to be tested on the Ivy Bridge hardware.

These are the main issues with Ivy Bridge on Linux, it comes down to the Intel Linux driver lagging behind the Microsoft Windows driver in some areas -- namely OpenGL performance and compliance. The OpenCL support is also behind. There are also some of the less widely used Ivy Bridge features not supported under Linux like wireless displays, etc. There's also several shortcomings of Intel's Linux driver that aren't Ivy Bridge specific, like no S3TC texture compression support by default and that it wasn't even until May that MSAA anti-aliasing support was supported in their mainline code-base.