1. Computers
  2. Display Drivers
  3. Graphics Cards
  4. Memory
  5. Motherboards
  6. Processors
  7. Software
  8. Storage
  9. Operating Systems


Facebook RSS Twitter Twitter Google Plus


Phoronix Test Suite

OpenBenchmarking.org

Intel Comes Up With An Alternative To Bringing Back UMS

Intel

Published on 26 August 2010 02:03 PM EDT
Written by Michael Larabel in Intel
16 Comments

The Intel Linux driver has been challenged by stability problems and other issues for owners of i8xx hardware since they rolled out kernel mode-setting and Graphics Execution Manager (GEM) support with UXA 2D acceleration more than a year ago. There were initial problems for other Intel users as well when switching to this overhauled driver stack -- to the point that it killed the netbook experience -- but those problems were quickly worked away. But for those using Intel's oldest supported hardware under Linux, the problems to this day remain. To circumvent this issue there's been the approach to add back user-space mode-setting to the Intel driver with EXA 2D acceleration to simply avoid these problems rather than correct the actual issues with KMS/GEM/UXA, but now another alternative has emerged.

Adding back user-space mode-setting and EXA acceleration to better support this vintage hardware would have added nearly 50,000 lines of code back to the xf86-video-intel driver and it would have likely received little testing and work by Intel's open-source developers. Instead the new approach is to keep kernel mode-setting for i8xx hardware, but to use a shadow frame-buffer rather than providing GPU acceleration with UXA/EXA.

The new code published by Chris Wilson would touch less than 500 lines of the Intel driver code by simply adding ShadowFB support to kernel mode-setting. Intel owners with problematic hardware can still have fun with kernel mode-setting and features like hot-plugging, RandR, suspend-and-resume, video overlay support, and other KMS features, but you'll lose any form of GPU acceleration.

For 2D operations you'd be using the shadow frame-buffer with the CPU, but taking this approach would break support for being able to use DRI2 and using DRI1 in the Intel driver has since been removed too. Though in terms of no actual EXA acceleration, using the ShadowFB can be fast for basic 2D especially compared to the old and slow Intel ASICs that are being problematic.

In this commit, Chris describes his approach to creating a shadow frame-buffer with kernel mode-setting:
An attempt to workaround the incoherency in gen2 chipsets, we avoid using dynamic reallocation as much as possible.

The first step is to disable allocation of pixmaps using GEM and simply create them in system memory without a backing buffer object. This forces all rendering to use S/W fallbacks.

The second step is to allocate a shadow front buffer and assign that to the Screen pixmap. This ensure that the front buffer remains in the GTT and pinned for scanout. The shadow buffer will be rendered to in the normal fashion via the Screen pixmap, and be marked dirty. In the block handler, the dirty shadow buffer is then blitted (using the GPU) over the front buffer. This should completely avoid having to move pages around in the GTT and avoid incurring the wrath of those early chipsets. Secondly, performance should be reasonable as we avoid the ping-pong caused by the small aperture and weak GPU forcing software fallbacks.

As this alternative approach of using KMS while disabling GPU acceleration amounts to about 1% the code size as the method of adding back user-space mode-setting and EXA, it's likely we will see this code added to the xf86-video-intel DDX and in time for the 2.13.0 release. Right now this code is living in Chris Wilson's "shadow" branch of the X.Org driver. The related mailing list message can be found here.

Latest Linux Hardware Reviews
  1. Mini-Box M350: A Simple, Affordable Mini-ITX Case
  2. Overclocking The AMD AM1 Athlon & Sempron APUs
  3. AMD Athlon 5350 / 5150 & Sempron 3850 / 2650
  4. Upgraded Kernel & Mesa Yield A Big Boost For Athlon R3 Graphics
Latest Linux Articles
  1. Ubuntu 12.04.4 vs. 13.10 vs. 14.04 LTS Desktop Benchmarks
  2. AMD OpenCL Performance With AM1 Kabini APUs
  3. A Quick Look At GCC 4.9 vs. LLVM Clang 3.5
  4. Are AMD Athlon/Sempron APUs Fast Enough For Steam On Linux?
Latest Linux News
  1. Ubuntu 14.04 LTS "Trusty Tahr" Officially Released
  2. Ubuntu 12.04 LTS vs. 14.04 LTS Server Benchmarks
  3. QEMU 2.0 Released With ARM, x86 Enhancements
  4. Running The Unity 8 Preview Session On Ubuntu 14.04 LTS
  5. R600 Gallium3D Disables LLVM Back-End By Default
  6. Fedora 21 Gets GNOME 3.12, PHP 5.6, Mono 3.4
  7. Fedora Workstation Is Making Me Quite Excited
  8. Maynard: A Lightweight Wayland Desktop
  9. Chromium Browser Going Through Growing Pains In Ubuntu 14.04
  10. KDE 4.13 Is Being Released Today With New Features
  11. Trying Out Radeon R9 290 Graphics On Open-Source
  12. Intel Broadwell GT3 Graphics Have Dual BSD Rings
Latest Forum Discussions
  1. Updated and Optimized Ubuntu Free Graphics Drivers
  2. The GNOME Foundation Is Running Short On Money
  3. After Jack Keane, RuseSoft will briing Ankh 3 to Linux through Desura
  4. Suspected PHP Proxy Issue
  5. Linux Kernel Developers Fed Up With Ridiculous Bugs In Systemd
  6. Change installation destination from home directory
  7. Bye bye BSD, Hello Linux: A Sys Admin's Story
  8. New tool for undervolt/overclock AMD K8L and K10 processors