For everyone’s joy and amusement, Intel Ivy Bridge programming manuals are now available at the intellinuxgraphics.org site.

This time, the documentation is split across 4 volumes, and consists of 17 pdf files. Comparing with last year’s Sandy Bridge documentation release, there is 1 additional part focused specifically on L3 cache and URB, a specific section about GT interface programming, another part covering multi-format transcoder, a new section specifically for PCI registers and one additional section focused on execution units details.

For the ones of you not feeling like clicking on the very first link in this post, these are the contents of this documentation release:

• Volume 1 Part 1: Graphics Core
• Volume 1 Part 2: Graphics Core – MMIO, Media Registers & Programming Environment
• Volume 1 Part 3: Graphics Core – Memory Interface and Commands for the Render Engine
• Volume 1 Part 4: Graphics Core – Blitter Engine
• Volume 1 Part 5: Graphics Core – Video Codec Engine Command Streamer
• Volume 1 Part 6: GT Interface Register
• Volume 1 Part 7: L3$/URB
• Volume 2 Part 1: 3D/Media – 3D Pipeline
• Volume 2 Part 2: Media and General Purpose Pipeline
• Volume 2 Part 3: Multi-Format Transcoder – MFX
• Volume 3 Part 1: VGA and Extended VGA Registers
• Volume 3 Part 2: PCI Registers
• Volume 3 Part 3: North Display Engine
• Volume 3 Part 4: South Display Engine
• Volume 4 Part 1: Subsystem and Cores – Shared Functions
• Volume 4 Part 2: Subsystem and Cores – Message Gateway, URB, Video Motion Estimation, Pixel Interpolator
• Volume 4 Part 3: Execution Unit ISA

If you always wanted to understand the internals of a GPU, learn about the amazing world of MMIO registers programming and have control over your GPU, this is your chance .

Have fun!

I noticed that my current PGP key was getting close to its expiration date, and it was also created back in 2008, when security was not that fancy as today (yes, it still was DSA 1024 bits. Yes, I don’t have any excuse for still using that, even considering the fact that I used it like 10 times in all those years. But yes, I finally got to fix it now). So today, I’ve switched to a shiny new GPG key:

pub   2048R/B84A5081 2012-06-12 [expires: 2022-06-10]
      Key fingerprint = 1FD0 C0DB 2044 314A DF46  9C36 F13E ADA4 B84A 5081

So in case you were using one of my old keys:

pub   1024D/0A292828 2008-05-08 [revoked: 2012-06-12]
      Key fingerprint = 8441 D93F 4CBA A266 45EF  3596 AE49 27EB 0A29 2828

or

pub   1024D/CF6C0F93 2009-01-22 [revoked: 2012-06-12]
      Key fingerprint = 1B7C 4A3D EDEC C46D CC52  6FFE AB2F 0267 CF6C 0F93

Please switch to a new one. It should be available on most keyservers shortly, and also at http://eugeni.dodonov.net/pubkey.asc directly.

So, Kernel 3.4 got released a couple of days ago, and the merge window has reopened for the 3.5 Kernel release.

We have put lots (and I mean it!) of work towards making a huge progress in the Intel Linux Graphics kernel driver for the 3.4 kernel, but things look yet even more brighter for the next one – namely, 3.5!

As a picture speaks louder than 1000 words, I’ve done a simple chart comparing the number of changes in the drivers/gpu/drm/i915 directory over the Linux Kernel releases since the 2.6.30 release some years ago:

Linux Kernel commits rate between 2.6.31 up to 3.5.0 (so far)

Between 3.3 and 3.4 Kernel versions, we had an astonishing number of 152 commits related to the drivers/gpu/drm/i915 directory (e.g., the Intel graphics driver in the kernel). This number looks impressive – but it is pale if we compare it to the 343 commits we had so far for the 3.5 Linux kernel merge window

So far, we are just 2 patches away from the all-time high of the 2.6.37 Kernel – and we are just getting into the 3.5 Kernel development cycle yet.

In case it is easier to read the absolute numbers instead of graphs, here is the full picture, generated from the git log --oneline <<kerner_version>>^1..<kernel_version>> drivers/gpu/drm/i915 command, for all the kernels between 2.6.29 and 3.5 (up to date):

2.6.30  98
2.6.31  122
2.6.32  119
2.6.33  144
2.6.34  69
2.6.35  155
2.6.36  184
2.6.37  345
2.6.38  247
2.6.39  113
3.0.0   109
3.1.0   131
3.2.0   126
3.3.0   78
3.4.0   152
3.5.0(next) 343

I’ll try to cover some of the highlights of the next Kernel release in the next post (ppgtt? haswell? valley view? DRI1 ? RC6? I2C? VBT? Those are just some of the keywords) – but this kinda answers the question whether the Intel Linux Graphics driver is alive.

Yes, it is.

And it rocks .

As usual, starting with Kernel, I can say that this way a very, very busy month, and we had more kernel patches during this time than I can remember from the past. Several patchbombs came through, such as:

• Several rounds of Ben‘s patches for timed GPU execution, or BO waits. Those patches add the ability to specify the desired timeout parameter to the core GPU functions, and allow the userspace to specify how log to wait until they are done – instead of waiting for them indefinitely. It is a nice addition to the way userspace cooperates with the Kernel part for the GPU-related tasks, and a helpful addition to support the GL_ARB_sync OpenGL extension.
• Also from Ben, we had some patches that fixed a couple of sparse warnings. They should not change anything functionality or performance-wise, but they make the driver code more elegant .
• From Daniel Vetter, we had a 22-patch series for dragon slaughtering consolidation of the legacy DRI1 code paths. Those patches do a huge cleanup and properly split the DRI1 and DRI2 calls in a way that everything related to DRI1 should belong to the i915_dma.c module now.
• Chris Wilson and Jesse Barnes have been working on a better way to handle the PCH PLLs separately from the display pipes. This patch greatly simplifies the interaction with the components of the GPU located on the chipset, and allows to allocate or re-use different PLLs on-demand. This came particularly handy for my Haswell enablement efforts, where most of the things are being done by the CPU part of the graphics subsystem, and PCH is used for non-essential tasks.
• Also from Chris Wilson, we had a 28-patch series for reusing the stolen memory early in the GPU initialization. Stolen memory is being allocated by BIOS for its need, and previously, when Kernel GPU driver was loaded, most of the memory was re-initialized. With those new patches, it is possible to reuse BIOS-allocated objects and even allocate frame buffer from the stolen memory. Yet another step towards a faster and flicker-less boot!
• Ben Widawsky has sent his patches for L3 cache remapping. Those patches account for the row-level remapping of cache content when a parity error is detected, and this task is carried transparently to the software. On Ivy Bridge (which those patches are targeted), this situation is detected by means of an interrupt, and when this interrupt gets to the i915 kernel driver, it is able to cope with it and keep track of the failed bits. In other words, you may think on it as on a some sort of badblocks handling which is used for hard disks disks, but for L3 cache. Except that the L3 errors are much, much rare to occur.
• Some power subsystem refactoring came from me, where all the power-related components of the driver (rc6, watermarks, framebuffer compression, power monitoring and turbo-related bits) got moved into the intel_pm.c module; and Daniel Vetter has also complemented this new module with additional power-related items I missed in my original move.
• As another major patchbombing, I’ve send another round of Haswell GPU enablement patches, which add a new intel_ddi.c module, improve support for HDMI outputs, and address most of the comments I’ve received for the past months about those patches.
• And finally, still on Intel Linux Graphics page but on an entirely different hardware, Alan Cox has sent a round of updated kernel patches for GMA500 support to inclusion into the drm-next tree.

Besides those major patch series, we had several patches for i8xx interrupts handling and gen2 fixes (which also helps to answer the question whether the old i8xx graphics cards are still supported ), improvements in page flipping, turbo initialization, Sandy Bridge GPU hangs in Google Maps/Earth, proper IPS polling which should be limited to Gen5 architecture now, pineview clock gating and several backlight fixes, besides all the other smaller ones.

On 2D driver side, the major news of the past month was the release of Glamor 0.4 acceleration backend. The biggest changes are the support for DRI2 and texture from pixmap functionalities, co-existance with AIGLX, many performance optimizations for pixmap uploading/downloading, full GLES2 color formats support and a new texture cache pool mechanism to reduce texture/fbo creating and destruction overhead and considerable improve overall performance.

