When It Works, Intel Core i5 2500K Graphics On Linux Are Fast!

After a month of headaches for Intel and myself, there are now Sandy Bridge graphics benchmark results from the Intel Core i5 2500K under Linux to finally publish. Sandy Bridge was a tough launch for Intel in terms of the Linux coverage with the media having problems building a working driver stack and then when I finally got my hands on a CPU, I ran into an entirely different set of show-stopping problems. The developers still have not solved the biggest original issue yet, but Intel sent out a new motherboard and another CPU and it happens to "just work" nicely under Linux. When using the latest bits of their open-source Intel Linux graphics code, the performance on the Core i5 2500K is actually quite impressive compared to other open-source Linux drivers.

First, to recap the important milestones in the Sandy Bridge Linux saga to date, before sharing these much anticipated results:

- It was in February of 2010 that I reported Intel has started work on Linux graphics driver support for Sandy Bridge. Not only were they starting on the support 11 months in advance, but even the source code was available from the start and not keeping it in an internal repository until the kernel DRM, DDX, and Mesa support was ready.

- In October of this year was when Intel's Linux developers finally announced they planned to have the 3D driver support complete in the fourth quarter. In the time between February and October, Intel continued working on Sandy Bridge support in succeeding Linux kernel releases and Mesa. They also invested in Mesa optimizations. Later in October they had X-Video acceleration support and were preparing to release a new X.Org (DDX) driver that quarter to officially carry Sandy Bridge support.

- Due to the milestones hit, in December it looked like Sandy Bridge would play well with Linux when fetching all of the latest code. The driver code was obviously not found in modern non-rolling Linux distributions (such as Ubuntu 10.10) since it arrived post-release. However, it began in late December when I was hearing from other journalists that received Sandy Bridge hardware from Intel but were stuck due to no "out of the box" support and their inabilities to build the Linux graphics stack from Git source.

- When Sandy Bridge launched, Intel was slammed by some and called Sandy Bridge the "biggest disappointment of the year" for its lack of support without needing to build all of the code from source. Here's what I said on launch day about Sandy Bridge based upon what I knew at the time, as in general for any vendor there is a challenge to deliver open-source Linux GPU drivers, but was not provided with a CPU in advance from Intel. Intel's developers said they would work on better timing the support for Ivy Bridge, the successor to Sandy Bridge.

- Thanks to other journalists inabilities to build a working driver stack from source and to then complain about it, Intel gave me an Intel Core i5 2500K a few days later at the Consumer Electronics Show. It was assumed to just be an easy process for showing Sandy Bridge graphics work on Linux, since I build Linux drivers just about daily at Phoronix.

- After testing the Core i5 2500K on an ASUS P8H67-M PRO motherboard that I purchased, the Sandy Bridge Linux experience was abysmal. It was broken. I was able to put out Core i5 2500K CPU Linux benchmarks with P67 motherboards, which were terrific, but on the graphics side, it was unstable and very bad as was thoroughly detailed on Phoronix.

- At first, the problems were somewhat written off by Intel developers as they had not experienced any of the issues that plagued my system, but it was discovered they have largely just been testing on Intel SDVs (Software Development Vehicles). The problems were being blamed on bad system memory, BIOS settings, and any other related component. A few days after Jesse Barnes received an ASUS P8H67-M PRO motherboard, and not to my surprise, he was able to reproduce the big problem I had been reporting concerning the system locking up under load and the display becoming corrupted in a tiled manner.

- With Jesse being able to reproduce the problems, it was reassuring that it was not a problem in my software configuration or build process for the Intel driver. Jesse and I spent several days each trying different components, memory tests, BIOS settings, BIOS version, and kernel / driver build options, but those were to no success. Fast-forward to today, the problem still has not been solved, nor does it appear that Intel even knows the precise problem or where it is happening in the software. It may not be in the Intel DRM driver code, but elsewhere in the Linux kernel's support for Sandy Bridge. Even running the very latest code as of a few days ago for the kernel and related components does not change the situation.

- While all of this trial-and-error testing was happening, Intel decided to send out a new CPU and motherboard. It was still a Core i5 2500K CPU but the motherboard was a pre-production Intel BLKDH67BL.

Due to the Chicago snowstorms delaying the shipment several days, the new CPU/motherboard package finally arrived this week. After reconnecting the same RAM, SSD, and power supply to the Intel-branded H67 motherboard, I booted up into Ubuntu 10.10 with the same software driver configuration that I used to unsuccessfully test the ASUS P8H67-M PRO motherboard. With the different motherboard, everything worked just fine! There was no lock-ups, tiling corruption, or other Sandy Bridge Linux driver bugs. It all worked just fine and it was actually running quite fast for being the Intel Mesa driver.