1. Computers
  2. Display Drivers
  3. Graphics Cards
  4. Memory
  5. Motherboards
  6. Processors
  7. Software
  8. Storage
  9. Operating Systems


Facebook RSS Twitter Twitter Google Plus


Phoronix Test Suite

OpenBenchmarking.org

Intel Haswell Graphics Code Begins Appearing

Intel

Published on 19 March 2012 11:33 PM EDT
Written by Michael Larabel in Intel
9 Comments

The open-source Intel Linux graphics driver code for Intel's 2013 platform, Haswell, has begun to surface.

Last month I mentioned that Intel Haswell graphics driver code would soon surface, it's taken a bit longer than anticipated, but the Intel Open-Source Technology Center developers are beginning to push the code publicly so that the hardware enablement can land in Linux distributions ahead of the hardware's availability a year from now.

Due to varying Linux release schedules and development cycles, plus that the open-source Linux graphics drivers can't be easily updated by end-users without updating most of the system's core components, Intel's OTC developers are left to push out their new hardware support code quite early. Both Sandy Bridge and Ivy Bridge Linux driver code began appearing a year in advance, so it's that time of the year for Haswell graphics code to begin appearing for the Linux kernel, Mesa, libdrm, and the xf86-video-intel DDX.

Haswell is Intel's successor to the yet-to-be-launched Ivy Bridge processors and the architectural successor to Sandy Bridge. Intel Haswell CPUs are expected in the first half of 2013 and will be built from a 22nm process with 3D tri-gate transistors, and introduce new goodies like the "stacked memory" for better graphics performance.

As far as the first code that's out there, hitting the intel-gfx mailing list this afternoon were some Haswell PCI IDs. While it's just some PCI IDs for a header file, it's interesting for a few reasons:

- First of all, beyond adding in the IDs for two desktop parts (IDs: 0x0402 and 0x0412) and two mobile parts (IDs: 0x0406 and 0x0416), it also adds in a "Mobile ULT" ID. Sandy Bridge and Ivy Bridge both had two PCI IDs for mobile/desktop (the GT1 and GT2 parts), plus a Ivy Bridge server ID, but this is the first time seeing a "Mobile ULT" chip explicitly appear in the Linux driver (ID: 0x0A16). The "Mobile ULT" comment is presumably for a mobile ultra-book graphics processor variant for Haswell.

- It's been rumored there will be three graphics processor variants, with a "GT3" Haswell, but the IDs listed now only mention GT1 and GT2.

- This initial code is treating the Haswell IDs as being a "Gen7" device, the same as Ivy Bridge (Sandy Bridge is "Gen6"), but not a "Gen8" device. While there are obviously some differences between Ivy Bridge and Haswell graphics, apparently Haswell will be close enough that it can safely hit most of the Ivy Bridge code-paths. Though Intel may very well be developing Haswell out as Gen8 over time.

Stay tuned for more information and analysis once the more juicy patches arrive. It would be a last-minute arrangement, but the first bits of Intel Haswell graphics support for the DRM driver could be merged into the Linux 3.4 kernel with its merge window just opening. On the Mesa driver side, there's still several months before the user-space graphics driver library is updated, so there should safely be first-cut support with Mesa 8.1. Like Sandy Bridge and Ivy Bridge, expect Intel's open-source developers to refine the code a great deal over the coming months prior to the hardware's availability next year.

Besides the graphics support, there's already Haswell CPU support building in open-source compilers. Haswell introduces the AVX2 instruction set to build upon the Advanced Vector Extensions from Sandy/Ivy Bridge. Initial support for these new instructions are already handled by the latest GCC and LLVM code.

About The Author
Michael Larabel is the principal author of Phoronix.com and founded the web-site in 2004 with a focus on enriching the Linux hardware experience and being the largest web-site devoted to Linux hardware reviews, particularly for products relevant to Linux gamers and enthusiasts but also commonly reviewing servers/workstations and embedded Linux devices. Michael has written more than 10,000 articles covering the state of Linux hardware support, Linux performance, graphics hardware drivers, and other topics. Michael is also the lead developer of the Phoronix Test Suite, Phoromatic, and OpenBenchmarking.org automated testing software. He can be followed via and or contacted via .
Latest Linux Hardware Reviews
  1. AMD Launches New FX CPUs, Cuts Prices On Existing Processors
  2. Preview: AMD's FX-9590 Eight-Core At Up To 5.0GHz On Linux
  3. Intel Launches The Core i7 5960X, Mighty Powerful Haswell-E CPUs
  4. AMD Radeon R9 290: Gallium3D vs. Catalyst Drivers
Latest Linux Articles
  1. Ondemand vs. Performance CPU Governing For AMD FX CPUs On Linux 3.17
  2. How Intel Graphics On Linux Compare To Open-Source AMD/NVIDIA Drivers
  3. The Fastest NVIDIA GPUs For Open-Source Nouveau With Steam Linux Gaming
  4. Testing For The Latest Linux Kernel Power Regression
Latest Linux News
  1. New Group Calls For Boycotting Systemd
  2. The Features To Find With The Imminent Release Of LLVM/Clang 3.5
  3. Borderlands 2 Is Coming To Linux
  4. The Witcher 2 Ups The Performance More & Works Around Catalyst Bug
  5. Running Gallium3D's LLVMpipe On The Eight-Core 5GHz CPU
  6. Trying Intel OpenCL On Linux For Video Encoding
  7. GSoC 2014 Yielded Some Improvements For Mesa/X.Org This Year
  8. webOS Lives On As LuneOS With New Release
  9. Marek Lands Radeon Gallium3D HyperZ Improvements
  10. Mozilla Firefox 32 Surfaces With HTML5, Developer Changes
Latest Forum Discussions
  1. Lennart Poettering Talks Up His New Linux Vision That Involves Btrfs
  2. nv and xorg.conf under Debian PPC
  3. AMD graphics doesn't work with AMD Catalyst drivers
  4. Best Radeon for a Power Mac G5?
  5. The dangers of Linux kernel development
  6. Updated and Optimized Ubuntu Free Graphics Drivers
  7. AMD Releases UVD Video Decode Support For R600 GPUs
  8. SSD seems slow