When Intel launched their newest "Sandy Bridge" processors earlier this month there were no Linux benchmark results available. We were not seeded with any CPU in advance and the other publications that have flings with Linux were unable to get the Linux graphics support working. There is no "out of the box" Sandy Bridge support under Linux with Ubuntu 10.10 and other distributions released in the past few months. It was not until the time that Sandy Bridge launched that there was the releases of Linux 2.6.37, Mesa 7.10, and the xf86-video-intel 2.14 DDX that are the versions reported to play well with the new Intel graphics. Because of the lack of "out of the box" Linux support, there was a very scathing review at SemiAccurate.com that went as far as calling Sandy Bridge the biggest disappointment of the year. The code was said to be ready, but there is a challenge in installing open-source GPU drivers by many Linux users.
A day later, there was an acknowledgement by Intel's Jesse Barnes (one of the Intel OSTC Linux graphics developers) that they sort of messed up but will be aiming for better timing with Sandy Bridge's successor, Ivy Bridge. By the end of that week, the Linux 2.6.37 kernel was out there as well as a new version of libva for providing VA-API video playback acceleration, Mesa 7.10, and then the xf86-video-intel 2.14.0 X.Org driver. At the Consumer Electronics Show (CES) I was then given a Sandy Bridge processor (Core i5 2500K) by Intel's PR department so that Linux graphics benchmarks could be put out there due to the other publications failing to build the open-source Intel driver stack. It was figured that everyone would be happy after that because building the kernel, Mesa, and the rest of the stack from source is pretty much an every-day occurrence around here.
The week since CES I had been testing some of the P67 motherboards that were received from the different vendors. The CPU performance under Linux is really great and compelling, as the results will show when published. Then the next step was to move onto an Intel H67 motherboard to take advantage of the new integrated graphics. A clean Ubuntu 10.10 installation was performed with its Linux 2.6.35 kernel, Mesa 7.9, and xf86-video-intel 2.12 DDX. On this clean installation, the Intel DDX driver worked fine and there was kernel mode-setting, but there was no form of 3D hardware acceleration due to the outdated bits, as expected.
Thanks to the speed of the Sandy Bridge processor, within about 16 minutes of the first boot I had the latest xf86-video-intel, Mesa, and libdrm code built from Git and installed the vanilla Linux 2.6.37 kernel from the Ubuntu mainline PPA. After a reboot, however, I noticed that Compiz did not flip on. Attempting to manually enable the compositing from the GNOME Preferences for the desktop effects still resulted in, "Desktop effects could not be enabled." When launching Compiz from the command-line, it turns out the Sandy Bridge PCI ID is black-listed by Compiz. However, when skipping the black-listing checks, launching Compiz still failed miserably while the verbose libGL debugging information didn't report anything out of the ordinary and all indications were that hardware acceleration was working.
My next step was to verify this with one of the common OpenGL benchmarks. After a quick FORCE_TIMES_TO_RUN=1 phoronix-test-suite benchmark nexuiz had worked out with hardware acceleration, it appeared the situation was going easy again. With this Intel H67 + Intel Core i5 2500K system running Ubuntu 10.10 with the Linux 2.6.37 kernel, Mesa 7.11-devel, xf86-video-intel 2.14, and libdrm 2.4.23, I then decided to run the common OpenGL games such as those in the recent open-source ATI Mesa benchmarks. It's a simple, phoronix-test-suite batch-run vdrift nexuiz warsow openarena padman smokin-guns and selected 800 x 600, 1024 x 768, 1280 x 1024, and 1920 x 1080 as the resolutions for each test to see how well the Sandy Bridge graphics and driver were scaling. However, in the end, I did not have a single valid result for one reason or another with each test.
VDrift ran the best overall, did not crash once even when testing it at all of the resolutions, and provided decent frame-rates, but there were random artifacts appearing on the screen. But this was just the start of the problems.