Now that the upstream merge window has started and my last drm-intel-next pull request landed in Dave Airlie’s drm tree it’s a good time to look at some of the things landing in 3.7:

The big ticket item is the modeset-rework. On top of that we have some eDP fixes that required the new modeset infrastructure to work properly. Unfortunately the Haswell DP and eDP support did not make it - we’ve had patches for 3.6, but they’ve been too ugly to merge. Paulo Zanoni reworked all these patches on top of the new modeset code, unfortunately the new patches missed 3.7. Also, thanks to these eDP fixes I could finally merge CADL support, this should help to light up the backlight on some obnoxious platforms with a BIOS that tries to get in the way of the kms driver …

There are also tons of improvements to the Haswell HDMI support and stability fixes for Haswell rendering from Paulo Zanoni. And Ben Widawsky enabled hw context support on Haswell (required for geometry shader support) and a few other more obscure hw features for Haswell.

For power management Ben Widawsky added tons of sysfs interfaces to control gpu frequency scaling on Sandybridge and newer, e.g. to limit the gpu to the lowest frequency for that last ounce of battery runtime. PowerTOP will use this to show a histogram of gpu frequencies, to complete the rc6 histogram support already merged into 3.6.

On the GEM side Chris Wilson provided tons of tuning patches to etch out a bit more performance in corner cases: We now write PTEs with write-combine mappings where the (cacheable) ppgtt ptes are not available. He also optimized the gpu flushing code between batch buffers and reduced the overhead of the gpu->cpu synchronization on newer platforms. Also merged are his cachable BO support and the unbound BO tracking, both of which should help boost SNA nicely on pre-Sandybridge machines. And we now also have non-blocking gpu waits, which greatly helps interactivity when more than one drm client is using the gpu - which is the case as soon as you run a compositor using OpenGL. Beware benchmarkers though: A side-effect of this is that the gpu is shared more fairly between the different clients - this can result in reduced fps when running a windowized GL app, since Compiz now draws more frames itself, sucking away gpu time from the GL app. End result is though that more rendered frames end up actually visible on the screen.

A big cleanup under the hood of GEM is the removal of the flushing_list. This concept dates back to the first days of GEM years ago, but turned out to be totally useless. Unfortunately it also complicated the code massively, resulting in countless little bugs - we’ve first tried to rip this all out at the beginning of this year, but only for 3.7 we’ve managed to track down all the bugs this uncovered.

Last but not least countless other small improvements and code-cleanups all over the place. Oh, and: In case you have a i830M with a ns2501 lvds dvo chip: We now have basic support for that, thanks to Thomas Richter.pz