Intel Comes Up With An Alternative To Bringing Back UMS

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.