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
Comment On This Article

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 Articles & Reviews
  1. Trying Out The Modern Linux Desktops With 4 Monitors + AMD/NVIDIA Graphics
  2. Turning A Basement Into A Big Linux Server Room
  3. NVIDIA's $1000+ GeForce GTX TITAN X Delivers Maximum Linux Performance
  4. OS X 10.10 vs. Ubuntu 15.04 vs. Fedora 21 Tests: Linux Sweeps The Board
  5. The New Place Where Linux Code Is Constantly Being Benchmarked
  6. 18-GPU NVIDIA/AMD Linux Comparison Of BioShock: Infinite
Latest Linux News
  1. GNOME 3.16 SDK Runtime Now Available
  2. Initial Intel Braxton Support Might Come To Linux 4.1
  3. Why KDE's KWin Doesn't Integrate Weston/QtCompositor For Wayland Support
  4. Clang Now Supports Targeting The NaCl OS
  5. PC-BSD Updates Its Lumina Desktop (v0.8.3)
  6. Fedora 22 Alpha Now Available For AArch64 & PowerPC64
  7. Systemd Developers Did NOT Fork The Linux Kernel
  8. PulseAudio 7.0 To Enable LFE Remixing By Default
  9. Features & Changes Coming For Mir 0.13
  10. How Far Valve Has Come: Three Years Ago They Needed OpenGL Linux Help
Most Viewed News This Week
  1. Introducing The Library Operating System For Linux
  2. Improved OpenCL Support For Blender's Cycles Renderer
  3. Allwinner Continues Jerking Around The Open-Source Community
  4. Open-Source Driver Fans Will Love NVIDIA's New OpenGL Demo
  5. GNOME 3.16 Released: It's Their Best Release Yet
  6. Systemd Change Allows For Stateless Systems With Tmpfs
  7. Ubuntu 15.04 Final Beta Released
  8. Nuclide: Facebook's New Unified IDE