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 termsand 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 ).
(Just in case – the 1st season of Game of Thrones is already available on DVDs/BDs for a long time, so the ones who don’t know what it is about can certainly watch it on Linux without facing all the scary copy-protection evilness and such. But beware – it will ruin your day/week/month and you won’t be able to stop until the end. And then there are still months until the 2nd season comes to an end. Oh my..).
What’s the oldest hardware generation that supports vaapi? My GM965 is probably too old? (And in any case my “HMPC” Asus EeePC 900 has the even older 945 graphics. Time for a change, perhaps.)
I think that the latest list we have is available at http://intellinuxgraphics.org/h264.html. So if I am mapping the marketing names into the core names correctly, everything starting with Core 2 Duo or so should support it. And everything above that does not have hardware for run hw-accelerated media stuff, so all they do is being done in software anyway..
Thanks a lot for those updates! Do you by chance know if anything above is related to this bug: https://bugs.freedesktop.org/show_bug.cgi?id=37686#c55 ?
@Tomasz – no, sadly, tearing is still a mystery on sandy bridge. I came with some patches which apparently solved it, but also introduced gpu hangs.. so we are still looking for the right fix
.
You may add a new category now, concerning progress related to coreboot support for SB/IB http://www.phoronix.com/scan.php?page=news_item&px=MTA4Mjg
As far as I know, coreboot-related items are being developed independently by google, without any interaction with us… So I don’t have anything to say about this…
Indeed, and moreover, reading Coreboot ML, it seems that Coreboot requires a signed Intel blob to initialize memory :-/
BTW i’ve written on LinuxFR a detailed (& very positive!) article on Ivy Bridge on Linux http://linuxfr.org/news/intel-ivy-bridge-et-linux-ca-juste-marche using information you’ve provided here, thank you
(i also wrote another one before on Sandy bridge too http://linuxfr.org/news/intel-sandy%C2%A0bridge-et-linux%C2%A0-%C3%A9tat-des-lieux )
Michael Larabel said that “Intel’s VA-API is implemented with their video engine unlike the Nouveau/Radeon Gallium3D drivers that are doing VDPAU/VA-API with GPU shaders over Gallium3D”
It’s the 1st time i see that piece of information, i thought that VA-API made use of shaders. Could you confirme that please ?
http://www.phoronix.com/scan.php?page=article&item=intel_ivy_gpushow&num=13 http://software.intel.com/en-us/forums/showthread.php?t=77855
@antistress – both statements are true actually.
Shaders are used in VAAPI for everything that is related to rendering, this is true. And starting with Sandy Bridge, the GPU has a dedicated decode and encode pipelines for media as well. So those can be used to offload media processing to hardware (for example, the quicksync uses that for very fast media converting), while still using shaders for other tasks in parallel.
So VAAPI is taking advantage of both approaches – using shaders when necessary, and dedicated media pipeline when it is available (e.g., on Sandy Bridge and Ivy Bridge).
@eugeni : thank you dedicated quicksync decoding is also supposed to need fewer watts on Windows than a traditionnal generic shader approach, i think. Is the Linux VAAPI also power efficient ?