Yeah, I admit that my semi-periodic updates about Intel Linux Graphics got more “seldom-periodic” than “truly-periodic” for the past weeks. But have no fear – they are back! And I am still on my self-appointed bi-weekly schedule estimate. This is what’s good about semi-periodic schedule – one never can run too much out of it :) .

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

10 Responses to “Holidays news from Intel Linux Graphics land”

  1. I can’t wait either to get a Ivy Bridge :-) Thank you all at Intel OSTC for your work on the Linux graphic stack (OGL 3.0, VA-API, Wayland etc)

  2. I use VT quite regularly with KVM. Any plans to fix the incompatibility so that Sandy Bridge can use RC6 and related features?

  3. Any idea where I could find more information on the status of WiDi technology under Linux? Anyone working on it?

  4. About VT – what needs to be disabled is VTd, or I/O virtualization (a.k.a., intel_iommu=off). The common virtualization works without any issues.

  5. About WiDi on Linux – sorry, I don’t know much about its support on Linux either… I’d be very happy to have it as well, the cables are transforming my home into a spiderweb lately :)

  6. Some thoughts questions: *Coming IVB will be good if you can work on some big hits of DX11/OGL 4.0 HW like exposing tessellation and double precision in shaders.. hope we shouldn’t wait until 3.1/3.2/3.3 get implemented before seeing this extensions exposed.. So basically will be interesting how much time we will need to be able to run Uninige Heaven 2.x with OGL tessellation support.. *Can we expect on IVB release all documentation needed for doing open source OpenCL LLVM backend similar to released by AMDIL backed released by AMD or better yet OpenCL team release this LLVM backend in open source form.. also will be interesting how if Intel OpenCL impl on IVB GPU remains closed it interacts with open source GL driver for efficient OCL/OGL interop.. *Will you be able to expose quicksync functionality ever on Linux? or release documentation for open source people implementing it?

  7. @oscarbg – sorry, I cannot answer those questions prior to the product launch. I’d be getting dangerously close to a non-disclosure stuff if I comment on those items now, just wait some more weeks for official news on that :) .

  8. @oscarbg : i’m not convinced that quicksync is useful actually : quality doesn’t seem as good as it should be. Same problem with AMD and NVidia solutions for that matter. See http://www.hardware.fr/articles/828-1/encodage-h-264-cpu-vs-gpu-nvidia-cuda-amd-stream-intel-mediasdk-x264-test.html I expect decoding/encoding through GPU using VA-API (& GStreamer 1.0) to provide hw acceleration without sacrifying quality

  9. @eugeni: do you have any news/infos about DVMT support in Linux? So far I could only find a mention of DVMT in drivers/staging/gma500/gtt.c.

  10. @yegorich, I believe all Intel graphics cards support DVMT automatically. You can check what objects are allocated to the video memory via /sys/kernel/debug/dri/0/i915_gem_objects.

Leave a Reply

(required)

(required)

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

© 2012 Eugeni's blog Suffusion theme by Sayontan Sinha