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

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 Linux Hardware Reviews
  1. ASRock X99 Extreme3 Is An Affordable Choice For Linux Users
  2. A Walkthrough Of The New 32 System Open-Source Linux Benchmarking Test Farm
  3. Habey MITX-6771: Mini-ITX Board With Quad-Core J1900 Bay Trail
  4. OCZ Vector 150 SSD On Linux
Latest Linux Articles
  1. 17-Way Linux Graphics Card Comparison With Civilization Beyond Earth
  2. AMD Kaveri: Open-Source Radeon Gallium3D vs. Catalyst 14.12 Omega Driver
  3. 12-Way AMD Catalyst 14.12 vs. NVIDIA 346 Series Linux GPU Comparison
  4. AMD Catalyst 14.12 Omega Driver Brings Mixed Results For Linux Users
Latest Linux News
  1. Live Patching Support Planned For Linux 3.20/4.0 Kernel
  2. Features Of The Linux 3.19 Kernel: Graphics & Disks Rule
  3. Orange Pi Is The Latest Raspberry Pi Inspired ARM Board
  4. An Open-Source Hardware Ambient Light Sensor Is Brought Up
  5. Heterogeneous Memory Management Is Coming Along For The Linux Kernel
  6. NTP Is The Latest Project Struck By Security Issues
  7. LDC 0.15.1 Released For A D Compiler In LLVM
  8. Fedora Doesn't Yet Enable F2FS File-System Support
  9. XZ 5.2 Adds New Multi-Threaded Options
  10. Intel 2.99.917 X.Org Driver Released, 3.0 Release Finally Near
Latest Forum Discussions
  1. Looking for an nVidia GPU, but not sure how well they are supported.
  2. No OpenCL with latest driver updates on Ubuntu?
  3. Need some hand holding with upgrading xserver
  4. Maker3D - create your 3D RPG
  5. FPS capped on Linux (AMD fglrx drivers)
  6. Speeding up systemd networking service
  7. Major Performance Breakthrough Discovered For Intel's Mesa Driver
  8. Are there an app using HSA ?