Still on the 2D side of things, a new Cairo 1.12.2 release went out. This is a largely bugfixing release, which fixed a large number of issues which were found out since the Cairo 1.12 got released. Chris Wilson has also carried out a performance evaluation of Cairo 1.12.2 with different backends in his blog.

On Mesa side, lots of bugs were fixed, as usual, and among the most interesting updates for the past months that I caught were:

• Support for RGBX_8888 format used in Android native buffers from Sean Kelley.
• Support for additional gbm interfaces from Ander, used to allow weston compositor to reuse KMS framebuffer objects instead of creating and destroying them for each rendered frame.
• Addition of the DRI image v4 extensions to MESA_drm_image, and support for additional DRI image formats from Gwenole.
• Also from Gwenole, 5-patch series for the DRI2 changes to add support for the new Wayland and VA/EGL proposals to handle YUV buffers, and differentiate progressive/interlaced contents.
• A couple of fixes for mipmap offsets when used with HiZ and separate stencil buffers, from Paul Berry.
• Lots of work on GLSL support, from Eric, Ken, Ian and Paul.
• And finally, still from Gwenole, came a patch series to allow caching data regions according to a given offset.

Moving to Wayland, the patches that caught my attention were:

• Collabora’s Pekka Paalanen‘s patches for adding Android support for Wayland (which were already covered by phoronix as well).
• Ander’s patches for reusing KMS framebuffer objects.
• Gwenole‘s patches that added support for querying for the list of supported surface formats, support for YUV buffers and generic buffer formats.
• And Tiago Vignatti‘s patches for xwayland improvements, customizable modifier key biddings.

And, last but not least, we’ve gone through the list of the open freedesktop.org and kernel.org bugzillas, and managed to scrub dozens of fixes in the past few weeks, solving a huge variety of issues – from i8xx-specific bugs up to recent GPU turbo issues after idle on newer machines. If you have a bug open with us, take a look if it is still active – chances are that many of the issues you could have were already gone . And if it still there, it would be a great time to check it again and verify if the drm-intel-next tree is still affected by it. As Kernel 3.5 merge window gets closer, it is a very good timing to try to address the remaining issues prior to its opening.

That’s all for now – stay tuned for future news from the Intel Linux Graphics land, and enjoy the International Workers’ Day meanwhile – if your country considers it as a holiday, of course !

This time, it took me less time than on previous round of updates, so I think I’ll be able to give you some more details about some of the most interesting changes I’ve spotted for the past weeks.

Starting with the Kernel, many and many patches has landed into the intel-gfx mailing list. Among some of the most interesting were:

• Another round of Valley View enabling patches from Jesse Barnes. Some of both Valley View and Haswell architecture patches were already included into the drm-intel-next branch by Daniel Vetter, but obviously most of the things are still being worked on. Valley View patches are getting really close to their final form, but some of the changes come from the fact that its architecture handles most of the display-related operations in a very orthogonal way to the other GPUs we have. So we’ll still see more rounds of patchbombing on ValleyView front.
• Daniel Vetter sent another round of patches for PPGTT handling, most of which were already included in his drm-intel-next tree by now. Besides those, Daniel came with another round of Sandy Bridge hardware-related workarounds for the kernel as well. None of those were (apparently) hit by our usual code paths in Kernel, but in order to prevent possible future problems it is better to be safe than sorry on this matter.
• Jesse also came with a patch series which reworked and simplified some shared code paths in the driver, mostly related to the Display Port support and interaction with the PCH-based items (e.g., parts of the display that are based on the chipset and not on the CPU itself).
• Chris Wilson sent some patches for properly handle some Graphics interrupts corner cases, some additional debugging patches, additional LVDS-related fixes and a large number of patches that improve the way GPU rings interact between each other.
• Adam Jackson from Redhat, Rodrigo Vivi, Paulo Zanoni and Takashi Iwai from SuSE have been working on supporting new video modes that we weren’t handling properly (such as modes that are not properly described in EDID metadata that monitors report even when those modes are actually supported by them). Those patches resulted in a series of very interesting discussions about how to handle such cases as well, including all the scary terms like CVT, DMT, EDID, GTF2, GTF, and all the other WTF-like terms and all the related stuff.
• Ben Widawsky posted some patches for proper cache-level parity handling and better RC6 visibility from userspace, by using the sysfs facilities.
• Last but not least, I’ve sent out the 3rd round of Haswell enablement patches. Phoronix already did a great coverage of them in the past weeks, so as the major highlights of this new series is support of digital outputs (like HDMI and DVI), and some additional tweaks to make things work better in overall. This time, the patchbombing was of mere 29 patches thanks to Daniel Vetter who had already included around as many patches into his drm-intel-next-queued tree last week. It was an amazingly interesting experience for me to work on this hardware enablement, and it is great to see the results of this work out in the wild. And of course, I’d like to thank Jesse for helping me with most of the hardest issues I had, and Ben for his help when I got completely stuck on some of them .
• And finally, still related to the Intel Graphics but also to all the other drm-based Linux projects, Paulo Zanoni have been working on an infoframes programming tool, which was finally included into the intel-gpu-tools suite; underscan properties support and on generic CRTC properties development.

Moving to Mesa, lots of patches on all the areas as well. The most interesting ones related to the Intel GPUs that I managed to look at were:

• Eric Anholt’s work on GLSL 1.40 support and performance tuning in shaders for Intel GPUs. The GLSL 1.40 support is a big step for the open-source GL library, and it will be a very welcomed addition for the next GL versions support. And performance-related patches are always a nice thing to have .
• Ian Romanick sent the patches that rework the initial uniform handling in Mesa.
• And Neil Roberts came with some patches that improve wayland-specific Mesa code paths.

Besides those changes, we had hundreds of patches that I left out of the scope of this update. Lots of activities are going on on many Mesa-related development, and the progress of this open-source GL implementation is looking great!

On 2D driver side, lots of patches entered the xf86-video-intel project for the past weeks, mostly related to the SNA acceleration backend, but also some glyph-related fixes and other bugfixes for UXA. All of them came from Chris Wilson, who is doing an unbelievable job on the project for the past years!

On Wayland project, as usual, lots of activity was going on. Among the most interesting developments was the addition of piglit support to the project by Chad Versace, which allows to run the piglit tests under GLX, Wayland and X11/EGL while selecting the desired window system at runtime.

And finally, on a related project, Jeremy Huddleston has released the first maintenance release for xorg-server, which fixes many input-related issues together with some RandR fixes and small memory leaks.

I guess that’s it for today. Stay tuned for future updates, and enjoy the next season of The Game of Thrones meanwhile (which works amazingly well on my Intel-based card with vaapi acceleration by the way ).

With so many happenings in the past weeksˆWmonths, it is hard to know where to start. But I’ll try to cover the most relevant events which happened since the last update.

As one of the coolest things which happened in the past month, I must mention the OSTS 2012 conference. OSTS stands for Open-source Technology Summit, and it is an Intel-internal (with some guests of course, among them, naturally, Linus Torvalds himself ) event which aims at gathering all the Intel open-source developers in one amazingly beautiful place between the states of Oregon and Washington. The event takes place in Skamania Loudge, one of the most beautiful places I’ve been to, and it happened on the first week of March.

While there, I finally had a chance to discover the rest of the team in person (yeah, it is really nice to have people faces matching the names who were just voices on the phone and irc handles in the past). And, of course, it was a huge opportunity to discuss many of the projects we’ve been working on in person (alongside discussing the politics, open-source, football, french history and pretty much everything else ).

Besides technical stuff, the conference itself was amazing, and it is great that Intel organizes it and makes it such a success – I really hope to be able to attend the future iterations of it as well.

But back to the news, let me cover some of the major highlights of the Intel Linux Graphics project which we had in the past month or so.

First of all, the 2012.02 Intel Linux Graphics stack release was released, bringing a full-featured Ivy Bridge platform support on the hardware side and OpenGL 3.0 compatibility on the software one. The support for GL 3.0 is a huge leap forward for open-source graphics landscape, and I’d like to congratulate all the developers who were working on it for the past months. You did an amazing job guys, congratulations for shaping the open-source world and making it move ahead in such a great pace!

One day after the 12.02 stack release, Chris Wilson has released xf86-video-intel 2.18, featuring hundreds of new commits and improvements. But the work on the 2D driver by no means stops at this point – we already have lots and lots of new commits there, most of which are related to the SNA technology. It is still considered experimental, but at the same time it is already quite ahead of the UXA backend in many trends.

