Virtualizing GPU Access

Robert Foss avatar

Posted on 12/02/2018 by Robert Foss

Share this post:

Virtualized GPU access is becoming common in the containerized and virtualized application space. Let's have a look at why and how.

For the past few years a clear trend of containerization of applications and services has emerged. Having processes containerized is beneficial in a number of ways. It both improves portability and strengthens security, and if done properly the performance penalty can be low.

In order to further improve security containers are commonly run in virtualized environments. This provides some new challenges in terms of supporting the accelerated graphics usecase.

OpenGL ES implementation

Currently Collabora and Google are implementing OpenGL ES 2.0 support. OpenGL ES 2.0 is the lowest common denominator for many mobile platforms and as such is a requirement for Virgil3D to be viable on the those platforms.

That is is the motivation for making Virgil3D work on OpenGL ES hosts.

How does this work?

This stack is commonly referred to as Virgil3D, since all of the parts originated from a project with that name.

Collabora - Virtualized OpenGL Stack

There are a few parts to this implementation.

QEMU, virglrenderer and virtio-gpu. The way it works is by letting the guest applications speak unmodified OpenGL to the Mesa. But instead of Mesa handing commands over to the hardware it is channeled through virtio-gpu on the guest to QEMU on the host.

QEMU then receives the raw graphics stack state (Gallium state) and interprets it using virglrenderer from the raw state into an OpenGL form, which can be executed as entirely normal OpenGL on the host machine.

The host OpenGL stack does not even have to be Mesa, and could for example be the proprietary nvidia stack.

Trying it out


First of all, let's have a look at the development environment. When doing graphical development I find it quite helpful to set up a parallel graphics stack in order to not pollute or depend on the stack of the host machine more than we have to.

