Eugeni's blog

Long time no news?

devel, english, intel, kernel, linux, Linux-Planet, mandriva, mesa 2 Responses »

Nov 192011

Well, not that long time, but still, I’ve been somewhat slower on news about Intel Linux Graphics this week, partly due to LinuxCon Brazil which happened here.

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!

Intel Linux Graphics on LinuxCon Brazil

devel, english, intel, kernel, linux, Linux-Planet, mandriva, mesa, review, vaapi, writing, x.org 4 Responses »

Nov 182011

For those of you who couldn’t attend LinuxCon Brazil – I’ve put my presentation about Intel Linux Graphics online for you all.

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

Have fun!

Intel Linux Graphics

And now, on your favorite Intel Linux Graphics news station…

devel, english, intel, kernel, linux, Linux-Planet, mageia, mandriva, mesa, programming, Uncategorized, x.org 1 Response »

Nov 082011

After some period of silence, this blog returns in bringing you the latest and greatest news from the Intel Linux Graphics world.

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.

Continuing with the semi-periodic updates…

devel, english, intel, kernel, linux, Linux-Planet, mageia, mandriva, Uncategorized, vaapi, x.org 7 Responses »

Nov 012011

…lots of things happened in the past days, on all fronts.

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 .

VAAPI users around the world, rejoice!

devel, english, intel, linux, Linux-Planet, mageia, mandriva, vaapi 14 Responses »

Oct 282011

Hello media users around the world with Intel cards aboard!

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 .

And now, time for some numbers

devel, english, intel, kernel, linux, Linux-Planet, mageia, mandriva No Responses »

Oct 272011

Michael Larabel from Phoronix was kind enough to carry out two different testing for the recently released kernel 3.1 on top of our Intel Linux Graphics cards today (thanks again Michael!). He split his evaluations into two different articles – First one is focused on performance and power usage for stock 3.1 kernel; and Second one specifically enabled RC6 on this kernel to see its effects in action.

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 .

Kernel 3.1 is out..

devel, english, intel, kernel, linux, Linux-Planet, mageia, mandriva, writing 12 Responses »

Oct 252011

…but what does it means for Intel Linux Graphics?

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 .

Graphics News Monday

devel, english, intel, kernel, linux, Linux-Planet, mageia, mandriva, mesa, x.org 5 Responses »

Oct 242011

Another week, another round of updates .

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 .

If you ever wondered who Eugeni is…

devel, english, intel, linux, Linux-Planet, mageia, mandriva 2 Responses »

Oct 192011

…and never had a chance to meet me, now you have .

I’ll do two Linux and open-source-related presentations in the coming weeks.

The first one would occur at the IV Semana Nacional de Ciência e Tecnologia, promoted by the Instituto Federal de Educação, Ciência e Tecnologia de São Paulo – campus São Carlos, this Friday as 20:30 at UFSCar. I’ll give a presentation about Linux, Open-Source, and why it is a good idea to work and contribute to it during the (under)graduation. The title of the presentation is Linux e Open-Source: o que são e como podem me ajudar durante a faculdade?, and it will be in portuguese. The link to the event and additional details about it are listed here.

The second will be at the LinuxCon Brazil conference, where I’ll have a presentation with self-explained title Intel Linux Graphics – Following the Open Source Road from Kernel to UI Toolkits. The LinuxCon conference needs no introduction, and it will have lots of amazing presentations, so be sure to check it out!

Also on LinuxCon, we’ll have a presentation by Guilherme Moro, who replaced my at Mandriva when I left. He’ll talk about Managing IT infrastructure with Open Source Multiplatform Tool Pulse 2. He is a great developer and a good friend of mine – I actually was responsible for bringing him to mstech, and later to Mandriva, to work in my teams. So it would be a great presentation to watch as well.

But in general – if you happen to come to any of the aforementioned presentation, I’ll be happy to talk about linux, intel, open-source, mandriva, mageia, football, programming and all other nice and endless issues .

So, what’ve been up to at linux graphics lately?

devel, english, intel, kernel, linux, Linux-Planet, mageia, mandriva, mesa, programming, x.org 3 Responses »

Oct 182011

So far, it turned out that the semi-periodic write-ups turned up to be much more frequent that I originally thought. Let’s see if I’ll be able to keep this pace – lots of interesting things are happening all around, so I think that it is not worth waiting weeks just to write a summary of most important points.

Since last update, we had a very productive weekend , and 2 days of work on all the projects. In this time span, on intel-gpu-tools front, we had some interesting commits:

One from myself, to add non-interactive logging of GPU activity, parseable by other scripts and applications
Several from Daniel, improving the debugging facilities of the tools
A new intel_reg_checker application from Eric Anholt, which attempts to discover possibly incorrect settings which could lead to the crash/hang/issue.
And I’ve sent some heuristics patches for intel_error_decode and intel_decode which attempt to identify the root cause of the problem (e.g., if it came through mesa codepath, or 2D driver, or VA). After discussion on both mail and IRC with Chris and Daniel, we came to the conclusion that this approach should be better approaches from a separate script or app, which would do the analysis of the trace.

On Kernel, we had some nice news too:

QA has carried out the performance and functionality testing for my edid patch, and it gave a really nice performance boost in all cases. After sending the final version of the patch, we had some comments from Jean Delvare and Alex Deucher about possible issues this could bring to radeon-based cards, if the fix would be implemented inside DRM. So I am still not sure about what to do here – I have two versions of the same fix, both are working, but I don’t know which one will be the final one.
Lots of activity and discussion on SNA, VA and RC6-related issues took place from Daniel, Ben, Chris and myself. Some of the reported issues have been isolated (well.. mostly ), and some have some patching attempts. The root cause of the problems is not clear yet. But on the bright side, apparently, we don’t have any crash or hang-related issues coming via RC6, only some rendering corruptions. So hopefully RC6-by-default will see the light of day again in some point in the future .
Some (possibly) final patches from Ben Widawsky and David Woodhouse arrived, attempting to fix the VTd-related problem on Ironlake chipsets.

Meanwhile, Mesa has had lots of activity too:

Chad Versace sent out some dozens of patches which added support for HiZ infrastructure in core mesa, adding new driver hooks and small changes all around. Note that HiZ is supposed to be supported by i965 family of the chips (e.g., 5th (Ironlake) generation onward).
Lots of piglit and conformance patches arrived from Eric, Yuanhan and Chad.
Stencil buffer support has received some updates from Chad as well.
And an improved math performance patch was sent by Ken. It should improve math-related operations by a nice margin on Ivybridge, and also allows it to work in a workaround-free way .

On DDX front, as usually, we had an impressive number of patches from Chris for SNA. On a related note, past weeks had given us lots and lots of feedback about SNA and how people are using it. This is great – it means that it works (despite some issues, many of which are already filed as bugs, or being investigated right now)! I’ve been using SNA by default on all my machines for a couple of months, and it works just fine for me. Only faster .

And finally, on Xserver-related work, we had a new Glamor pull request from Zhigang Gong, lots of man and documentation-related patches, Xinput and evdev development, and a small patch which drops support for the bsdi. I am actually quite curious about this one – it has been a really, really long time since I’ve seen a bsdi system out there. Does anyone still has one around? It would be nice to play with it those days…

EDIT: Update from Daniel Vetter – HiZ is available in hardware starting from Ironlake. I updated the post accordingly.