Discussion:
VirtIO-GPU 3D OpenGL Hardware Acceleration for VMs
Saket Sinha
2016-02-15 02:34:18 UTC
Permalink
Hi,

It seems upstream Linux/Gallium3D/Mesa/Qemu/KVM has recently gained
virtualized support for 3D/OpenGL hardware acceleration in VMs,
allowing using the GPU of the host in VMs.

As per my understanding the following components are needed -

- Linux 4.4 kernel includes the DRM driver for VirtIO-GPU 3D
acceleration (needed in the VM).
- Qemu 2.5 includes the VirtIO-GPU 3D mode support.
- Gallium3D VirGL driver is included in Mesa git (needed in the VM,
supports up to OpenGL 3.3 atm).
- On the host *any* OpenGL driver (for the host GPU obviously), no
special requirements there.

In order to do test this, if I can be guided as to what are the right
applications to test the entire Graphic stack on a QEMU-KVM Virtual
machine, I shall be grateful.






Regards,
Saket Sinha
David Airlie
2016-02-15 02:47:05 UTC
Permalink
----- Original Message -----
Sent: Monday, 15 February, 2016 12:34:18 PM
Subject: VirtIO-GPU 3D OpenGL Hardware Acceleration for VMs
Hi,
It seems upstream Linux/Gallium3D/Mesa/Qemu/KVM has recently gained
virtualized support for 3D/OpenGL hardware acceleration in VMs,
allowing using the GPU of the host in VMs.
As per my understanding the following components are needed -
- Linux 4.4 kernel includes the DRM driver for VirtIO-GPU 3D
acceleration (needed in the VM).
- Qemu 2.5 includes the VirtIO-GPU 3D mode support.
In qemu 2.5 only gtk3 frontend support 3D and must be enabled with gl=on
- Gallium3D VirGL driver is included in Mesa git (needed in the VM,
supports up to OpenGL 3.3 atm).
- On the host *any* OpenGL driver (for the host GPU obviously), no
special requirements there.
In order to do test this, if I can be guided as to what are the right
applications to test the entire Graphic stack on a QEMU-KVM Virtual
machine, I shall be grateful.
glxinfo in the guest should print virgl in the renderer string, that is enough
to know the stack is functioning.

if it shows llvmpipe it isn't.

Dave.
Andrew Randrianasulu
2016-02-17 07:10:32 UTC
Permalink
Hello!

I tried to test virtGL on nouveau, and found few surprizes.

First, new quemu (commit commit a5af12871fd4601c44f08d9e49131e9ca13ef102, Merge
remote-tracking branch 'remotes/sstabellini/tags/xen-2016-02-12' into staging)
failed to link wih gcc 4.9 if I specified -march=i486, switching to -march=i686
fixed this. I found this solution while search for specific error message:
http://stackoverflow.com/questions/23065501/stdatomicunsiged-long-long-undefined-reference-to-atomic-fetch-add-8
error message in my case was "undefined reference to `__atomic_load_8' "

Second, I found my Xserver (1.12.4 patched with some patches from later
Xservers, excluding most of glx stuff) was too old, for host side. Qemu just
crashed at the moment guest loaded drm driver. Upgrading to 1.18.1 fixed this,
but I assume anything from 1.13.0 should be minimally enough ? (due to
GLX_ARB_create_context, GLX_ARB_create_context_profile stuff)

Next, I found even 1.18.1 by default builds without glamor support. There was
configure swicth --enable-glamor, but it was, unlike dri3 stuff, off by
default. Switching it on allowed guest to finally have 3d as in working
glxinfo. glxgears still segfaulted. making /dev/shm user (ok, world-) writable
fixed this. Found by strace-ing glxgears, and launching glxgears from root,
where it worked. DRI3 stuff on host, where I also tried it, segfaulted
similary, but I can live with DRI2/EXA here, especially because nouveau still
have issues with glamor/modesetting, on both nv50, and nvc0, as I was told on
#nouveau.

I also tried few MESA debug environment variables in attttempt to get rid of
artefacts inside VM, but sadly they remained there.


ESA_EXTENSION_MAX_YEAR=2001 ./x86_64-softmmu/qemu-system-x86_64 -cdrom /home/admin/slaxdvd-4.5.0-x64-test.iso -m
512 -display sdl,gl=on -enable-kvm -soundhw es1370 -usb -vga virtio -usbdevice
mouse -cpu host

for example not resulted in any improvements.

MESA_GL_VERSION_OVERRIDE=3.0 and any version below (on host) resulted, like with
old X server, in crashed qemu:

gl_version 0 - compat profile
WARNING: running without ARB robustness in place may crash
qemu-system-x86_64: Couldn't find current GLX or EGL context.

(note gl_version 0 thing - libepoxy bug? I use 1.3.1)

So, I assume right now host 3D driver must support OpenGL 3.1 or up?

Image links:
http://ibin.co/2XC09wl34cuT
http://ibin.co/2XCIj5vhR9l8

#nouveau log from 16-02-2016:
https://people.freedesktop.org/~cbrill/dri-log/index.php?channel=nouveau&date=2016-02-16

I hope it will help someone!
Chih-Wei Huang
2016-03-24 07:41:31 UTC
Permalink
Post by Saket Sinha
It seems upstream Linux/Gallium3D/Mesa/Qemu/KVM has recently gained
virtualized support for 3D/OpenGL hardware acceleration in VMs,
allowing using the GPU of the host in VMs.
As per my understanding the following components are needed -
- Linux 4.4 kernel includes the DRM driver for VirtIO-GPU 3D
acceleration (needed in the VM).
- Qemu 2.5 includes the VirtIO-GPU 3D mode support.
- Gallium3D VirGL driver is included in Mesa git (needed in the VM,
supports up to OpenGL 3.3 atm).
- On the host *any* OpenGL driver (for the host GPU obviously), no
special requirements there.
In order to do test this, if I can be guided as to what are the right
applications to test the entire Graphic stack on a QEMU-KVM Virtual
machine, I shall be grateful.
If you are interested to test Android on QEMU
with 3D hardware acceleration (via virgl, of course),
here is an ISO you can test:

http://www.fosshub.com/Android-x86.html/android-x86-6.0-20160318.iso

The command to run QEMU

qemu-kvm -smp 2 -m 2048 \
-device virtio-gpu-pci,virgl -display gtk,gl=on \
-d guest_errors \
-serial mon:stdio \
-cdrom android-x86-6.0-20160318.iso


It's built with kernel 4.4.4 and Mesa 11.2.0-rc3.
If you'd like to build the ISO yourself, please read
https://sourceforge.net/p/android-x86/wiki/Downloading%20and%20Building/
--
Chih-Wei
Android-x86 project
http://www.android-x86.org
Loading...