Still on the 2D support side, Chris Wilson has also released Cairo 1.11.4 and, a couple of days later, stable Cairo 1.12 version. This is the first major Cairo version in years, and it comes with an amazing set of features and performance improvements in all aspects. Check those two articles on Chris Wilson blog for some of the highlights of those releases.

Moving to the kernel project, we have an amazing number of features as well. Within a couple of hours from each other, Jesse Barnes has published his first set of patches for the Valley View support, and I’ve sent my patches for Haswell enablement. Both series of patches has already received a couple of iterations of updates, and have already been covered by phoronix reviews. Another major step towards full Open-Source support in not yet released GPUs!

Still on Kernel, Daniel Vetter has released a couple of snapshots of his drm-intel-next tree, and initial patches for the 3.4 kernel has already landed in Linus Torvald’s tree. And yet, while the next version of kernel is still taking place, we already have a a huge amount of patches getting ready for the one after it – the 3.5 one. Among those, are the logical context switching patches from Ben Widawsky, gtt handling improvements, lvds improvements, more Sandy Bridge and Ivy Bridge workarounds, improved semaphores for display plane, enablement (hopefully final) of RC6 by default for Sandy Bridge, and many many others. Things are looking great, and the development pace is amazing. I’ll try to cover more details of those patches in one of the next blog posts.

And to finish with the Kernel side of the story, Dave Airlie has managed to nail-down the long-standing issues we had while suspending, which resulted in random filesystem corruption and other nasty side effects. The patch was already sent to Linus, so things on the suspend-resume side are looking sweet again.

On Mesa side, Eric Anholt has sent the initial GLSL 1.40 patches. GLSL 1.40 is a bit different from its 1.30 counterpart in the sense that there is not much use for it outside the OpenGL 3.1, which is not there yet. Meanwhile, Mesa 8.0.2 was released, with additional bug fixes and improvements in this stable edition of it. So far, Mesa 8.0 looks very impressive, from both stability and performance point of view. Once again, amazing job guys!

Besides those news, we had thousands of new patches meanwhile, which I won’t be able to cover in this post. The development goes on and on, and so far 2012 looks quite promising for the Intel Linux Graphics project.

And, last but not least, this probably will be my last post while I have 0x1E years of age. In a couple of hours, I’ll have to go through a bit-shifting in age, coming to a very nicely looking number of 0x1F years (which looks yet more amazing in binary, being represented by a beautiful number of 0b11111). Almost coming of age by now .

As the major news, as you all already know, Mesa 8.0 was released, bringing GL 3.0 and GLSL 1.30 support combined with multitude of fixes and enhancements all over the place. For Intel i965-based graphics cards, for instance, this means a very nice boost in performance (specially on Ivy Bridge platform), lots of stability fixes and, of course, complete GL 3.0 feature set.

Besides Mesa, Kernel project was also amazingly active for the past few weeks.

• Daniel Vetter has updated his drm-intel-next tree, with a nice set of changes. Most notable of those is the support for PPGTT – which stands for Per-process Graphics Translation Table. In other words, this means that each process is able to map his own region of the GPU memory, and should not interfere with all the other ones using the GPU at the same time. This results in better performance (due to the reduced need to re-mapping addresses, and due to the fact that PPGTT entities are GPU-cacheable) and, of course, much enhanced stability.
• This new round of patches also includes a much improved interlaced modes support. These patches represent a very nice thing in our open-source community – they started with a simple request on the mailing list, which then transformed into a bugzilla entry, and after weeks of Daniel, Paulo, and many other developers working on those fixes, resulted in a amazing series of patches which greatly enhances the support for interlaced modes in Intel GPUs. This is how Open-Source community works – and this is awesome!
• Swizzling support for Sandy and Ivy Bridge architectures, which can also improve the performance for many use cases.
• Lots of bugfixes and improved debugging support.

Besides those patches, the notable patch-sets of the past weeks were:

• Ben Widawsky’s logical context switching patches. On a high-level overview of this feature, we can describe is at a feature which adds support for having a per-context set of GPU items the processes have access to. So it adds the possibility of having a different context id for each set of operations. This way, what processes in one context_id do should not affect the processes in another set. For GL_ARB_Robustness OpenGL extension, for example, it could prevent one WebGL applications from taking down all the other users of the GPU for example; and for GL_EXT_Transform_feedback it would allow each process to have a way to store its own feedback data for different stages of the pipeline – such as vertex shaders, geometry shaders, and so on.
• I have sent some patches for RC6 feature debugging, and apparently they have solved all the remaining problems with RC6 support on Sandy Bridge. So hopefully, one year after the platform launch, its remaining ghosts are finally being put to rest.

On other projects, the most notable news I managed to catch in the past weeks were some xrandr patches from Bryce Harrington from Canonical, some DRI2 enhancement patches from Mario Kleiner and input and synaptics patches from Chase Douglas on the X.org development project.

And finally, on Wayland, lots of development activity has been going on as well – most notable patches were from Ander about drag and drop icons, and patches from Juan Zhao which added support for window maximization to the core protocol.

Starting with the hot topic of the past years, Wayland 0.85 has just been released! This release marks the first milestone in the road to a stable 1.0 Wayland and Weston release. After it, we’ll have a 0.90 release, which would be the one to mark API freeze and will begin the preparation to the final 1.0 release. Of course, additional releases could happen meanwhile. Wayland has evolved a lot for the past years, so make sure to check it out.

Besides Wayland, lots of activities have been going on with all the projects.

On kernel side, Daniel Vetter has sent out his new drm-intel-next tree, which features lots of fixes from Ben, Eric and Chris, improvements to swizzling handling, fence accounting improvements, VTd workarounds for Ironlake, simplified debugfs handling code and an improved i915_error_state logging.

Besides those improvements, lots of attention was directed towards interlaced modes support on Intel GPUs, which resulted in a large series of patches from Paulo Zanoni and Daniel Vetter that should improve support for interlaced and non-interlaced modes and made them, well, work correctly . If you have been experiencing any sort of problems with such modes, please, try the patches and verify if they solve the issues. Chances are that they will, but if they won’t, please, let us know!

Among other interesting patches in kernel for the past few weeks, Ivy Bridge hard-hang fixes are among the most notable ones. Those patches toggle a couple of work-arounds for issues which randomly affected some of the Ivy Bridge machines – and resulted in complete system hangs. Due to their random nature, and specially due to the fact that they mostly affected low-resolution modes (chances to hang your machine in a 320×240 resolutions were noticeable much higher than in any other resolution), we had hard time to track them previously. In fact, we only managed to reproduce them consistently in the last week – and luckily we were able to come with patches which apparently fixed most of the problems. The patches will probably be included into 3.3 kernel via the drm-intel-fixes branch, and if they won’t cause any other issues we’ll backport them to 3.2 kernel as well.

Another interesting patch is the one which applies the missed IRQ fix (a.k.a., the voodoo patch ) to Sandy Bridge platform as well. So far, we had a couple of reports which mentioned that a very similar issue to the one which was fixed on Ivy Bridge last month was happening on Sandy Bridge as well. If you are suffering from this issue, please, give it a try and let us know if it solved the issue to you or transformed it into anything else (like a GPU hang which happened on one of the machines instead of missed IRQ. Those results would be even more interesting, as they could tell us what we are missing and how to fix the problem for good).

Additionally, lots of development was targeted on improving the semaphores issues detection and avoidance, and for better debugging support in the i915_error_state log. Usually, this log is all that remains of a GPU hang – so the more information we can get from there, the better.

And finally, aiming at finally discovering what root-causes all the rc6 issues out there, I sent out a patch which allows to hopefully isolate the issue. Leann Ogasawara from Canonical was also kind enough to pre-build Ubuntu kernels with this patch – so if you are affected by a RC6 issue, and are running Ubuntu – please, give them a try!!

On Mesa side, things are moving very quickly towards the Mesa 8.0 release. The 8.0-RC2 version was already released, and final 8.0 version is expected to happen in a very near future. Who knows, perhaps by the time you’ll be reading this line, it will already be among us . Mesa 8.0 release looks very exciting so far – besides the GL 3.0 extensions and GLSL 1.30 support, it also brings amazing performance and stability improvements. Hopefully you’ll be able to see it with your own eyes when the next stable release will be out – or, if you don’t want to wait that long, or want to use your very last chance to report any major show-stopper bugs in the 8.0 branch – now is the time.

