#linux kernel 3.4

The merge window for the Linux 3.4 kernel will open up this month assuming the latest Linux 3.3 release plans work out. One of the features to look forward to out of Linux 3.4 will be the DRM driver support for Intel Medfield graphics. It's still tough to find Intel Medfield hardware out in the wild at the moment, but the low-power Intel hardware will be powering more smart-phones moving forward. Unfortunately, the Medfield platform relies upon PowerVR-derived graphics, similar to Intel's notorious Poulsbo. Imagination Technologies doesn't allow PowerVR licensees to provide open-source 3D graphics drivers, which has been handicapping Intel and other vendors. Imagination keeps the PowerVR intellectual property tightly closed. The proper Intel Medfield Linux graphics support is provided by a mess of binary blobs. There is also an open VA-API Medfield driver. The good news is that Intel is dropping PowerVR graphics in the future and that for the 3.4 kernel there will be at least basic DRM/KMS support for Medfield. Alan Cox has been adding Medfield support to his GMA500-Poulsbo DRM driver. This DRM driver doesn't provide any graphics hardware acceleration nor feature-rich like the in-house Intel / Radeon / Nouveau DRM drivers. The open-source Poulsbo driver just provides a clean mode-setting experience and a slightly better experience than using the xf86-video-vesa DDX driver without kernel mode-setting. To the DRI development list, Alan Cox sent over a set of 47 patches for the Poulsbo driver. This work is to be merged for the Linux 3.4 kernel. This set of 47 patches adds around 6,000 lines of new code to the opens-source "GMA500" driver. Most of this is the Medfield hardware enablement plus some clean-up work. The Medfield enablement work wasn't done single-handedly by Alan Cox like he's done in the past with Poulsbo as his pet project, but by Kirill A. Shutemov, a fellow Intel OTC engineer. The current Medfield support is considered experimental. The Medfield support covers kernel mode-setting, backlight control, and other basic functionality. But there remains no 2D/3D acceleration support. Though there may be some hope of seeing 2D acceleration in the future with 2D acceleration references in one "mdfld" struct and a code comment for "2D acceleration." Meanwhile, other Linux 3.4 kernel changes to look forward to include performance improvements to Intel's main DRM driver (Sandy Bridge, Ivy Bridge), a DisplayLink KMS driver, more Android staging patches, hopefully Radeon HD 7000 series support, and a lot of other work to be talked about in the coming weeks.

Towards the end of last year a new effort was initiated to mainline more of the Android changes inside the Linux kernel. Work has been progressing on that front and with the Linux 3.4 kernel more of these changes will land. The Linux Foundation, Linaro, and others have been interested in merging more of the out-of-tree work by Google on Android back into the mainline kernel. This would ease things for developers, manufacturers, and others. In the past, attempts at merging key Android changes have failed or ended up in staging but to only then be un-maintained. This time around, the mainlining effort has been working out better and more changes are set for the 3.4 kernel. John Stultz of Linaro published the latest Android update patches for the Linux kernel staging area to be merged during the Linux 3.4 kernel merge window. The mailing list patches begin here. Of the changes in this staging pull isn't anything particularly exciting but Android work on the RAM console and persistent RAM. This work doesn't include the recent Wake locks work that's still considered a proof-of-concept for an upstream implementation. Outside of the kernel, if you missed it, there is now a Java-based X11 server for Android.

While the Linux 3.3 kernel is still weeks away from release, there's more building up to look forward to with its successor: the Linux 3.4 kernel. A few months down the road when Linux 3.4 makes it out, there will be some additional Intel performance improvements. Daniel Vetter, the current maintainer of Intel's "-next" Git tree for their open-source DRM driver, has issued a new pull request to David Airlie for pulling in the latest bits into his DRM subsystem "-next" tree. This is what will ultimately go into the Linux 3.4 kernel as soon as the next merge window is open. His pull request can be found on the dri-devel mailing list. There's some interesting work building up for Linux 3.4 when it concerns Intel's Direct Rendering Manager driver, namely there's interlaced mode support, improved error state work, a "pile of minor patches", and two performance-related items. PPGTT is short for Per-process Graphics Translation Table and allows each graphics process to map its own region of graphics memory.As PPGTTs are cacheable and each process having its own region of memory can avoid potential clashing, the PPGTT work leads to performance improvements. The other item that can enhance performance for Intel graphics in the Linux 3.4 kernel is swizzling support. Again, this is just a Sandy Bridge and Ivy Bridge feature. Coming up soon will be benchmarks to look to see how this latest open-source Intel work affects the Sandy Bridge graphics performance. It's also making me rather impatient to see shipping Ivy Bridge hardware and how interesting its performance will be. Besides the PPGTT and swizzling support, enabling RC6 support in their kernel driver also leads to significant performance improvements. This should be in place for the Linux 3.4 kernel as well assuming there's no other fallout from faulty Sandy Bridge systems not being able to handle the RC6 power-savings feature. As far as where the Intel Sandy Bridge Linux graphics performance is at right now, read Intel Sandy Bridge Shines With Mesa 8.0. You can also see how the Intel Sandy Bridge performance compares to Mac OS X 10.8, the new "Mountain Lion" release coming out this summer from Apple.