Eugeni's blog

Updates from the Intel Linux Graphics land

devel, english, intel, kernel, mesa, Uncategorized, x.org No Responses »

Jan 292012

The real life and work issues had eaten most of my time for the past 2 weeks, but things seem to be geting back to normal now. So time for semi-regular updates from the Intel Linux Graphics land.

Starting with kernel, many notable changes happened in the past weeks. To make our -next merge window process go faster, a new process was adopted for the kernel patch and branch handling process. Let me elaborate a bit more about how this is going to work.

For the past months, we had the drm-intel-next branch (containing patches intended to go into the next merge window – e.g., when the 3.3 kernel is being developed, this is the branch which contains patches intended to be included in the 3.4 kernel version), and also drm-intel-fixes branch (containing patches for the currently developed kernel – e.g., patches which fix issues which were added during the past merge window. So for instance, those are the patches which go into 3.3-rcN kernel versions after the merge window). Both of those patches were maintained by Keith Packard.

However, the amount of patches combined with other tasks resulted in a somewhat slower patch queuing process. So Daniel Vetter has volunteered himself to maintain the drm-intel-next branch from now on, reviewing, queuing and managing the patches intended to get into the next kernel merge window (for now, those are targeting the 3.4 kernel version).

At the same time, Keith Packard will continue to maintain the drm-intel-fixes branch, managing and carrying stability patches for the current kernel.

And finally, to improve the testing and availability of newer features for older kernel versions, I’ve started my own drm-intel-backports set of branches, for 3.0, 3.1 and 3.2 kernel versions – containing all the latest and greatest patches from the latest kernel releases. Of course, those patches do not follow the usual kernel stable development model, so they introduce new features, capabilities and possible issues. But for the brave souls out there willing to see and test the absolutely latest development in our drivers on top of their kernels, it should be a great chance to do so.

(I assume that I was not that fast with the drm-intel-backports patch merging process in the past 2 weeks, so for now it only contains patches from the 3.2 kernel branch. I intend to backport the 3.3 and 3.4-next patches for all those versions in the coming days. Also, apparently those backported patches do not work correctly with pre-Ironlake chipsets on 3.0 kernel, and there are some display-related issues on top of 3.1 one – I’ll look into it as well. Sorry for the delay – but the real life interfered with my patching capability for the past weeks…)

Besides those changes, we had a large number of notable kernel advances in the past weeks:

One of the most interesting features is the support for interlaced modes in the Intel Linux Graphics cards. A great work by Peter Ross, Daniel Vetter and Paulo Zanoni resulted in a series of patches which provided support for interlaced modes. These patches will be queued for inclusion in the 3.4 kernel – but when I’ll get back to my -backports series of patches, I’ll certainly include them into the 3.[012] series as well.
More Ivy bridge 3-display pipes issues were fixed, such as the hibernation problem with 3rd pipe being active.
Stabilizing the almost-ready-to-launch Ivy bridge platform, the hopefully final forcewake-related fixes were included in both drm-intel-next and drm-intel-fixes branches, and were also cherry-picked by Greg to be included in the stable 3.2 kernel as well. This should solve the remaining missing interrupts problems we were experiencing.
Initial patches to support the hardware context switching were sent by Ben Widawsky, and are accessible in his own freedesktop.org repository for testing. Hardware-supported context switching allows to save the hardware registers and state for each process, so it could essentially help the GL_EXT_transform_feedback extension and advanced geometry shading state passing between different stages. And, of course, it can also improve the stability – hardware would ensure that different processes would not interfere with each other in a harmful way.
And almost a hundred pending patches were picked by Daniel Vetter for his new drm-intel-next branch. The next merge window certainly looks interesting for the Intel Linux Graphics support in this sense…

On Mesa side, the 8.0 release is getting really close. After the 8.0-rc1 release a couple of weeks ago, lots of patches were picked into the 8.0 branch, improving the stability, performance, and fixing many rendering issues – especially on the Ivy Bridge platform. More excitingly, the communication between Mesa and Unigine developers resulted in better support for open-source drivers in the just released Oil Rush game. It is really great to see such cooperation – and Unigine-based game certainly is one of the most advanced graphical releases of past years on Linux.