On the xf86-video-intel side, as usual, hundreds of patches were committed by Chris Wilson, mostly targeting the SNA backend, and also the Glamor integration. Since the beginning of the year, git log already shows 380 new patches. Out of those, 368 are SNA-specific for now. Phoronix has run yet another round of SNA testing in the past weeks with some interesting results. Things are getting very interested with this backend.

And finally, moving to the intel-gpu-tools project, two new tools were proposed in the past few days – one for testing different panel fitter settings (intel_panel_fitter, from Paulo Zanoni); and another to demonstrate the sprite features, available for SNB/IVB platform, which uses 3 new IOCTLs included in the latest drm subsystem: GETPLANERESOURCES, GETPLANE, and SETPLANE. Planes and sprites support are ones of the latest additions to the core drm subsystem, and in my opinion they certainly are among the most interesting items there. I believe that more and more applications will be using them at some point (like the 1st one mentioned in this post – yes, the one which starts with ‘W‘), which is great.

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.

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.

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 .

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!

Somewhere on the road to curitiba, starting 2011....

For me, 2011 was extremely busy, exhausting but also very fruitful. I started it in a completely different situation from 2010, when I was a mere developer in Mandriva company. And during the course of 2010 and, later, 2011, I got the chance to work as engineering team leader for Conectiva, then development manager and, finally, technical diretor for Mandriva. And, after this experience, I got to move into Intel, working with even more challenging and amazing projects.

So yes, it was a hugely crazy and great experience. Thank you 2011 – despite all the problems and obstacles, you was great after all if we sum up everything.

See you all in 2012!

So starting with the coolest news – the Mesa team is getting close to the GL 3.0 milestone! Yeah, with latest GL_ext_transform_feedback patches from Paul Berry, the last major piece of GL 3.0 spec is getting into place. There are still some extensions missing and lots of smaller tasks to be done, but it is possible to say that we are almost there. I think that this is really exciting for both us, and for all the Linux and open-source users in the world – so yeah – we’ve been good boys and girls during the year and Santa Claus gift has materialized itself in form of almost-full GL 3.0 support in Mesa.

Who knows, maybe prior to the Chinese new year we’ll receive the 2nd part of this gift (in other words, mesa 8.0 release ).

On kernel side, the 3.2-rc6 release brought lots of awesome changes to our drivers. Yes, I am talking about everyone’s favorite rc6 and semaphores features. They are on by default on Ivy Bridge architecture, and are also enabled on Sandy Bridge if VTd is disabled. So most of you should enjoy greatly improved battery life, considerable faster performance and also enhanced stability within the i915 driver when Linux 3.2 will be released.

Besides those patches, work has started on collecting patches for the 3.3 merge window. Daniel Vetter sent his pending patches in a form of tiny 43-patches series. Those patches bring PPGTT support, improve debugfs handling, enhance pread/pwrite performance, fix swizzling for SNB/IVB, improve forcewake operations and enhance debugging support for cases when GPU rings get stuck.

Ben has also sent his patches for scheduling/throttling, but they haven’t received much interest except from myself and phoronix . Those patches add support for more fine-grained GPU scheduling and rings load distribution between individual process. I am really interested in this work, and I hope that they will be accepted into the main kernel in the foreseeable future.

Also on kernel, Rodrigo Vivi and Paulo Zanoni sent out some patches which finally fix some corner cases for TV-out and SDVO outputs. This certainly should make many users happy out there just in time for Christmas.

And finally, for the kernel size, Chris Wilson came with a patch which works around the missed IRQs issues on Ivy Bridge platform. With this patch, and with semaphores being enabled on Ivy Bridge by default, I am very happy to say that we don’t have any blocking bugs for Ivy Bridge in our bugzilla. I think that it comes as a nice Christmas gift for all the users out there (the ones who already have an Ivy Bridge machine, and the ones who will get it by its launch – which is still 4 months away). Of course, I won’t talk much about it prior to its official launch, but trust me – Ivy Bridge rocks!. I can’t wait to have an Ultrabook based on this platform for myself…

Besides mesa and kernel, it is worth mentioning that on the 2D side, Zhigang added full Glamor support into the driver. The Glamor acceleration is still considered very experimental and non-stable, but now it is available for the world to take a peek on it and witness how it works with their own eyes.

So I think that this is pretty much it. We have hundreds of patches floating around for all the projects, thousands of emails and millions of users in the world – and we are working hard to make all of them happy with the results of our work. 2011 was extremely productive and rewarding for us – and I hope that the year of 11111011100 (a.k.a., 0x7DC or 2012_base10 for the ones still reading in decimal numbers out there ) will be even more interesting*!

See you!

(*) Assuming the world won’t end in a core dump caused by the Mayan millennium counter overflow bug .

The focus of this release was on performance and stability improvements in the drivers, and I think we managed to get the job done according to what we expected. Thanks to LLC caching and improvements in both Kernel and Mesa, 3D performance was improved by a large margin on Sandy Bridge generation of GPUs onwards, and many annoying issues were fixed as well (with some of the fixes already queued for Kernel 3.2 release). And I’d also like to highlight lots of work towards GLES compliance on Sandy Bridge architecture, and many and many different stability fixes in all the projects.

For statistical purposes, my saved bugzilla searches count 253 bug reports which were closed after the previous release, and we had 594 bug tickets in total which had any activity since that release. Of course, this does not represents what was done by an accurate number, so please, just use those numbers as some sort of bugzilla pondering references.

So to sum it all up, I’d like to thank all the developers, QA, users, testers, and all the community we have around Intel Linux Graphics project for your amazing work. Yes, the Intel Linux Graphics project has not only a team within Intel – but also a huge community and users all around the world, following the Open-Source road from Kernel up to the UI components. Thank you all guys!

Enjoy!

For the Kernel side, some nice patch series have arrived to the list:

• Daniel Vetter sent his PPGTT enabling patches, which resulted in many interesting reviews and discussions. PPGTT, or Per-Process Graphics Translation Table, is a mechanism for remapping GPU memory into system one. Unlike traditional Graphics Translation Table, which has a global mapping for everything, PPGTT allows each process to have its own level of mapping. On practice, it should improve stability by a large margin and performance by a considerable value, and also is a nice thing to have in general, specially when hardware supports it natively (which it does, starting with Sandy Bridge). Also, if you are interested in learning the details of how GTT and GPU memory management works, you should check this excellent article from 2007 for a great introduction.
• Ben Widawsky has sent a new series of patches for forced GPU throttling and scheduling. I already described them in one of the previous posts, and I am really interested in seeing them accepted to the kernel.
• I’ve sent out some patches for userspace-controled RC6 enabling and tweaking, together with some patches for enabling semaphores and rc6 by default on newer generations of gfx hardware. Those patches, together with Ben’s ones, also raised an interesting point – we have many userspace-controllable items in the debugfs file system, which should probably belong to sysfs instead. This would require a proper definition of their usage and behavior before real userspace applications would be able to use them.
• And Wu Fengguang sent some patches for Display Port and HDMI fixes.

Moving up the stack to the 3D driver, some major news worth highlighting are:

• On Mesa side, the major news is Ian has released Mesa 7.11.2 with some additional GLES and EGL patches, and a small patch which fixed Mesa build on Mandriva (and also on other distributions which use -Werror by default, such as Mageia for example).
• Lots of work is happening in Mesa, targeting OpenGL 3.0 support by the end of the year. GLSL 1.30 is already among us, and most of GL 3.0-required extensions are in place, but there are many things to do. Hopefully they will be all done in the next few weeks.
• Speaking on Mesa, some major news happened for the drivers using the Gallium technology. As you probably heard through Phoronix already, the i965g, Cell and Failover gallium-based drivers were dropped from Mesa due to lack of love, support and care. Sad – but this is life. And in any case, i915g driver is still there, and of course, those events do not affect Intel’s 915 and 965 Mesa drivers at all.
• And also on Mesa, Ian has started the work on GLX_ARB_create_context and the layered GLX_ARB_create_context_profile extension, and came with a question whether it is still worthy to support non-XCB protocol, or if there are any platforms that can’t / don’t use XCB for X protocol yet. The overall feedback so far was to drop non-XCB bits sooner than later. So looks like XCB has won the X protocol war in the end .

