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


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.

Latest Linux Hardware Reviews
  1. Mini-Box M350: A Simple, Affordable Mini-ITX Case
  2. Overclocking The AMD AM1 Athlon & Sempron APUs
  3. AMD Athlon 5350 / 5150 & Sempron 3850 / 2650
  4. Upgraded Kernel & Mesa Yield A Big Boost For Athlon R3 Graphics
Latest Linux Articles
  1. A Quick Look At GCC 4.9 vs. LLVM Clang 3.5
  2. Are AMD Athlon/Sempron APUs Fast Enough For Steam On Linux?
  3. AMD Athlon's R3 Graphics: RadeonSI Gallium3D vs. Catalyst
  4. GCC 4.9 Compiler Optimization Benchmarks For Faster Binaries
Latest Linux News
  1. Fedora Workstation Is Making Me Quite Excited
  2. Maynard: A Lightweight Wayland Desktop
  3. Chromium Browser Going Through Growing Pains In Ubuntu 14.04
  4. KDE 4.13 Is Being Released Today With New Features
  5. Trying Out Radeon R9 290 Graphics On Open-Source
  6. Intel Broadwell GT3 Graphics Have Dual BSD Rings
  7. Early Linux 3.15 Benchmarks Of Intel Core i7 + Radeon
  8. Red Hat Releases Its RHEL 7 Release Candidate
  9. New Features Coming To Xubuntu 14.04 LTS
  10. NVIDIA Officially Releases CUDA 6
  11. Google Releases An AutoFDO Converter For Perf In LLVM
  12. Fedora 21 To Evaluate Remote Journal Logging, 64-bit ARM Emulation
Latest Forum Discussions
  1. The GNOME Foundation Is Running Short On Money
  2. Change installation destination from home directory
  3. After Jack Keane, RuseSoft will briing Ankh 3 to Linux through Desura
  4. Linux Kernel Developers Fed Up With Ridiculous Bugs In Systemd
  5. Bye bye BSD, Hello Linux: A Sys Admin's Story
  6. New tool for undervolt/overclock AMD K8L and K10 processors
  7. How to enable opengl 3.3 on r9 270?
  8. R290x sound problems