Speaking about the Mesa development, this final stabilization phase prior to the 8.0 release is a great chance for you to report issues, bugs and problems before the release which is expected in a few days from now. So if you observe any last-minute problems and regressions with Mesa 8.0 branch – please, let us know! This next release looks really impressive from the technical side, but your help in additional testing is more than welcome.

On Wayland side, lots of different patches and features were received in the past weeks. Wayland and Weston development goes on with great pace – and the ones of you to attend FOSDEM next week will have some really interesting stuff to gaze upon. But I won’t spoil the surprise .

On Xserver development, the 1.12 RC2 and 1.11.4 releases were unleashed last week, together with a new glproto, util-macros and xkeyboard-config versions. The development continues non-stop, with hundreds of patches and discussions happening in the mailing lists.

And finally, the phoronix feedback I got from you over the past weeks was amazing. Thank you all for all your questions and suggestions – it was really nice to hear what you have in mind, what you like (and dislike) in our drivers and what direction we should be heading. I’ll try to answer the last remaining questions in the next few day, and will summarize everything on a dedicated blog post.

Phoronix survey about Intel Linux Graphics

devel, english, intel 7 Responses »

Jan 142012

For the ones of you who haven’t read Phoronix lately – Michael is running a survey about Intel Linux Graphics drivers for the past few days.

So far it got 10 pages of amazingly interesting comments (which I was trying to answer as time and my fingertips permitted). 95 comments as of now to be fair (sorry, 96 already – my bad ). Make sure to check it out.

In the end, I’ll try to summarize all my replies in the thread here. But it will be a long read by the looks of it.

Bleeding edge i915 for stable kernels

devel, english, intel, kernel, linux 2 Responses »

Jan 112012

One of the most frequent ~~complains~~ questions related to the Intel Linux Graphics drivers I’ve received in the past few months was: “Why Intel devs work only on the most bleeding edge, and do not give enough attention the us stable users”?

Yes, this question affects all the components of the stack – kernel, mesa, libdrm, 2D driver, and so on, but the answer to this is quite simple – this is how software gets developed. New features go into new releases, and stable releases receive bugfixes and stability improvements at most. And this is not much of an issue to the userspace components anyway – with all the LD_LIBRARY_PATH flexibility it is possible to have multiple versions of the libraries installed without any issue. But as for the kernel, indeed, it is not that easy. So most of the times, those questions were directed at the kernel part of our driver – namely, the tiny i915.ko module which is responsible for making the graphical heart of Intel-based GPU beat.

Even for the kernel, this is not exactly true – Greg’s stable trees do include most of the critical fixes for our drivers since always. But it is true to some point – most of the newest development and patching happens within the usual Linux development window – and those patches and features are then merged to the release candidates of a future kernel during the merge window. And for the kernel, it is not that easy to have multiple kernels around at the same time without having to reboot between them here and again.

So therefore, I thought on giving a small gift to the users who are not still ready to jump into the latest and greatest kernels releases – but still want to enjoy the goodies brought with the latest versions of the graphics driver. So I prepared two kernel branches on my freedesktop.org kernel repository:

3.0-drm-intel-backports — latest 3.0.x kernel with all the i915 patches from latest kernel release. Right now, it is 3.0.16 + 195 backported patches. Diffstat reports 78 files changed, 4988 insertions(+), 2176 deletions(-).
3.1-drm-intel-backports — latest 3.1.x kernel with all the i915 patches from latest kernel release. Right now, it is 3.1.8 + 104 backported patches. Diffstat reports 74 files changed, 3147 insertions(+), 1589 deletions(-).

Besides driver backports, the patches which affect multiple drivers (like, i915, nouveau and r128) were also backported in full in those branches. And all the required build and API dependencies (like HDMI/DP ELD or drm/gem API changes) are also included in full.

I’ll try to keep those branches maintained on a semi-periodic basis and synchronized with the latest updates both from -stable branches, and from newest kernel releases.

Of course, let me put an obligatory support and stability statement:

Those branches are not supported officially, are experimental and can be unstable or even broken sometimes (in which case, if you’d be kind enough to let me know about that, I’d try to fix them ASAP). So use them at your own risk.