And finally, on the xserver side, discussions were raised on the mailing list on the release dates for the next xserver release, and the Xinput 2.2 state in it. It is almost there, and will probably get merged until Christmas. Also, Xorg-server 1.11.2.901 (a.k.a., 1.11.3-RC2) was released.

Speaking about it, it was actually the first LinuxCon I attended (I also went to LinuxWorld Brazil in 2006, but that’s pretty much all the Linux-specific events I’ve been to). So it was really nice to talk to all the people I know from the Internet and put some faces behind the irc nicks and email handles. It was also really nice to meet and talk to Linus, Dirk Hohndel and Lennart Poettering in person, and meet old ex-conectiva people from all over the world.

It was also particularly nice to meet and talk to Christian Reis (a.k.a., Kiko), who is the VP of Engineering at Linaro now. He used to study with me at UFSCar university more than a decade ago and we met on a couple of events at São Carlos previously. He did a very interesting keynote about the state of ARM on Linux at the beginning of the conference, and we talked a lot about GFX drivers on Linux afterwards.

As for my presentation, I’d like to thank you all for attending and asking interesting and technical questions. We actually managed to have a mini real-time debugging session on some lvds issues at the end of the presentation .

And of course, I managed to announce that Mesa 7.11.1 was going to be released about 5 minutes before Ian sent his email – it happened right during my presentation actually . And so.. I spoke of mesa, so yeah, let’s head back to the Intel Linux Graphics news now.

As you all know, Mesa 7.11.1 was released this week. It comes with an absolutely amazing number of 200+ backported patches for performance and stability enhancements in pretty much all the components we have. It is not the last release of the 7.11 branch, so you should expect some more releases in the next couple of months. And perhaps some more even after Mesa 8.0 will be released.

On Kernel side, lots of things happened this week. Linus has released Linux 3.2-rc2 (and also blogged about it in his google+ page while fighting the amazingly fast brazilian 3g connection issues ). It comes with many patches and fixes, for both Intel and non-Intel gfx cards. There is still many patches to get into the 3.2 branch though.

Also, I sent out some patches for once again enabling RC6 and Semaphores by default, but after a discussion on intel-gfx mailing lists I got some ideas on reworking them. And Keith Packard has also sent a rc6-enabling patch earlier today, which probably will fix all the RC6 issues and allow it to enter the kernel. This is the 5th attempt on enabling it by default as far as I remember, so I hope it will get in this time.

On xf86-video-intel, Chris Wilson has released the 2.17 version of the 2D driver, which comes with a large number of fixes for the UXA acceleration. Besides UXA, it also comes with more than 300 patches for SNA – so if you are using it, you really should update. Trust me, you really want to do it .

Still on Kernel, as many of you know, the latest Bios update to the Ivy Bridge bios somewhat broke suspend-resume for IVB machines out there. Keith Packard and Jesse Barnes had already sent some patches to address that, so if you one of the lucky ones out there with an Ivy Bridge, and you do have this issue – please, test it and let us know if it works!

On Mesa side, besides the 7.11.1 release, lots and lots of work is going on to finish GL 3.0 support. Among around a thousand of mails and commits on the mesa-dev list, it is hard to highlight the most important ones, but I’d like to give attention to the Chad Versace‘s patches which bring the HiZ support and enable it by default, and to Paul Berry‘s work on GLSL 1.30.

But besides those, yes, there is a huge number of amazing changes on pretty much everything, with some interesting changes from Eric, Kenneth, Chad, Yuanhan and Ian. Mesa 8.0 ought to be an exciting release!

So that’s it for today. See you!

(of course, if you have attended and want to see it again, you can do this too ).

Have fun!

Intel Linux Graphics

But as I said, heck, it is Friday, and we all have a nice binary date on the calendar, so I’ll give you two additional reasons for celebration today:

• On Mesa, Eric Anholt and Ian Romanick exposed GLSL 1.30 compatibility for Intel gen6+ cards. Yes, with the latest commit which added gl_VertexID support, everything required by GLSL spec should be supported now. Yet another milestone towards GL 3.0 was passed.

• And on xf86-video-intel, patches which add the support for Glamor were sent by Zhigang. Yes, I am talking a lot about Glamor in the past days, as it certainly looks like a very interesting project. Now, with patches which split the device-independent library from the device-dependent part, its support towards upstreaming is getting closer and closer.

Besides those items, as usual, we have had lots of development and news for all the projects. And next week, we’ll have LinuxCon in Brazil, where I’ll give a presentation about Intel Linux Graphics, what it is, how it works, and what are all those scary words like kernel, drm, ddx, vaapi and wayland. And, of course, we’ll have lots of amazing presentations on many Linux-related projects.

So if you’ll be there, I’ll be glad to answer your questions and talk about pretty much everything.

See you!

So if you were sad, depressed and crying in despair without having a chance of reading about what was going on with the Intel Graphics for the past days, rejoice!

Those past few days were quite busy on all the projects, and with thousands of emails to keep track of it is hard to select the most relevant news – all of them are! But I’ll try to summarize the most interesting stuff that happened for the past few days.

Starting with kernel, as you all already know, we are living in the post-3.1 era now, with the release of Linux 3.2-rc1. It brings lots and lots of fixes and improvements all around, and much more are yet to come.

On Intel Graphics side, the following items caught my attention for the past days:

• Keith Packard sent yet more eDP-related patches, allowing eDP displays connected to the PCH to, well, work . The main issue came from the fact that the driver incorrectly was treating a PCH-connected eDP panel like a CPU-connected one, setting the wrong bits in the wrong places.
• Daniel Vetter has sent out a series of patches for simulating GPU hangs. As you all know, GPU hangs are an (unfortunate) part of a GPU driver life, and there are many factors which could cause them, ranging from incorrect GL instructions to out-of-bounds variables somewhere in the stream of commands and down to hardware failures. Prior to Daniel’s patches, the only way to see a GPU hang was by having a hung GPU, so most of them were not easy to reproduce and investigate. Now, it is possible to stop the GPU at will, and see the effects. This is particularly interesting at least for me, because I was working on some tools for doing heuristics analysis of the root-causes of GPU hangs. Now, I can do this task with much more ease.
• Jesse Barnes sent out a new round of planes support, and support for SNB and IVB video sprites. The video sprites support different video formats natively and can do scaling as well, and their support was added to the DRM overlay code with this patchset.
• Ken and Daniel did a bit of cleanup of code specific to some pre-production SNB systems. Now that Sandy Bridge is out there, those bits are not necessary anymore, so they were wiped out.
• Daniel has sent a 13-patch series of pwrite/pread reworking. This patchset fixes some spurious -EFAULTS issues which could lead to kernel issues, improves the performance of pread/pwrite calls on LLC machines and cleanups unused code, replacing them with faster execution paths.
• Also on kernel, I’ve found an issue which can cause division-by-zero in kernel when accessing power-related registers from userspace, and sent a small patch fixing it. Apparently, the very same issue was already found back in July by Konstantin Belousov. It is a small fix for a potential kernel crashing issue, and let’s hope it will be picked up in one of the next kernel pull requests.
• And Jesse Barnes sent out some documentation and cleanup patches for the drm subsystem.
• Still on kernel, but outside of our team’s area, one big news for Linux Graphics will certainly make some people out there happy. Yes, I am speaking about Alan Cox moving of basic GMA500 driver out of staging. This driver support accelerated console and non-accelerated KMS on Poulsbo, Oaktrail, Cedarview and Medfield hardware. Note that medfield support in this initial patchset is left out on purpose, as it needs considerable rework to be ready to enter main kernel.

One particular issue worth highlighting is that a long-standing issue on GL-based applications (among which Unigine Tropics and Sanctuary are probably the most notable examples, among many others) was finally fixed, thanks to an amazing work by Eric Anholt, Kenneth Graunke and Keith Packard. This issue can be described as ‘small moving ants on top of image edges’ or ‘flickering pixels‘. So if you have had this issue, make sure to check out the patches!

Going to Mesa, out of hundreds of emails and commits, it is hard to choose the most interesting ones. Work on GL 3.0 support proceeds quickly, and new mesa stability release, 7.11.1 is almost out of the door. Our Q&A team did a full testing of this bugfixing release, and haven’t found much issues. So prepare yourself, as in few weeks we’ll have MESA 7.11.1 out there. Stay tuned for Ian’s announcement in nearby future.

