A first post about Intel Linux Graphics and their friends

A long time no post.. but then, it was also a long time without a home, internet and free time as well.

As you already know, since August I am working at Intel, within the Intel Linux Graphics group. And, as many of you know as well, the news about Intel Linux graphics out there vary a lot, but usually just between the “it just works” and “nothing works” states, with few intermediate points in between (many of which are usually covered by phoronix news).

So to fill those empty spots, I thought on getting back into the habit of semi periodic write-ups I got while at Mandriva – just giving out some insights, overviews and overall updates about what is going on with Intel Linux Graphics and related open-source projects from time to time.

But first of all, let me do a quick review about what Intel Linux Graphics is all about. Unlikely other drivers project, the Linux Graphics does not consists from a single and unique driver. By the contrary, it has a lot of ground to cover, working directly on the upstream projects which compose the graphical stack – ranging from the i915 driver in kernel to the entire MESA 3D/GL stack, passing through libdrm and vaapi and all the way up to x11-server, cairo and wayland – among others. So when you read about an Intel Linux Graphics release, it considers a snapshot version of each of those components.

Of course, each of those projects has a different release goals and timelines, different sets of features to cover, and so on. And, of course, there is a matrix of different generations of graphical hardware, different variations of the models and revisions, and a multitude of OEM platforms to cover.

So, in short, “it’s complicated” .

In this sense, the Intel Linux Graphics project so far was doing quarterly releases of the entire stack, as one could see at 2011Q3, 2011Q1, 2010Q4 and all the previous ones. However, one of the problems with the quarterly releases, specially over such a big and varying stack, is that they don’t fit all the situations. So starting with the next release, we’ll be changing our process to carry out more specific releases, based on pre-defined release criteria for each of them. And the next release will be focused specifically on performance and stability enhancement over our current code.

What do I mean by performance and stability? While most of the people out there do not experience any issues with the drivers (e.g., “they just work” category I mentioned out there), we are by no means perfect, and yes, we have bugs which affect different users, operating systems and hardware components (all the way to that “nothing works” category of people – which is thankfully quite small, and of course we hope to promote it to the “just work” category of the people ASAP). And we are trying to get better and better for each release, at the same time trying to maintain the same level of openness as one would expect from open-source projects.

If you look at the freedesktop bugzilla, for intel graphics-specific issues, there is a quite complete list out there. Of course, many of those bugs are old, or do not apply to the current state of the code anymore, but some of those are valid – and they don’t get the level of attention they need. Specially considering the large number of reports, it is really hard to keep track of all of them, and it is specially easy to get lost among all of them. So if your bug is not getting enough attention – just go over to it, and ping us. We do not ignore you, but sometimes we lose track of specific issues out there, and we’ll be happy to be reminded either when an issue is fixed, or whether it is still out there and needs some love .

So, as I said previously, I’ll try to cover up the details of each part of our drivers stack, and try to keep updated the list of the current work and goals we have in mind. So I’ll start with this first post, and will try to cover a bit about the areas we’ve been focused the most for the past months – specially considering the “performance” and “stability” criteria, and the most interesting features we have out there.

RC6

The first feature which I’d like to mention, which is probably unknown to most of you out there, is the support for RC6 technology. This is a feature which allows the GPU (in other words, the graphical adapter) to enter an extremely low power-consuming state while the graphical card is idle. This feature has drastic effects on the power usage of the system – up to 26% power usage improvements according to Phoronix testing. So in theory, having this feature enabled by default would allow a much better battery life for a casual system out there equipped with an Intel graphical card.

However, one drawback to the rc6 is that in some very rare cases, it results in different set of issues. The good part is that very few systems are affected by this bug, and none of the machines either the developers or QA team has managed to reproduce the problems, so chances are very high that it could just work for your by adding a ‘i915.i915_enable_rc6=1′ parameter to the kernel. The bad part is.. well.. the same as the good part – we could not reproduce the issues on any of the machines we had. So by a chance, if you enable this feature and hit some unexpected behavior or issue – please, let us know! We would be really interested in fixing this for all the systems out there. But, with all the magnitude of different x86-based machines, it is virtually impossible to test them all. So we need your help to help of us fix this issue, in case it affects your machine. All the details, such as the vendor, model, installed OS, whether the issue happens with a new install from scratch, bios configuration – would help.

FBC

Besides RC6, one other interesting feature present in the Intel graphical drivers is the support for framebuffer compression, of fbc. This feature allows the driver to store the contents of the picture on screen in a compressed format, effectively reducing the amount of energy (and, therefore, power) required to update the screen. On some hardware revisions, however, this feature sometimes causes the GPU not to redraw the display correctly, resulting in only partial screen updates, sometimes visible only after a few suspend-resume sequences. The solution for this problem was to disable this feature by default on such machines, while having it enabled automatically on the chips which do not reproduce the problem. However, even on those chips, you can always enable it manually, by using a i915.i915_enable_fbc=1 kernel parameter.

Semaphores

