Announcing The DRM VGEM - Virtual GEM Provider

Alpha quality patches were published today that introduce the "Virtual GEM Provider" for the Linux kernel DRM, which can improve the software-based acceleration experience for graphics.

First some history... Back in September the Softpipe driver for Gallium3D became slightly more useful when GLX_EXT_texture_from_pixmap support came for software drivers, which is needed for some compositing window managers to function. In October that support then came to the LLVMpipe driver, which is the more useful software-based graphics driver since it takes advantage of LLVM for real-time shader generation and can take better advantage of modern CPUs to deliver slightly better performance.

In November was the big milestone when the GNOME Shell could then run on the LLVMpipe driver. It was tested and it worked. With a modern Intel/AMD CPU you can now run GNOME Shell without having GPU hardware acceleration, but its not nearly as efficient as having even a mediocre graphics card with a modest open or closed-source driver.

Being able to run the GNOME Shell with the Mutter window manager while not having to rely upon a GPU hardware driver will eventually cause the GNOME developers to cease maintaining the GNOME3 fall-back mode (it's already been expressed). Red Hat developers have also said this Shell-over-LLVMpipe driver will be one of the many features of Fedora 17. But first this software-accelerated mode could benefit from some performance optimizations and the Virtual GEM Provider works towards this end.

Read the November article about where the support is at now and part of what's planned for this software GPU driver built using LLVM and Gallium3D.

Within the Fedora 17 feature specification by Adam Jackson one of the work items has been: "llvmpipe currently does not use any DRM services. Most importantly this means that all image transfers between the X server and the compositor - both acquiring the window images with EXT_texture_from_pixmap, and uploading the new scene with glXSwapBuffers - are copies. Big, big copies. The DRM should provide a mock GEM allocator that is backed purely by system memory (optionally with the ability to bind and unbind such memory to a real driver), so that the software 3D stack can take advantage of the same kinds of zero-copy optimizations as hardware drivers."

Additionally from that Wiki page, "Drivers without a native DRM driver should be ported to use mock-GEM for memory management. For almost all such drivers this will just mean using mock-GEM to allocate the shadow framebuffer. Some cases (mostly virt, where shadowfb doesn't win you anything) will want to be able to bind their front buffer directly to a GEM object, to eliminate the memcpy on scene upload. Since llvmpipe probably wants to keep compatibility with non-mock-GEM X servers, either DRI2 or GLX needs to somehow advertise that the llvmpipe driver loaded in the server is mock-GEM-aware."

The Virtual GEM Provider (VGEM) as published today by Adam is this "mock GEM allocator" to speed things up for LLVMpipe and potentially the other drivers too. The VGEM code for the kernel DRM sub-system is just over 300 lines of code at present and is fairly simple, but already some developers have critiqued the design.

From the mailing list announcement:

This is about as minimal of a virtual GEM service as possible. My plan is to use this with non-native-3D hardware for buffer sharing between X and DRI.

The current drisw winsys assumes an unmodified X server, which means it's hopelessly inefficient for both the push direction of SwapBuffers/DrawPixels and the pull direction of GLX_EXT_texture_from_pixmap. I'm still working through the details of what the xserver support will look like, but in broad strokes it's "use vgem for CreatePixmap and optionally the shadowfb".

Obviously alpha quality, mostly looking for feedback on the approach or any glaring bugs. Eventually I'd like to see solutions for sharing gem objects between drm devices and/or the dma_buf API, but that's a ways down the road.

VGEM itself is interesting and the long-term plans of GEM object sharing between DRM devices and/or the recently-merged DMA-BUF makes it even more interesting.

As this is effectively a new driver (and a virtual one at that), it's possible we could see the Virtual GEM Provider pushed later in the Linux 3.3 kernel cycle outside of the merge window, assuming it's first-cut implementation is ready in the next few weeks, but Adam Jackson hasn't shared those plans. The code at least should be found in use by Fedora 17 in May.

There's also the X.Org Server changes that Adam mentions, which is now outside of the X.Org Server 1.12 merge window, but hopefully all of the pieces will come together making for better software-based graphics support in H2'2012 Linux distributions.

Besides this mock GEM support, there's also other LLVMpipe driver optimizations possible to benefit the Linux desktop. However, with the branching today of Mesa 8.0, that's now outside the current Mesa window.