But as for mesa master branch, the following patches called my attention the most:

• Eric sent a patch series to add support for GL_EXT_texture_integer on i965 driver.
• More work towards EXT_transform_feedback was done by Dan McCabe and Paul Berry, and Marek from the community side.
• And we had lots of fixes for potential segmentation faults, safety checks, better hardware specification compatibility, piglit-based fixes and other issues from Yuanhan, Eric, Ken, Chad and Ian.

On Wayland side of the force, lots of patches went in those days. Among those, there was an interesting proposal for the screen locking protocol by Pekka Paalanen, and some bugfixing patches from Juan Zhao.

Going to the other components, we had a release of xorg-xserver 1.11.2 RC2, with several crashes and correctness fixes; and new stable pixman 0.24.0 which brings many performance improvements and usage of architecture-specific instructions to improve overall performance over a number of different operations (such as bilinear scaling for example).

And finally, for the intel-gpu-tools, I was working on a new intel_gpu_analyze application, which I was using to tracing and analyzing CPU and GPU performance data during workloads, and also checking on the corresponding power consumption. This is a very experimental code yet, and it lives at my freedesktop.org git for now. But still, I can already do some nice performance analysis like this one.

It took me longer than I originally expected to write this next post in the series due to some personal problems which kept me out of the virtual world for quite some time, but better late then never.

So, starting with Kernel, as usual, we had lots of updates.

• Jesse Barnes sent out his patches for adding DRM planes and support for a new FB creation ioctl. Planes are similar to half-CRTCs, in the sense that they have a location and fb, but don’t drive outputs directly. His patchset provided two new interfaces: addfb2, a new FB creation ioctl that lets specify a surface format, as defined by a fourcc code from the video4linux headers; and ** planes – ioctls for fetching plane info and attaching an fb to a plane.
• Jesse has also proposed some patches for enabling video sprites via overlays.
• Keith Packard has prepared some patches for flicker-free boot, which attempts to avoid the initial modesetting in drm.
• A very interesting set of patches from Ben which attempt at adding fairness to GPU scheduling, preventing greedy apps from over-dominating the GPU and leaving nothing for other apps. This, of course, is still experimental, but think about this like on what CFS scheduler did to Linux Process Scheduling, and CFQ did to I/O scheduling. Of course, this also raises some concerns, like for example what should happen to benchmarks – which expect to grab all the possible power to get some measurable numbers, but nothing unsolvable here. It would be really interesting to see how it will go.
• Ben has also sent out some patches which attempt to fix recursive unmapping of pages, a side effect of the Ironlake workaround which was done recently.

For Mesa, lots of activities on all fronts too. I won’t be able to cover all of them, but the main highlights of the past days were:

• Work on EXT_transform_feedback by Dan McCabe and Paul Berry from Intel and Marek Olsak. The piglit tests are already in place for some months (I actually started to work on some of them, but then Marek has published his own set of tests, and I left mine in a half-finished state for now at my freedesktop.org personal repo. But I think I’ll finish them at some point). The mesa support for this GL 3.0 extension is approaching its completeness fairly quickly.
• A 33-patch series from Eric Anholt with lots of fixes for batch buffer handling within mesa.
• Lots of different fixes and consistency improvements for Gen6 and Gen7 generations of cards from Ken were also unleashed into the wild.
• A HUGE cleanup of the remaining DRI1 pieces, such as the radeon drivers, dri1-specific extensions and core mesa bits, was carried out by Kristian Høgsberg, Eric and many others who participated in the discussion.
• GLSL and extensions-related work continues, with clean-ups, fixes and improvements from Ian, Ken, Paul Berry and Chad.
• GL_ARB_texture_storage support was brought in by Brian Paul from VMware. It is supported by gallium drivers and swrast for now.
• Chad Versace sent more patches for the Stencil buffer and HiZ support.
• Ian sent out a 20-patch series which completely refactors the handling of uniforms within Mesa.
• Eric has sent 24-patch series for improved renderbuffer mapping (MapRenderbuffer).
• Paul Berry has added support for GLSL 1.30 interpolation qualifiers for Gen6+. This allows to keep track of which fragment shader inputs are overridden with the GLSL “flat”, “smooth”, “perspective” and “noperspective” interpolation qualifiers.
• And Chia-I Wu has sent some new patches for an updated version of glext.h and for improved android-x86 support within core Mesa.

On Wayland land, we also had quite some interesting changes:

• Tiago Vignatti sent several patches for improving input and evdev handling.
• Juan Zhao has put out some documentation about Wayland building.
• Ander, me, Benjamin Franzke, Casey Dahlin, Pekka Paalanen and Juan Zhao has also sent some build, correctness and GL-related patches. In overall, Wayland development is moving on nicely.

Moving to VAAPI, as I already wrote here, Gwenole has released a new version of both libva and vaapi-driver-intel. Also, speaking on new releases, Eric Anholt has also released libdrm 2.4.27, we had the release of xorg-server 1.11.2 RC2, a new pixman 0.23.8 release, which happens to be a release candidate for the stable 0.24 release, and Chris Wilson has put out xf86-video-intel 2.17 RC1, with several fixes and amazing list of 200+ SNA-related patches.

Also on SNA, I’ve put out two patches which would allow to activate SNA by means of a config file option, without recompiling. Those patches patches are floating around the intel-gfx mailing list, and make the task of SNA testing amazingly more easy (at least, for me ).

So – I guess I’ll stop here for now.

See you in the next iteration of The Tales from the Crypt Intel Linux Graphics land .

I am glad to bring you the good news – Gwenole has just releases libva and vaapi-driver-intel version 1.0.15 into the wild! Go ahead and grab them here and here!

And now for the nice details of what you should expect from those releases.

Vaapi-driver-intel

This release improves the VC-1 and MPEG-2 decoding, and fixes some memory leaks:

• Fix VC-1 decoding (TTFRM packing)
• Fix MPEG-2 decoding on Ivy Bridge
• Fix MPEG-2 decoding with sparse QM matrices updates
• Fix slice-param & slice-data buffer memory leaks

Libva

This release moves the i965 driver into its own subdirectory, improves packaging support and build issues, and comes with some miscellaneous fixes.

• API: make {Top,Bottom}FieldOrderCnt signed (Yi Wang)
• Add auto-generated Debian packaging
• Refine VA trace & VA fool utilities
• Move i965 driver to a specific repository (vaapi/intel-driver)
• Fix DSO link issue in tests
• Fix fglrx driver name detection
• Fix API vs. DSO vs. package versioning

As you can see, this is a bugfix-mostly release. Next step is 1.0.16, which will bring some nice features to you in nearby future.

As always, stay tuned .

His testing confirms what I was pointing out with my latest series of the post (however, it always feels great to have independent confirmation of the results). For performance numbers, kernel 3.1 brings around +20% to +40% improvements on top of the previous release for Sandy Bridge architecture. Yeah, this is nice. So if you haven’t updated your kernel to the latest and greatest one (in other words, kernel 3.1), you should really consider doing this.

As for power numbers, we have some good news too. The default kernel power usage on 3.1 is mostly similar to 3.0, with some small variations here and there. However, if one enables RC6 support, the immediate results is that your power usage drops by up to 40% on idle. It is really nice to see less than two-digit watts numbers on current generation of desktop hardware (while it is pretty common to see it on Atom CPUs for some time already, desktop and mobile versions of Intel cards were not that used to such numbers – yet).

One additional bonus Michael has found out is pretty much more interesting one. Apparently, by enabling RC6, the graphics-intensive applications get an additional performance boost of up to 10%. This was a bit unexpected for me, but it is better to have good surprises than bad ones.

From what we have discussed with Jesse Barnes, such improvements could come from several different paths. The first explanation is that, with RC6 enabled, the graphical card can actually consume much less power (down to 0V), so it leaves more room for CPU to use the non-claimed power to do more processing of its own. And the second one is that, thanks to additional thermal bonus which we get from the RC6-provided power economy, the GPU frequency has more room for scaling. So effectively, in both of those case, RC6 allows you to have a better performance, both CPU and GPU-wise – at a cost of somewhat higher power usage coming from such performance.