And finally, the 3rd major issue being worked on the kernel side is the usage of semaphores in the graphical driver, which allows for a big jump in performance, and also in stability in some cases. However, not everything is perfect in this world , so on some hardware models this feature results in performance choppiness or GPU hangs. It is within of the nature of the bug to appear only on some selected machines, most of which are out of our reach, so chances are, like with the RC6 and FBC features, it should just work out of the box. But if it does not – please, let us know!

Apart from those 3 big items, lots of work has been carried out on different components of the stack in the past months. I’ll try to summarize the most interesting points for each component below.

Kernel

The Linux kernel 3.1, which is quickly approaching its release date, brings lots of stability and performance improvements over 3.0 version. The performance results are the most notable ones, as according to the initial testing, you could expect about 25% performance improvements in 3D games and performance benchmarks (and even up to 40% in some of them). I won’t enter into the details here, as I am certain that Michal Larabel from Phoronix will do his usual round of benchmarks soon enough and provide the numbers .

Besides the performance fixes, the timing for detecting the different video outputs has also received lots of attention. Some of the fixes will appear in 3.1 kernel, and some of them are already being prepared to get into 3.2 as soon as its merge window will open.

And of course, there were lots of patches for stability and error recovery within GPU.

Out of the major distributions out there, as far as I know, only Mandriva Cooker has already updated its kernel to the latest 3.1 pre-released version, so its users already have most of those features with them. So if you are a brave soul and are willing to try this as soon as possible, you could either try Mandriva’s development version; or download and build the 3.1-git kernel yourself. Or just wait a few weeks and it will came to you as soon as your $FAVORITE_DISTRIBUTION would update it in the repository.

So, leaving kernel area, let’s move to another major component of the stack, which is well-known by its name..

MESA

(No, it is not the Black Mesa Research Facility, so you may put away your crowbar )

Lots of work has been done on Mesa library, and some thousands of emails on the mesa-dev mailing list complement this statement.

Some initial patches for HiZ support from Chad Versace landed on the list, and Phoronix has also performed initial testing on them, obtaining very impressive results.

Also, a huge cleanup of old drivers, together with the removal of old DRI1 code and overall refactoring of the code in preparation for the GL 3.0 was done by Ian Romanick. Kenneth Graunke provided lots of patches for both performance and stability improvements for a large number of cases, together with the IvyBridge-specific optimizations. New Vertex Shader backend, lots of TextureImage development by Eric Anholt, work on gl_ClipDistance and the layout of vertex attributes by Paul Berry, lots of GLSL 1.30 development and overall bugfixing complement the picture of what happened with Mesa for the past month or so.

As mesa-dev list, and the git source tree, are quite busy places, there were lots of other development and updates all around which I haven’t covered here. Mesa 7.11.1 and 7.12 are really going to be amazing releases when they will come out!

But leaving mesa, the next stop in the Intel Linux Graphics stack overview leads us to..

DDX, or xf86-video-intel X driver

The video driver for Intel graphics cards has received lots of attention for the past weeks. Most of the patches came from Chris Wilson, and were related to further improvements in the SNA backend, and a fix for a non-SNA-related X crash. Besides those, we also had some IvyBridge-specific fixes from Kenneth Graunke and cleanup of some warnings from Paulo Zanoni.

Cairo

On Cairo side, a huge work has been made on performance, stability and testing. In some workloads, the performance improved by several orders of magnitude, and in average, one could expect better performance for Cairo on most cases when comparing with the previous release.

Wayland

For Wayland compositor, lots of discussions took place in the wayland-devel mailing list, covering a large collection of topics, randing from the best way to process configuration events and requests, similarities and differences between the wayland protocol and X operations, window management and overall interaction between the clients and the compositor within the Wayland world. From the technical side, there were lots of patches from Tiago Vignatti and Kristian Høgsberg on both core wayland and the wayland-demos repository. One notable change was the change of the GPLv2 headers to MIT for the remaining files where such change wasn’t applied previously.

Intel-gpu-tools

The package for providing tools for debugging, analyzing, tracing and profiling the Intel graphical cards on Linux/Unix has received some code cleanups from Paulo Zanoni, some news tests from Daniel Vetter, and also a small series of patches from myself which allows it to work in a non-interactive way, generating a tab-separated list of performance values for each capturing points. Those events can be further analyzed with a statistical tool, or plotted with gnuplot, or dumped into openoffice calc/excel applications – you name it.

Libdrm

Libdrm, which is a glue between the kernel and the userspace applications that use the kernel graphical driver, has received some fixes from Daniel Vetter last week. Besides those, there was a fix to make ‘make check’ work correctly, and a support for using xf86drm.h from C++ applications.

Xserver

X.org X server has received lots of updates and merges since the 1.11.0 release in the past weeks. Among the most notable ones, there were some enhancements to the DRI2, XRANDR and DAMAGE extensions, documentation, comments and scripts fixes, besides the changes in the input framework.

VAAPI

And finally, as for VAAPI, not much activities happened in the git repo for the past weeks besides some refinements on the API and the vatrace tool.

So, as this post has already grown past the size I originally expected, I think that I’ll stop about here this time.

I’ll try to continue with the semi-regular blogging about the news in the graphics land of Intel world on a weekly basis.

See you! Eugeni