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 Benchmarking Platform
Phoromatic Test Orchestration

Announcing The DRM VGEM - Virtual GEM Provider

Linux Kernel

Published on 11 January 2012 09:02 PM EST
Written by Michael Larabel in Linux Kernel
Add A Comment

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.

About The Author
Michael Larabel is the principal author of Phoronix.com and founded the web-site in 2004 with a focus on enriching the Linux hardware experience and being the largest web-site devoted to Linux hardware reviews, particularly for products relevant to Linux gamers and enthusiasts but also commonly reviewing servers/workstations and embedded Linux devices. Michael has written more than 10,000 articles covering the state of Linux hardware support, Linux performance, graphics hardware drivers, and other topics. Michael is also the lead developer of the Phoronix Test Suite, Phoromatic, and OpenBenchmarking.org automated testing software. He can be followed via and or contacted via .
Latest Linux News
  1. Yet Another OpenGL 4.5 Extension Is Nearing Completion In Mesa
  2. Xfce's Power Manager Is Finally Ported To GTK3
  3. The CompuLab Fitlet Is A Neat Little Linux PC With AMD SoC
  4. AMD & Others Are Working On The LLVM SPIR-V Converter
  5. Linux 4.1-rc5 Kernel Released
  6. Mesa 10.5.6 Brings Fixes All Over The Place
  7. NVIDIA's Proprietary Driver Is Moving Closer With Kernel Mode-Setting
  8. The Latest Linux Kernel Git Code Fixes The EXT4 RAID0 Corruption Problem
  9. Features Added To Mesa 10.6 For Open-Source GPU Drivers
  10. Ubuntu's LXD vs. KVM For The Linux Cloud
Latest Articles & Reviews
  1. Opening The Gates To Our Daily Open-Source Linux Benchmark Results
  2. The Latest Features For Linux Performance Management + Benchmark Monitoring
  3. Noctua NH-U12DX i4 + NF-F12
  4. Btrfs RAID 0/1 Benchmarks On The Linux 4.1 Kernel
Most Viewed News This Week
  1. The Linux 4.0 Kernel Currently Has An EXT4 Corruption Issue
  2. The Linux 4.0 EXT4 RAID Corruption Bug Has Been Uncovered
  3. Microsoft Open-Sources The Windows Communication Foundation
  4. Systemd 220 Has Finally Been Released
  5. NVIDIA's Proprietary Driver Is Moving Closer With Kernel Mode-Setting
  6. Another HTTPS Vulnerability Rattles The Internet
  7. LibreOffice 5.0 Open-Source Office Suite Has Been Branched
  8. LibreOffice 5.0 Beta 1 Released