Other than that, have fun .

New year, new stuff

devel, english, intel, kernel, linux, mesa No Responses »

Jan 062012

So, holidays came to an end, and it is time to get started with the 2012 series of “tales from the Intel Linux Graphics land”.

But as the year has just started, it is still time to cover some amazing gifts which Santa ClausDaniel Vetter brought to you all right in time for Christmas. Yes, I am talking about the new intel-gpu-tools 1.1 release!

This new release comes after 2 years from the 1.0.2 release (which came out back in 2009), and accumulates an astonishing amount of changes:

Diffstat reports that 138 files were changed, having 29694 insertions and 3524 deletions.
Lots of new instructions and registers decoding logic was added in intel_error_decode and intel_reg_dumper tools
Many changes in intel_gpu_top, which can now run non-interactively for monitoring GPU usage statistics
Different display and mode setting tests
And, probably the most interesting feature out there, the introduction of a full-feature test suite for Intel and DRM testing.

Let me stop a bit on this latest feature, and explain it in a more detailed form. Starting with the 1.1 version of intel-gpu-toops, the package provides a complete testing suite for most of the known issues and problems that have been caught in our graphics drivers for Linux for the past years. So when you run make test (as root) in the intel-gpu-tools directory, this will start a long pile of test cases, testing most parts of the GPU.

Ideally, all tests should pass – this means that your current kernel and userspace libraries are not affected by any known kernel (or userspace) issue. Some tests can fail – usually this comes with an explanation of why it fails (either on the test output or in dmesg). And some tests can fail in a very evil way, hanging the GPU or the entire machine. A specific category of tests (HANG tests), which are not run by default, are designed to test specific corner cases which should make your machine hang for good; and some tests are written specifically to caught performance regressions and hick-ups.

Still wonder why is this interesting? Well, I can think on one obvious huge bonuses we get from this test suite – if you are experiencing an issue, you can run the make test suite, and verify if it is a new genuine bug, or something that was already caught by a test case. And obviously, this is an easy way to find and track regressions on the kernel and drm level.

So, to sum it all up – if you want to give a quick try and check if your kernel/userspace/distribution configuration is affected by any known issue in the driver, just run the testsuite. If it passes, you are good to go. If it does not passes, well, you already know that something is not right and needs investigation.

Besides intel-gpu-tools, Mesa work continues towards the remaining GL 3.0 features. During last few days of 2011, Eric Anholt sent some patches for adding hardware support to GL_EXT_transform_feedback bits present on the Ivy Bridge architecture. Besides those changes, hundreds of patches and discussions take place on the mesa-dev mailing list – the most user-notable change comes from the fact that XCB is now mandatory. I guess we have a clear winner in the XCB vs XLIB match in 2012..

On Kernel side, with the release of 3.2 version of the kernel, next merge windows has opened and already received some patches for 3.3 kernel series. Besides the usual fixes and new features which I already covered in previous posts, several alternatives were proposed by Chris Wilson and Eric Anholt to solve the mysterious missed IRQ issue which affects Ivy Bridge (and some Sandy Bridge) machines. The winner in this competition, however, was Daniel Vetter, who came with a simple patch that not only had solved the issues in a nice way, but also allowed us to remove several work-arounds which were added in the past. So far, all my Ivy Bridge machines are up and running for some days without any problems – which is totally awesome!

Moving to other projects, notable changes which were introduced in the past weeks were the move of intel_decode facility for decoding GPU batch buffers from intel-gpu-tools to libdrm library by Eric Anholt; patches from Paulo Zanoni to support new screen rotation feature of VPro; additional patches for improved Glamor performance from Zhigang Gong; support for building libdrm on Android from Chad Versace; Kristian Høgsberg created a new W-prefixed project for Wayland (namely, Weston, which is a different town in Massachusetts state. I actually got to get through it once when I was in the US back in 2005, working on a remote boot and software streaming project for mstech, which was further acquired by Ardence, which was further acquired in Citrix.. fun to see how the world goes in circles ).

So I think that’s it for now. For the ones who are still in the new year holidays, enjoy the rest of your holidays; and for the ones who are already back into to the real life – welcome to 2012!