function add_export_env {
  local VAR="$1"
  local VAL=$(eval echo "\$$VAR")
  if [ "$VAL" ]; then
    VAL=$(concatenate_colon "$@" "$VAL");
    VAL=$(concatenate_colon "$@");
  eval "export $VAR=\"$VAL\""

function prefix_setup {
  local PREFIX="$1"

  add_export_env PATH "$PREFIX/bin"
  add_export_env LD_LIBRARY_PATH "$PREFIX/lib"
  add_export_env PKG_CONFIG_PATH "$PREFIX/lib/pkgconfig/" "$PREFIX/share/pkgconfig/"
  add_export_env MANPATH "$PREFIX/share/man"
  export ACLOCAL_PATH="$PREFIX/share/aclocal"
  mkdir -p "$ACLOCAL_PATH"
  export ACLOCAL="aclocal -I $ACLOCAL_PATH"

function projectshell {
  case "$1" in
    virgl | virglrenderer)
        export ALT_LOCAL="/opt/local/virgl"
        mkdir -p "$ALT_LOCAL"
        prefix_setup "$ALT_LOCAL"

The above snippet is something that I would put in my .bashrc or .zshrc. Don't forget so run source ~/.bashrc or the equivalent after making changes.

To enter the environment I simply type projectshell virgl.

Build libepoxy

libepoxy is a library for managing OpenGL function pointers for you. And it is a dependency of virglrenderer, which we'll get to below.

git clone https://github.com/anholt/libepoxy.git
cd libepoxy
./autogen.sh --prefix=$ALT_LOCAL
make -j$(nproc --ignore=1)
make install

Build virglrenderer

Virgilrenderer is the component that QEMU uses to provide accelerated rendering.
It receives Gallium states from the guest kernel via its virtio-gpu interface, which are then translated into OpenGL on the host. It also translates shaders from the TGSI format used by Gallium into the GLSL format used by OpenGL.

git clone git://anongit.freedesktop.org/virglrenderer
cd virglrenderer
./autogen.sh --prefix=$ALT_LOCAL
make -j$(nproc --ignore=1)
make install

Build libpciaccess

libpciaccess is a library for simplifying accessing devices on the PCI bus.
It is a dependency of Mesa, which we'll get to below.

git clone git://git.freedesktop.org/git/xorg/lib/libpciaccess
cd libpciaccess
./autogen.sh --prefix=$ALT_LOCAL
make -j$(nproc --ignore=1)
make install

Build Mesa

# Fetch dependencies
sudo sed -i 's/\#deb-src/deb-src/' /etc/apt/sources.list
sudo apt update
sudo apt-get build-dep mesa

# Actually build Mesa
git clone https://anongit.freedesktop.org/git/mesa/mesa.git
cd mesa
./configure \
    --prefix=$ALT_LOCAL \
    --enable-driglx-direct \
    --enable-gles1 \
    --enable-gles2 \
    --enable-glx-tls \
    --with-egl-platforms='drm x11 wayland' \
    --with-dri-drivers="i915 i965 nouveau" \
    --with-gallium-drivers="nouveau swrast radeonsi"
make -j$(nproc --ignore=1)
make install

Build QEMU

git clone git://git.qemu.org/qemu.git
cd qemu
./configure \
    --prefix=$ALT_LOCAL \
    --target-list=x86_64-softmmu \
    --enable-kvm \
    --disable-werror \
make -j$(nproc --ignore=1)
make install

Set up a VM

As a guest we're going to use Ubuntu 17.10, but just use the latest release of whatever distro you like. The kernel has have been built with the appropriate virtio-gpu Kconfig options though.

wget http://releases.ubuntu.com/17.10/ubuntu-17.10.1-server-amd64.iso
qemu-img create -f qcow2 ubuntu.qcow2 35G
qemu-system-x86_64 \
    -enable-kvm -M q35 -smp 2 -m 4G \
    -hda ubuntu.qcow2 \
    -net nic,model=virtio \
    -net user,hostfwd=tcp::2222-:22 \
    -vga virtio \
    -display sdl,gl=on \
    -boot d -cdrom ubuntu-17.10.1-desktop-amd64.iso

Run VM

qemu-system-x86_64 \
    -enable-kvm -M q35 -smp 2 -m 4G \
    -hda ubuntu.qcow2 \
    -net nic,model=virtio \
    -net user,hostfwd=tcp::2222-:22 \
    -vga virtio \
    -display sdl,gl=on

Et Voila! Your guest should now have GPU acceleration!


Hopefully this guide will have helped you to build all of the software needed to set up your very own virglrenderer enabled graphics stack.

Visit Robert's blog.

Comments (8)

  1. Kieran:
    Feb 13, 2018 at 11:01 AM

    Thanks for the write-up! What kind of overhead does this produce compared to running on host?

    Reply to this comment

    Reply to this comment

    1. Robert Foss:
      Feb 13, 2018 at 04:30 PM

      Hey Kieran!

      That's a good question, I haven't looked into the performance aspect.

      I would think that the performance impact is not too bad. But it would also depend on the application.
      An application that executes more OpenGL calls would see a larger impact.

      Reply to this comment

      Reply to this comment

  2. Ernst Sjöstrand:
    Feb 13, 2018 at 08:29 PM

    Nice! I uploaded packages for Ubuntu with virgilrenderer enabled to my ppa and wrote a few lines about it.... https://www.sabeltand.net/virgl/

    Reply to this comment

    Reply to this comment

    1. Robert Foss:
      Mar 09, 2018 at 03:08 PM


      I'm glad the post helps. Overall virgl is pretty painless to work with, which is nice.

      Reply to this comment

      Reply to this comment

  3. Stephen Lawrence:
    Mar 09, 2018 at 01:09 AM

    The Genivi automotive alliance is interested in the current support for GPU virtualisation in virtio as part of its project investigating graphics sharing between automotive domains [1]. It would be great to get Collabora's input.

    [1] https://at.projects.genivi.org/wiki/pages/viewpage.action?pageId=16024743

    Reply to this comment

    Reply to this comment

    1. Robert Foss:
      Mar 09, 2018 at 03:07 PM

      Thank you for commenting here Stephen.

      A proper reply requires more than the space available in the comment section here.
      Allow us to reach out directly. We will make sure to write a follow up post on our blog here when appropriate too.

      Reply to this comment

      Reply to this comment

      1. Stephen Lawrence:
        Mar 14, 2018 at 05:20 PM

        Thanks for the reply Robert and apologies for the slow response. I've been out of the office.

        OK understood and thanks for the interest.

        Whilst not trying to continue the conversation here I can outline why the post piqued my interest. Firstly a Hypervisor project has recently begun as part of the work on interaction between automotive domains. One of its goals is considering whether IO can be standardised further to ease h/w support. Of course virtio is a key technology there. There will be a HV workshop at the upcoming Genivi AMM in Munich April 17-19. Then there is the project looking at Graphics Sharing and Distributed HMIs. Stating the obvious but GPU virtualisation is interesting there when domains are consolidated onto powerful SoCs. So for both projects the current state and future roadmap of virtio-gpu support for automotive GPUs is interesting. There are HV experts participating in the HV project but given Collabora's depth of knowledge in both the linux gfx stack and h/w GPUs I personally think Collabora could bring a very useful viewpoint. Thanks for your consideration.

        Reply to this comment

        Reply to this comment

        1. Daniel Stone:
          Mar 14, 2018 at 06:14 PM

          Right, there's quite a few things to discuss in that space. Cross-domain graphics sharing is something we have a particular interest in - see our efforts with the Waltham project. virtio is definitely valuable, as an open cross-vendor standard which allows for different virtualisation implementations to be used. We think there's a lot of value in that compared to having every component support various proprietary interfaces, and that's something we'd be very happy to discuss.

          Reply to this comment

          Reply to this comment

Add a Comment

Allowed tags: <b><i><br>Add a new comment:

Latest Blog Posts

An overview of the Panfrost driver


During the past few months significant progress has been made on the Open Source Arm Mali GPU driver front, culminating in the Panfrost…

Quick hack: Raspberry Pi meets Linux kernel mainline


With just a few simple steps, you can compile and boot a Raspberry Pi using the Linux kernel mainline source code. Here's how.

News from the Debian Cloud Team


Since the last Debian release, a number of changes have been made in the Debian Cloud Team, both on the technical & organisational level…

Panfrost update: A new kernel driver


Following two months of work to develop a new kernel driver for Midgard and Bifrost GPUs, the kernel side of Panfrost is now in a form close…

Modern USB gadget on Linux & how to integrate it with systemd (Part 1)


A look at how to implement USB gadget devices on Linux machines which have the necessary UDC hardware, automate the manual configfs process…

FOSDEM 2019 - Recorded presentations (videos)


From the latest on Open Source projects Zink (OpenGL on Vulkan) and VirGL (virtual 3D GPU for QEMU), to a state of the union on GStreamer…

Open Since 2005 logo

We use cookies on this website to ensure that you get the best experience. By continuing to use this website you are consenting to the use of these cookies. To find out more please follow this link.

Collabora Ltd © 2005-2019. All rights reserved. Website sitemap.