So, in few words, I would define this situation as battery when you want, performance when you need. When you are on battery, under mostly idle workload (for example, browsing or reading or writing some blog posts), your battery lasts much longer. And when you start some processing-intensive application (say, openarena or angry birds), it gets more horsepower to get the job done, and some extra FPS which could mean life or death – which is specially true in case of said workloads . Of course, those additional horses are hungry, so this incurs in more power being used when such additional performance is there – but it is something to be expected in any case.

While writing this description, I actually came to realize that the feature known as GPU turbo, which is present on Intel graphics cards, could be used to define and control such behavior on a much finer granularity. From what I’ve searched all around, surprisingly, nobody seems to have covered its functionality yet. I guess I’ll try to cover how it works, and how one could use and control it from userspace in one of the next posts, so stay tuned! And meanwhile, enjoy all those nice power and performance-related bonuses which the Intel Linux Graphics team brought to you just in time for Halloween .

I tried to summarize all the patches and changes which went to this kernel release which somehow affected the drivers/gpu/drm/i915 directory (and, therefore, the kernel part of our driver).

To give proper credit to all the authors whose code was accepted into the official kernel between the 3.0.0 and 3.1 release, here is the full list:

• Adam Jackson: drm/i915/dp: Better hexdump of DPCD
• Adam Jackson: drm/i915/dp: Don’t turn CPT DP ports on too early
• Adam Jackson: drm/i915/dp: Explicitly disable symbol scrambling while training
• Adam Jackson: drm/i915/dp: Explicitly request 8/10 channel coding
• Adam Jackson: drm/i915/dp: Move DPCD dump to common code instead of PCH-only
• Adam Jackson: drm/i915/dp: Read more DPCD registers on connection probe
• Adam Jackson: drm/i915/dp: Retry DPCD fetch on G4X too
• Adam Jackson: drm/i915/dp: Zero the DPCD data before connection probe
• Adam Jackson: drm/i915/pch: Fix integer math bugs in panel fitting
• Adam Jackson: drm/i915/pch: Save/restore PCH_PORT_HOTPLUG across suspend
• Ben Widawsky: drm/i915: add module parameter compiler hints
• Ben Widawsky: drm/i915: hangcheck disable parameter
• Ben Widawsky: drm/i915: provide module parameter description
• Chris Wilson: drm/i915: Add an interface to dynamically change the cache level
• Chris Wilson: drm/i915/bios: Avoid temporary allocation whilst searching for downclock
• Chris Wilson: drm/i915: Cache GT fifo count for SandyBridge
• Chris Wilson: drm/i915: Combine pinning with setting to the display plane
• Chris Wilson: drm/i915: Disable FBC across page-flipping
• Chris Wilson: drm/i915/gtt: Split out i915_gem_gtt_rebind_object()
• Chris Wilson: drm/i915: Introduce i915_gem_object_finish_gpu()
• Chris Wilson: drm/i915: Introduce i915_gem_object_finish_gtt()
• Chris Wilson: drm/i915: Mark the cursor and the overlay as being part of the display planes
• Chris Wilson: drm/i915: Only export the generic intel_disable_fbc() interface
• Chris Wilson: drm/i915: Perform intel_enable_fbc() from a delayed task
• Chris Wilson: drm/i915: Remove vestigial pitch from post-gen2 FBC control routines
• Chris Wilson: drm/i915: Replace direct calls to vfunc.disable_fbc with intel_disable_fbc()
• Chris Wilson: drm/i915: Set persistent-mode for ILK/SNB framebuffer compression
• Chris Wilson: drm/i915: Share the common work of disabling active FBC before updating
• Chris Wilson: drm/i915: Use of a CPU fence is mandatory to update FBC regions upon CPU writes
• Dave Airlie: Revert “drm/i915: Try enabling RC6 by default (again)”
• Eric Anholt: drm/i915: Use the LLC mode on gen6 for everything but display.
• Eric Anholt: drm/i915: Use the uncached domain for the display planes
• Hugh Dickins: drm/i915: more struct_mutex locking
• Jesse Barnes: drm/i915: add GPU max frequency control file
• Jesse Barnes: drm/i915: allow cache sharing policy control
• Jesse Barnes: drm/i915: apply phase pointer override on SNB+ too
• Jesse Barnes: drm/i915: apply timing generator bug workaround on CPT and PPT
• Jesse Barnes: drm/i915: check for supported depth at fb init time
• Jesse Barnes: drm/i915: don’t set SDVO color range on ILK+
• Jesse Barnes: drm/i915: don’t set transcoder bpc on CougarPoint
• Jesse Barnes: drm/i915: don’t use uninitialized EDID bpc values when picking pipe bpp
• Jesse Barnes: drm/i915/dp: wait for previous AUX channel activity to clear
• Jesse Barnes: drm/i915: enable ring freq scaling, RC6 and graphics turbo on Ivy Bridge v3
• Jesse Barnes: drm/i915: fix CB tuning check for ILK+
• Jesse Barnes: drm/i915: flush plane control changes on ILK+ as well
• Jesse Barnes: drm/i915/hdmi: HDMI source product description infoframe support
• Jesse Barnes: drm/i915/hdmi: send AVI info frames on ILK+ as well
• Jesse Barnes: drm/i915/hdmi: split infoframe setting from infoframe type code
• Jesse Barnes: drm/i915: load a ring frequency scaling table v3
• Jesse Barnes: drm/i915: load the LUT before pipe enable on ILK+
• Jesse Barnes: drm/i915: provide more error output when mode sets fail
• Jesse Barnes: drm/i915: provide more error output when mode sets fail
• Jesse Barnes: drm/i915: set bpc for DP transcoder
• Jesse Barnes: drm/i915: set GFX_MODE to pre-Ivybridge default value even on Ivybridge
• Jesse Barnes: drm/i915: show interrupt info on IVB
• Jesse Barnes: drm/i915: split out Ironlake pipe bpp picking code
• Jesse Barnes: drm/i915: split out PCH refclk update code
• Jesse Barnes: drm/i915: split out plane update code
• Jesse Barnes: drm/i915: use pipe bpp in DP link bandwidth calculation
• Jesse Barnes: drm/i915: use pipe bpp in DP link bandwidth calculations
• Jesse Barnes: drm/i915: use pipe bpp when setting HDMI bpc
• Kamal Mostafa: i915: do not setup intel_backlight twice
• Keith Packard: drm/i915: Call intel_enable_plane from i9xx_crtc_mode_set (again)
• Keith Packard: drm/i915: Cannot set clock gating under UMS
• Keith Packard: drm/i915: Can’t do accurate vblank timestamps with UMS
• Keith Packard: drm/i915: DP_PIPE_ENABLED must check transcoder on CPT
• Keith Packard: drm/i915: Enable dither whenever display bpc < frame buffer bpc
• Keith Packard: drm/i915: Enable i915 frame buffer compression by default
• Keith Packard: drm/i915: FBC off for ironlake and older, otherwise on by default
• Keith Packard: drm/i915: Fix PCH port pipe select in CPT disable paths
• Keith Packard: drm/i915: Fixup for ‘Hold mode_config->mutex during hotplug’
• Keith Packard: drm/i915: Flush other plane register writes
• Keith Packard: drm/i915: Hold mode_config->mutex during hotplug processing
• Keith Packard: drm/i915: i915_gem_object_finish_gtt must always release gtt mmap
• Keith Packard: drm/i915: Ignore GPU wedged errors while pinning scanout buffers
• Keith Packard: drm/i915: In intel_dp_init, replace read of DPCD with intel_dp_get_dpcd
• Keith Packard: drm/i915: Initialize RCS ring status page address in intel_render_ring_init_dri
• Keith Packard: drm/i915: Leave LVDS registers unlocked
• Keith Packard: drm/i915: Remove unused ‘reg’ argument to dp_pipe_enabled
• Keith Packard: drm/i915: Rename i915_dp_detect_common to intel_dp_get_dpcd
• Keith Packard: drm/i915: Select correct pipe during TV detect
• Keith Packard: drm/i915: Set crtc DPMS mode to ON in intel_crtc_mode_set
• Keith Packard: drm/i915: Skip GPU wait for scanout pin while wedged
• Keith Packard: drm/i915: Try enabling RC6 by default (again)
• Keith Packard: drm/i915: TVDAC_STATE_CHG does not indicate successful load-detect
• Keith Packard: drm/i915: Use dp_detect_common in hotplug helper function
• Keith Packard: drm/i915: Wait for LVDS panel power sequence
• Keith Packard: Revert and fix “drm/i915/dp: remove DPMS mode tracking from DP”
• Keith Packard: Revert “drm/i915/dp: Zero the DPCD data before connection probe”
• Matthew Garrett: i915: Fix opregion notifications
• Matthew Garrett: Not all systems expose a firmware or platform mechanism for changing the backlight intensity on i915, so add native driver support.
• Michel Alexandre Salim: drm/i915: Add quirk to disable SSC on Sony Vaio Y2
• Pieterjan Camerlynck: i915: add Dell OptiPlex FX170 to intel_no_lvds
• Simon Farnsworth: drm/i915: Enable SDVO hotplug interrupts for HDMI and DVI
• Thomas Jarosch: drm/i915: Fix wrong initializer for “locked” variable in assert_panel_unlocked

