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.
