Another month is at end, and it looks like a good timing for another update about the Intel Linux Graphics project.

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 :) !

As Starks used to say, “Winter is coming”. So in this sense, time has come for another round of updates from the Intel Linux Graphics project.

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 :) ).

Yeah, I know that it has been quite a while since I last time wrote about news from the Intel Linux Graphics land. But as an excuse for such a long delay, I can say that it wasn’t because we had nothing to comment about – but on the contrary, we had sooo many things happening that I really could get a free time to write something.

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.

Golf course at Skamania Loudge

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 :) ).

Distant lonely mountain

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.

Snow on a bridge.

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 :) .

© 2012 Eugeni's blog Suffusion theme by Sayontan Sinha