Wednesday, January 15, 2014

Neat drm/i915 stuff for 3.14

Kernel v3.13 is nearing its release, so it's time at our regular look at what the next version will bring to the Intel gfx driver.

This time around there was a lot of infrastructure work for improved power management. Imre Deak implemented code to manage display power wells in a more generic way so that the current Haswell support is also ready for other platforms. Unfortunately new platform support hasn't landed yet. But for Haswell we now have working runtime D3 support, contributed by Paulo Zanoni. For Baytrail/Valleyview Deepak S provided improvements to the GT power well  force-wake code - on these mobile platforms it is split up between the render engine and more auxiliary engines like the blitter and the video decode hardware.

Back to the topic of display and power management Ville Syrjälä contributed a lot of patches to fix little issues in the watermark computation code and als for the framebuffer compression support. The motivation for this is Ville's atomic pageflip feature work which not only needs to update all the scanout targets (primary plane, sprites, ...) but also all derived state perfectly synchronized to the next vblank. And especially the watermark updates have proven to be really tricky to get right. Finally Jani Nikula has completely rewritten our low-level backlight code. This has already fixed a few bugs, and hopefully this new code will give us fewer headaches in the future than the old one. Note that this is just about the raw backlight interface provided by Intel's integrated gpu, almost all machines use some other PWM or at least have some fanciness (written in ACPI scripts) on top of that. So don't expect your backlight to magically work perfectly, this is just a tiny piece of the puzzle.

Looking at GEM related features the big thing is the reset statistics ioctl from Mika Kuoppala. This is the kernel code to implement the GLX_ARB_robustness extension, and the further building blocks on top of that. This extension is shipping in Mesa 10.0.x releases and is necessary to implement browser support for WebGL in a sane way. Thjs release cycle has also seen more patches from Ben Widawsky towards full ppgtt support, but the final bits didn't make the cut due to a few regressions that popped up at the last minute.

For platform support the big thing is that we've removed the prelimary hardware support tag for Broadwell, which means 3.14 and later kernels will use the real i915.ko driver by default. There's still a few features missing for full-blown Broadwell kernel support, but all the basics to boot the system and so avoid users getting stuck with black screens are there. Baytrail also has seen lots of smaller improvements, like a vga hotplug fix from Imre, DSI improvements from Deepak and tons of other patches from Jesse Barnes, Ville and Chon Lee Ming.

One last piece new in 3.14 is the deprecation of the legacy UMS support. We've kept this code on live support since a few years already, but now it's getting in the way of some of the plans for improving the driver load and teardown code. So long-term we want this gone. For now there's still a kernel config option to keep the code around. Another new&nifty kernel option disables the legacy fbdev support. This is not something for your regular desktop linux system yet since the boot splash and a bunch of other things rely on it. And you also need to manually make sure that the vga driver doesn't load. But it does allow us to rip out all the legacy linux framebuffer support code, which is beneficial for embedded systems. And with efforts like David Herrmann's kmscon also where the future is heading towards in general.

7 comments:

  1. AIUI, you definitely want fbdev support when using kmscon. In the event that kms craps out, you need a stable, reliable fallback. kmscon supports fbdev as that fallback.

    ReplyDelete
    Replies
    1. fbdev is useful as a fallback for hardware without kms drivers. But if you have a kms driver the fb device exposed is just a wrapper around the underlying kms driver. So not useful as a fallback at all. But on a lot of embedded systems there's no legacy userspace which requires and fbdev emulation to work, so it's useful to be able to compile out all that code. Linux distros otoh use fbdev e.g. for boot-splashs still.

      Delete
  2. > Another new&nifty kernel option disables the legacy fbdev support.

    I'm missing something here. What's the difference to DRM_I915_FBDEV, that afaics already landed in 3.13? http://git.kernel.org/linus/4520f53a159fb81b8c27afe52428a0959aff259c

    ReplyDelete
    Replies
    1. Indeed, I've somehow missed that this has landed already. But we've merged a few fixes from Chris Wilson to make the vga handover a bit more robust in 3.14 with fbdev disabled, so I'd say it still counts a bit ;-)

      Delete
  3. Wondering if 3.13 might fix my issues. I am currently trying out an Asus zenbook UX302LA-BHI5T08 with i5-4200U\Intel 4400 graphics. Using kernel 3.12.9-2 (Arch), I currently have to use i915.modeset=0 to see anything a boot, even a just the command line. I have been searching all over and reading up on the i915 drivers changes and issues with haswell CPUs. Even watched a couple of your vids on this topic from late 2012. I have been trying different kernel parameters to get this thing booting with the proper 1920x1080 resolution (acpi_backlight=vendor etc.), but haven't found a single param or combination of param that work.What kernel params would you try on this laptop to get things working? Would 3.13 be more likely to work?

    Older kernels do work (Ubuntu 12-based distros I tried), but then I don't have wireless support for Wireless-AC haha! 800x600 might be worse thought LOL.

    ReplyDelete
    Replies
    1. Update: I threw on 3.14-rc2 and everything is now working great now without ANY extra kernel params. I have 1920x1080 and brightness control. Keep up the great work on drm/i915 stuff!

      Delete
    2. Awesome, always nice to hear that we're making progress. Please keep on testing and file a bug report if anything breaks, we take regressions extremely serious. It's the only way to have some assurance that we're indeed improving and not just running in circles

      Delete