It was just midnight yesterday when the press embargo covering Intel's Sandy Bridge micro-architecture with their new Core i3/i5/i7 and H67/P67 chipsets expired. While at Phoronix we have known how Sandy Bridge would work with Linux
, the lack of "out of the box" support for the next-generation Intel graphics under Linux or an easy-to-use way to deploy the open-source drivers on existing distributions caused a bit of an uproar by other journalists. Well, more like a big uproar
As I've been talking about over the past two days to a number of different parties, it can be a challenge to deliver open-source GPU Linux drivers
at launch due to the different components that make-up the driver stack. It's not that there aren't any Sandy Bridge Linux GPU drivers available, they're all in Git form right now and will be released as source packages in the coming days (Mesa 7.10, xf86-video-intel 2.14.0, Linux 2.6.37), but it isn't too easy for end-users to deploy.
The Sandy Bridge Linux graphics support isn't actually too bad besides lacking out-of-the-box support or any easy way to easily upgrade the driver stack for novice end-users of Linux. There's open-source OpenGL acceleration (though it's over classic Mesa and not Gallium3D), VA-API video decoding (and encoding support is evidently on the way this quarter), 2D/KMS, etc. This support though will be found in Ubuntu 11.04 when released in April and Fedora 15 in May, so it's really just the very early adopters that will be impacted by having to roll their own driver stack or find any third-party package repositories.
Intel though admits it could have done better with its Linux launch support. In one of our active threads in the Phoronix Forums
, Jesse Barnes admits they sort of messed up
with the Sandy Bridge launch. Jesse is one of the open-source Linux developers at Intel responsible for the support upbringing and ongoing driver development across their DRM / Mesa / DDX.
No, this is our job, and we blew it for Sandy Bridge. We're supposed to do development well ahead of product release, and make sure distros include the necessary code to get things working (we have separate teams to do development and aid distros in backporting, though most of them can handle it by themselves these days).
I could give you all sorts of explanations as to why this is (Sandy Bridge is a big architectural change, we made some mistakes in defining our development milestones, and we didn't work hard enough to get our changes backported), but really there's no excuse. Fortunately we've learned from this and are giving ourselves more time and planning better for Sandy Bridge's successor, Ivy Bridge.
As for a stable ABI, yes it would definitely help situations like this and make lives easier for distros, device manufacturers, and probably users. But it would make life harder for developers, and as we all know, open source development is driven by developers, and we're a whiny and lazy bunch. (Yes, this is a flippant remark, don't take it too seriously since I omit much of the complexity behind the "life harder for developers" part that has big implications for users, distros, and device manufacturers; it's a complicated issue.)
At least it looks like things may be better for those Ivy Bridge early adopters and reviewers... Ivy Bridge is the Sandy Bridge successor. Again though, for Sandy Bridge things went well (assuming the performance isn't bad once we are able to run our tests) aside from perhaps some timing issues for providing out of the box support. There can be underlying changes made to improve the process of releasing open-source graphics drivers and making them more easily update-able by end-users of Linux, but this isn't an Intel or Sandy Bridge-specific issue but is something that affects all hardware vendors. This also isn't something that can quickly change overnight.
We will be delivering our Sandy Bridge Linux performance results as soon as we gain access to the CPUs and build the latest code from Git.