If we count the final number of changes between the 3.0 and 3.1 versions, we come to the following results:

drivers/gpu/drm/i915/i915_debugfs.c     |  232 +++++++-
drivers/gpu/drm/i915/i915_dma.c         |   10 +-
drivers/gpu/drm/i915/i915_drv.c         |   69 ++-
drivers/gpu/drm/i915/i915_drv.h         |   51 +-
drivers/gpu/drm/i915/i915_gem.c         |  193 +++++-
drivers/gpu/drm/i915/i915_gem_gtt.c     |   39 +-
drivers/gpu/drm/i915/i915_irq.c         |   22 +-
drivers/gpu/drm/i915/i915_reg.h         |   59 ++-
drivers/gpu/drm/i915/i915_suspend.c     |   13 +-
drivers/gpu/drm/i915/intel_bios.c       |  140 +++--
drivers/gpu/drm/i915/intel_display.c    | 1028 +++++++++++++++++++++++--------
drivers/gpu/drm/i915/intel_dp.c         |  135 +++--
drivers/gpu/drm/i915/intel_drv.h        |   38 +-
drivers/gpu/drm/i915/intel_hdmi.c       |  166 +++++-
drivers/gpu/drm/i915/intel_lvds.c       |   90 ++--
drivers/gpu/drm/i915/intel_opregion.c   |   16 +-
drivers/gpu/drm/i915/intel_overlay.c    |    6 +-
drivers/gpu/drm/i915/intel_panel.c      |   76 +++-
drivers/gpu/drm/i915/intel_ringbuffer.c |   13 +-
drivers/gpu/drm/i915/intel_sdvo.c       |   88 +--
drivers/gpu/drm/i915/intel_tv.c         |   46 +-
21 files changed, 1879 insertions(+), 651 deletions(-)

So, in sum, there are changes all around the driver. Among the most interesting ones (in my humble opinion), are:

• Frame Buffer Compression is now enabled for Gen6 onwards (in other words, starting with Sandy Bridge). Of course, you can always enable it manually on your machine as well by using the i915.i915_enable_fbc=1 kernel parameter.
• FBC should work better in general, thanks to patches from Chris Wilson which disable it across page-flipping and before updating, persist framebuffer compression mode for Ironlake and Sandy Bridge, and also making a proper use of fences after CPU writes.
• RC6 was attempted to be enabled, but it was reverted early in the development cycle. As we had unusual time frame for this kernel release, by the time we have hit RC8, all the remaining RC6-related issues were tracked down. But as it was already too late for kernel 3.1, its enablement by default should happen in kernel 3.2. The usage of RC6 brings amazing power usage benefits, so you can enable it by yourself via the i915.i915_enable_rc6=1 kernel parameter – and letting us know about any non-covered issues it may bring.
• DCPD, or Display Port Configuration Data handling has received lots of attention, and in general one should have a much better support for Display Port outputs.
• configuration parameters for changing the cache level, maximum GPU frequency, cache sharing policy and GPU ring frequency scaling.
• additional debugging output when mode setting fails, information about interrupts on Ivy bridge, hangcheck disabling support and better DPCD hexdump.
• improvements for HDMI support, SDVO and LVDS handling, better pipe handling of EDID bpc values and proper panel fitting calculationsl
• usage of LLC mode (usage of CPU cache for GPU instructions) for Gen6. This one-lined (excluding comments ) change alone was responsible for about 20% performance improvements for openarena in full-screen mode, and about 12% improvements in nexuiz.

The i915 driver in kernel 3.1 received a total of 95 new patches when compared to 3.0 (excluding merges), coming from 14 different authors – both working at Intel and not. Now the road is open for 3.2. So fasten your seat belts and prepare for the next ride .

As a shameless self-promoting plug, let me start by sharing the presentation about Linux and Open-Source which I did last week. As with all my other presentation, I put it on scribd:

Linux e Open-Source: o que são e como podem me ajudar durante a faculdade?

I hope it would be as much interesting for you to access it, as it was for me to have the opportunity to write and present it. Thanks to all who attended the event, it was great!

But going back to the technical items in the agenda, let me start with the Kernel progress over the past week:

• As you all know, Kernel 3.1 was just released. It comes with a nice set of patches for Intel Graphics, so we hope you’ll enjoy it. Expect all range of improvements – from performance boosts to lots of stability and feature-wise fixes.
• As a major news, we had a pull request for the drm-intel-next branch from Keith Packard, for inclusion into the 3.2 version of Linux kernel. It comes with lots of interesting patches, among which I’d like to highlight the Ivybridge 3-display pipe support, lots of fixes for Embedded Display Port (eDP) handling on Sandy Bridge architecture, workarounds for the VT-d-related issues on Ironlake family of GPU, fixes for interrupt race conditions, among many others.
• Still on kernel, there was a number of conversations – all over the IRC channel, bugzilla and mailing lists – about GPU hangs and backlight-related issues. Some of those investigations resulted in new patches which could possibly solve – or, at least, help identifying the issues.
• On the FBC front, I’ve sent an initial patch for enabling Frame Buffer Compression on Ivybridge. It still needs testing and verification though, and lots of changes in code style and content, many of which were pointed out by Chris Wilson. So I’ll work on it this week.
• And as a bonus news, it looks like all the critical RC6-related issues (e.g., crashes or hangs) are now gone. There are still rendering-related problems though, some of which I came to figure out through this blog of mine (thank to you all for reporting!!). This is still not the ideal solution, but heck – it is a large step forward. Based on latest performance and power-related investigations which both we carried out internally, and the ones reported by community – by activating RC6 one could expect up to 50% improvements in power consumption. Definitely a nice thing to have.

On mesa front, we had a number of news as well:

• A discussion about moving the DRI1 radeon drivers into the land where the old drivers live happy forever-after was started by Eric and picked up by a number of Mesa developers. Those are possibly the last remaining drivers using DRI1 code path out there, and I guess we won’t have them around for much longer. Specially now that gallium backend is among us.
• Some optimizations about dead and non-reachable code cleanups were proposed by Ian.
• And we had several fixes for Gen6 and Gen7 architectures from Kenneth and Yuanhan.

An interesting collection of news came from the X.org development land:

• The discussion about Glamor server project was carried on, with a number of interesting opinions and talks. Glamor project, which was initially sent to the X developers mailing list some weeks ago, is aiming at introducing a new hardware-independent DDX which can use the GPU acceleration via OpenGL interface. One of the concerns expressed by the X development community about it is that, well, there are already too many different acceleration projects for X out there. So, after a number of very insightful discussions about Glamor, it was agreed that its development will be split into two different branches – one device-independent library, which could be reused by all the other DDX drivers; and intel-specific bits will be developed and integrated on their own incremental pace.
• Besides Glamor, lots of activity came from the Xinput developers and documentation updates.
• A number of coverity-discovered patches was sent by Dave Airle.
• And as a major news, we had a new security update for the Xserver project, fixing two security vulnerabilities: CVE-2011-4028 and CVE-2011-4029. One of the vulnerabilities allows to disclose the existence of a privileged file, and another allows to reset permissions of a restricted file to 444 via a symlink attack. So it would be a good idea to update your Xserver installation with those fixes included.

On Cairo side, there was an interesting discussion about slow HTML5 rendering in Firefox, coming from the non-optimal usage of X shared memory. The root of the problem is that code path used in this case does not uses BigReq extension, so it is limited to allocating a fixed 16Kb buffer – which is obviously not enough for the data it needs to process. So it results in lots and lots of small transmissions, and incurring in around 25k context switches per second.

Those are the major highlights of what I’ve seen over the past few days. See you on the next post .