We're hiring!
*

GPU virtualization update

Elie Tournier avatar

Elie Tournier
May 09, 2018

Share this post:

A few months ago, Robert Foss wrote a blog post about virtualizing GPU Access. In his post, Robert explained the architecture of the GPU virtualization stack and, how to build and run a VM with hardware acceleration.

If you are interested by the GPU virtualization topic, I suggest you read Robert’s post.

Today, I will discuss the major improvements which landed upstream during these pasts 3 months.

tl;dr:

  • QEMU can now use OpenGL ES acceleration.
  • Virglrenderer is close to be OpenGL ES 2.0 compliant.
  • We are still working on OpenGL ES 3.0.

For each component of the stack, I will explain the added modifications and our plan for the future.

Virglrenderer

At Collabora, we have been working as part of the upstream community to add new features and improve the code base.

Most of our work consisted in adding more caps to support OpenGL ES 3.0 on OpenGL ES and to find some workarounds for the missing OpenGL ES features. For example, OpenGL ES does not support 1D texture so we have to use a 2D texture with one of the component set to 0.5.

On my system, KabyLake with Mesa 18.0, I obtained the following results:

  • Android OpenGL ES 2.0 CTS on OpenGL backend: 4 failures
  • Android OpenGL ES 2.0 CTS on OpenGL ES backend: 4 failures
  • Android OpenGL ES 3.0 CTS on OpenGL backend: 40 failures
  • Android OpenGL ES 3.0 CTS on OpenGL ES backend: ~2400 failures

The OpenGL ES 2.0 CTS failures seems to be driver related. The tests fail on my system but pass on r600.

The difference between OpenGL ES 3.0 results might seem scary but a single fix should take care of it. These failures are due to the fact that we don't support reading back results from integer (as opposed to floating-point) rendering, so all the tests for integer formats fall.

QEMU

Status

We can, since 4867e47, create an OpenGL ES context. Thanks to this, we can now run QEMU on a system that only supports OpenGL ES.

Running QEMU on an OpenGL ES backend.

If you want to try it out, you can follow the guide from Robert’s blog. The only difference is the command line to run the WM, you just need to replace -sdl,gl=on by -sdl,gl=es.

So it will become:

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=es

Others flags are also available:
-sdl,gl=core Force to create an OpenGL context.
-sdl,gl=on Try to create an OpenGL context and if it fails, we fallback and try to create an OpenGL ES context.
-sdl,gl=off Disable the hw acceleration.

Continuous Integration

Tomeu Vizoso initiated an effort to create a CI for Virglrenderer. The CI is hosted on Freedesktop.org but validation is limited. We only check that we were able to compile virglrenderer and that the dist-check passes.

The code for the CI is available here.

What’s next?

  • One of our long-term goals is to be compliant with the current OpenGL ES specification.
  • We also want to improve CI. We currently check that we are able to compile Virglrenderer and that the basic testsuite passes. The next step will be to run the Khronos Conformance Test Suite and/or Piglit. Virglrenderer is now being used in big projects so we need to make sure that new patches don’t introduce any regressions.
  • Security improvements. One of the main reasons to use containers is the process isolation. A bad implementation can cause leaks, give access to some unautorized components or even worse, crash the host system and lose all the advantage of process isolation. One of the solutions disscused with upstream is to use a memory safe programming language like Rust. We are still in discution. See this thread.
  • Performance and debugging improvements.

Thanks

This post has been a part of work undertaken by my employer Collabora.


Visit Elie's blog.

Comments (2)

  1. Salvador:
    Apr 03, 2019 at 10:52 PM

    Hi, i am on rpi3 with mesa 19. It has full opengl capabilities, or sorta. The fact its than i could compile virgl render 0.6 and enabling it and it works, the problem its than i cant set gl=on becase it fails on shader profile, it ask to be 3.0. So, the question is, I need to have opengl on to have opengl acceleration or with virgl render only I have the acceleration. Its weird than qemu pass on compiling with opengl and glx but it dindt work when you set it. It should refuse opengl es profiles lower than 3.0

    Reply to this comment

    Reply to this comment

    1. Elie Tournier:
      Apr 04, 2019 at 03:04 PM

      Hello Salvador,

      You already open issues[1][2] on the project GitLab.
      We are happy to help you but please keep all the information/discussion in on place.

      Unfortunately, the output you just pasted indicate that your system doesn't fulfil the minimum requirement for running virgl.

      Elie

      [1] https://gitlab.freedesktop.org/virgl/virglrenderer/issues/96
      [2] https://gitlab.freedesktop.org/virgl/virglrenderer/issues/101

      Reply to this comment

      Reply to this comment


Add a Comment






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


Search the newsroom

Latest Blog Posts

Using syzkaller, part 4: Driver fuzzing

26/06/2020

Syzkaller is much needed tool for Linux kernel testing and debugging. With some work, it can also be enhanced to find bugs in specific drivers,…

Cross building Rust GStreamer plugins for the Raspberry Pi

23/06/2020

Previously, we discussed about how Rust can be a great language for embedded programming. In this article, we'll explain an easy setup to…

Generating MPEG-DASH streams for Open Source adaptive streaming with GStreamer

12/06/2020

Adaptive streaming is a technique to provide flexibility and scalability by offering variable bit-rate streams to the client. Here's a quick…

Bifrost meets GNOME: Onward & upward to zero graphics blobs

05/06/2020

With only free software, a Mali G31 chip can now run Wayland compositors with zero-copy graphics, including GNOME 3. We can run every scene…

Using regmaps to make Linux drivers more generic

27/05/2020

Device drivers can support more revisions and SoC platforms by abstracting away specific hardware interface layouts. Let's examine a specific…

Cross-compiling with gst-build and GStreamer

15/05/2020

gst-build is one of the main build systems used by the community to develop the GStreamer platform. In my last blog post, I presented gst-build…

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-2020. All rights reserved. Privacy Notice. Sitemap.