Enable the VirtIO GPU 3D (Virgil)

[Thiago Martins]

Hello!

 Are you guys planning to enable VirtIO GPU 3D for QEmu 2.5 on Xenial?

 I'm seeing that Ubuntu 16.04 already have all dependencies to make it happen (I can be wrong)! Like Linux 4.4, Mesa 11.1 and QEmu 2.5.

 So, can it be enabled?

 Also, what are the side effects of enabling it? Will it break SPICE VDI Desktop? Or does it work okay alongside with SPICE?

Cheers!
Thiago

[Serge Hallyn (serge-hallyn)]

How is that enabled? I don't see anything about it in configure.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Thiago Martins (martinx)]

According to Wiki:

http://wiki.qemu.org/ChangeLog/2.5

It have "Build dependencies":

* virtio-gpu 3D support requires virglrenderer:

- http://cgit.freedesktop.org/~airlied/virglrenderer

Extra info:

https://virgil3d.github.io/

I think that we need to package virglrenderer first.

[Thiago Martins (martinx)]

Guys,

The build dependency, virglrenderer, have its own Git repository now:

https://cgit.freedesktop.org/virglrenderer

Cheers!
Thiago

[Thiago Martins (martinx)]

The virglrenderer is now on Debian! :-D

https://tracker.debian.org/pkg/virglrenderer

[Serge Hallyn (serge-hallyn)]

Thanks - that will need to be synced to ubuntu and the MIRd (depending on how exactly it is needed).

[GizmoChicken (gizmochicken)]

I'm also unable to use the VirtIO GPU 3D (Virgil) on Ubuntu 16.10.

Does this bug still apply to Ubuntu 16.10? Or is some other issue preventing me from using Virgil on Ubuntu 16.10?

My QEMU commands include the following:

    -vga virtio \
    -display gtk,gl=on \

When I try to start my VM using commands including the above, I get:

     qemu-system-x86_64: -display gtk,gl=on: GTK support is disabled

On the other hand, when OMIT "-display gtk,gl=on" from my commands (but still include "-vga virtio"), the VM starts up. But in that case, "dmesg | grep drm" on the guest reveals that, although "virtio-vga detected" is output, "virgl 3d acceleration not available" is also output.

My host is running Ubuntu 16.10 with all packages up-to-date, including the following:

     qemu (2.6.1+dfsg-0ubuntu5.3)
     libvirglrenderer0 (0.5.0-1)

I get the above when using Ubuntu 16.04, Ubuntu 16.10, and Ubuntu 17.04 as guests.

So, is VirtIO GPU 3D (Virgil) enabled in Ubuntu 16.10?

[GizmoChicken (gizmochicken)]

I've updated from 16.10, and my host is now running Ubuntu 17.04 with all packages up-to-date, including the following:

     qemu (2.8+dfsg-3ubuntu2)
     libvirglrenderer0 (0.5.0-2)

As mentioned in comment #7, my QEMU commands include the following:

    -vga virtio \
    -display gtk,gl=on \

And when I try to start my VM using commands including the above, I still get:

     qemu-system-x86_64: -display gtk,gl=on: GTK support is disabled

I'm not certain, but I think that, for the VirtIO GPU 3D (Virgil) to work, mesa must be compiled using the "--with-gallium-drivers=virgl" option. See https://wiki.archlinux.org/index.php/QEMU#virtio

So maybe the problem isn't with qemu, but instead with mesa being compiled without the "--with-gallium-drivers=virgl" option being set. Any thoughts?

[Thiago Martins (martinx)]

Mesa on Ubuntu 17.04 have VirGL!

---
user@ubuntu-1:~/sources/mesa/mesa-17.0.3/debian$ grep virgl . -r
./changelog: * Enable support for virgl (Closes: #807774).
./rules: GALLIUM_DRIVERS += nouveau svga virgl
---

Maybe there is a need to double check GPU drivers?

Let me know if it works for you!

Cheers!
Thiago

On 13 April 2017 at 18:28, GizmoChicken <email address hidden> wrote:

> I've updated from 16.10, and my host is now running Ubuntu 17.04 with
> all packages up-to-date, including the following:
>
> qemu (2.8+dfsg-3ubuntu2)
> libvirglrenderer0 (0.5.0-2)
>
> As mentioned in comment #7, my QEMU commands include the following:
>
> -vga virtio \
> -display gtk,gl=on \
>
> And when I try to start my VM using commands including the above, I
> still get:
>
> qemu-system-x86_64: -display gtk,gl=on: GTK support is disabled
>
> I'm not certain, but I think that, for the VirtIO GPU 3D (Virgil) to
> work, mesa must be compiled using the "--with-gallium-drivers=virgl"
> option. See https://wiki.archlinux.org/index.php/QEMU#virtio
>
> So maybe the problem isn't with qemu, but instead with mesa being
> compiled without the "--with-gallium-drivers=virgl" option being set.
> Any thoughts?
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1540692
>
> Title:
> Enable the VirtIO GPU 3D (Virgil)
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1540692/+subscriptions
>

[GizmoChicken (gizmochicken)]

Thanks! That's helpful information.

So after learning that mesa isn't the problem, I searched a bit more and found this related Debian bug report: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=839695

The submitter reports the same issue that I'm seeing, namely "GTK support is disabled" seen when attempting to using the "-display gtk" command.

The submitter requests that an alternate version of QEMU be built (using the "enable-gtk" option) and be made available in the repository under a distinct package name, such as qemu-gtk or similar.

As you can see from the report, the request seems to have been firmly rejected for the time being. So I imagine that the we'll see the same outcome here.

When I get a chance, I'll try to build QEMU using the "enable-gtk" option.

[Christian Ehrhardt  (paelzer)]

Hi - just my two cents trying to clarify a few things.

FYI there are two and a half road-blockers on the way to get this done.

#1 We don't need/want to divert from Debian for that, but there due to a lot of issues with virgl and being too late for the current release
  * Revert "enable virtio gpu (virglrenderer) and opengl support"
    Revert "switch from sdl1 to gtk3"
    Revert other gtk2/drm/vte/virgl-related changes
    Reopens: #813658, #839695
    The change were too close to stretch release and too large,
    bringing too much graphics stuff for headless servers,
    will re-think this for stretch+1.
    sdl1 back: Closes: #851509
    virtio-3d bugs: Closes: #849798, #852119

#2 most of the needed extra dependencies are not in main, so they will need to pass the MIR process [1]

#3 (the half one) at least recently virgl had a lot of security issues spiking the maintenance effort around it, so it seems not safe/mature enough yet. At least that will affect/deleay a positive security review.

What one could do right now is identifying the exact list of extra dependencies that this will create on qemu, check which are not in main yet and add them as [MIR] bug tasks here.
That as a prep for when Debian makes the switch, otherwise we will have to opt out of that until all dependencies are in main.

[1]: https://wiki.ubuntu.com/MainInclusionProcess

[Thiago Martins (martinx)]

Aaah... That's sad... Maybe for Ubuntu 18.04! :-D

On 23 May 2017 at 15:09, ChristianEhrhardt <email address hidden>
wrote:

> Hi - just my two cents trying to clarify a few things.
>
> FYI there are two and a half road-blockers on the way to get this done.
>
> #1 We don't need/want to divert from Debian for that, but there due to a
> lot of issues with virgl and being too late for the current release
> * Revert "enable virtio gpu (virglrenderer) and opengl support"
> Revert "switch from sdl1 to gtk3"
> Revert other gtk2/drm/vte/virgl-related changes
> Reopens: #813658, #839695
> The change were too close to stretch release and too large,
> bringing too much graphics stuff for headless servers,
> will re-think this for stretch+1.
> sdl1 back: Closes: #851509
> virtio-3d bugs: Closes: #849798, #852119
>
> #2 most of the needed extra dependencies are not in main, so they will
> need to pass the MIR process [1]
>
> #3 (the half one) at least recently virgl had a lot of security issues
> spiking the maintenance effort around it, so it seems not safe/mature
> enough yet. At least that will affect/deleay a positive security review.
>
> What one could do right now is identifying the exact list of extra
> dependencies that this will create on qemu, check which are not in main yet
> and add them as [MIR] bug tasks here.
> That as a prep for when Debian makes the switch, otherwise we will have to
> opt out of that until all dependencies are in main.
>
> [1]: https://wiki.ubuntu.com/MainInclusionProcess
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1540692
>
> Title:
> Enable the VirtIO GPU 3D (Virgil)
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1540692/+subscriptions
>

[Ernst Persson (ernstp)]

I uploaded some packages to my ppa if anyone wants to test: https://launchpad.net/~ernstp/+archive/ubuntu/virgl
Works really well in my opinion!

[Gannet (ken20001)]

It's so sad but still no possibility to use virgl in 18.04.

[RussianNeuroMancer (russianneuromancer)]

@Ernst Sjöstrand

Could you please upload packages for 18.04?

[salemboot (salemboot)]

Ernst how did you get around rebuilding spice?

[Thiago Martins (martinx)]

Looks like that the bug report on Debian was fixed:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=839695

I'll also try the Ernstp's PPA.

[Christian Ehrhardt  (paelzer)]

Hi Thiago,
FYI AFAIK the latter only re-enabled gtk, not virgil.

[GizmoChicken (gizmochicken)]

Hi Christian,

I notice that you and Serge Hallyn are members of the “Ubuntu Virtualisation” team. See https://launchpad.net/~ubuntu-virt/+members

I'm curious. Is the “Ubuntu Virtualisation” team still active on launchpad?

As you point out, diverging from Debian in the official repositories probably isn't a good idea. But would the “Ubuntu Virtualisation” team consider maintaining a semi-official "qemu-testing" ppa from which recently released versions of QEMU could be installed? Ideally, the ppa would offer a version of QEMU that includes support for VirtIO GPU 3D (Virgil) and as well as other recent QEMU features, such as the user-space bits for Intel vGPU acceleration support, etc.

Honestly, I'm not quite sure what I mean by "semi-official 'qemu-testing' ppa" as requested above. But I'm thinking maybe something similar to "ppa:graphics-drivers" that, although "currently in testing" according to the maintainers, is a fairly reliable source of drivers that aren’t found in the official Ubuntu repositories.

[Christian Ehrhardt  (paelzer)]

Hi,
Once in a time there was [1] done manually. It bit-rot, so it was given up.

After a while I resurrected it via [2] + [3] in a semi automatic fashion.
And I suggested to use it in various bug verifications and such.
But after half a year it turned out to be unused still and not worth the effort (even with automation in place it is work to keep things building).

Given this history I'd help community members to enable it again based on my work back then [2]/[3]. But my own trust in the worth of it has vanished, so I'm not trying on my own atm.

And that pretty much is what paragraph #1 in [1] summarizes.

[1]: https://launchpad.net/~ubuntu-virt/+archive/ubuntu/virt-daily-upstream
[2]: https://help.launchpad.net/Packaging/SourceBuilds/Recipes
[3]: https://code.launchpad.net/~ubuntu-virt/+git

[Christian Ehrhardt  (paelzer)]

FYI I saw some movement in Debian, so they might try once again to include it, hopefully it fails less than last time.
If it happens to be able to follow them (or if we don't share the same issues to go ahead) we need MIR in bug 1657409 resolved which seems to me as it would have become dormant.

I pinged there to get an update on the security eval.

[Thiago Martins (martinx)]

YAY! This is finally ready on Ubuntu 18.04 with Ubuntu Cloud Archive Stein! :-D

Just do:

    sudo add-apt-repository cloud-archive:stein
    sudo apt update
    sudo apt full-upgrade

And enjoy a 3D Enabled QEMU 3.1 on Ubuntu 18.04!

It's AWESOME!

Likely that it's also enabled by default on Ubuntu 19.04 but, I didn't test it.

[Thiago Martins (martinx)]

Unfortunately, the text console is just black.

But both Ubuntu desktops are working! The regular one, and the one based on "Wayland".

Which is huge anyway!

Any idea about how to fix the text-only black console?

[Christian Ehrhardt  (paelzer)]

Yeah 19.04 has the same support - thanks for remimding me of this old bug Thiago!

[Christian Ehrhardt  (paelzer)]

As expected there was more work for the auxiliary coding (get virtglrenerer MIR approved, get it to work with apparmor cleanly, ... than the actual enabling).

For your black screen issue, I have not seen that one so far (but a bunch of others issues which so far all were tied to my experimental system setup). You could open a new bug describe as much about the setup and steps to reproduce and I can take a look.

[Jo-Erlend Schinstad (joerlend.schinstad-deactivatedaccount)]

Very nice to finally have VirGL available on Ubuntu 19.04. SDL is not available, though. GTK works, but it has some quirks that SDL doesn't. Does anyone know why SDL isn't available?

[Christian Ehrhardt  (paelzer)]

Hi Jo-Erlend,
as you know there are two SDL versions out there.
- 1.2 is deprecated and was since Ubuntu 18.10 no more in main, so it was no option anymore
- 2.0 OTOH was too new and had too much (many more than GTK at the time) issues with qemu.
  You see that in the qemu changelog:
  - sdl2 is yet too unstable for the LTS Ubuntu release given the reports
    we still see upstream and in Debian - furthermore sdl2 isn't in main yet,
    so we revert related changes to stick with the proven for now:
    - 0fd25810 - do not build-depend on libx11-dev (libsdl2-dev already
                 depends on it)
    - 9594f820 - switch from sdl1.2 to sdl2 (#870025)
=> In Bionic we changed from SDL2 to SDL1.2 to avoid the issues
=> In Cosmic and later Debian and Ubuntu switched to GTK instead which worked much better (despite the quirks)

AFAIK sdl2 is not in main right now, so it is still now option to be enabled instead or in addtion. We'd need a strong use case or issue to spend all the work, it seems across Distros that GTK is the way to go here.

I hope that explained your question - if not please open a new bug for it to keep this one here clear.

[Thiago Martins (martinx)]

Hey guys!

This is an awesome version of QEMU and I can use Virgil 3D (vGPU within QEMU Guests works ok) with the native Linux `radeon` driver.

However, if I try to install the AMDGPU-19.03 drivers, it completely breaks QEMU!

AMDGPU-19.30:

https://www.amd.com/en/support/kb/release-notes/rn-amdgpu-unified-navi-linux

It breaks QEMU on Ubuntu 18.04.2 + Stein UCA Repo!!!

I also tried the previous AMDGPU versions, same results.

Here is the error after installing amdgpu:

https://paste.ubuntu.com/p/35Mtqrsd3n/

How to repeat:

Here is what I do:

1- Install Ubuntu 18.04.2 (with HWE for Kernel and XOrg);
2- Enable UCA with `sudo add-apt-repository cloud-archive:stein`;
3- Install `qemu-vkm`, `virt-manager`, and etc;
4- You'll be able to create a QEMU Guest using Virgil 3D using the Linux `radeon` module! It's awesome.
5- Install AMDGPU-19.30 (or any other previous version), for an even more awesome QEMU? Let's see!
6- No deal, after installing AMDGPU drivers, no more QEMU!

Any idea about how to fix this? Is this an amdgpu limitation? Any idea if QMEU with Virgil 3D with it someday (or this isn't in the master plan)?

Cheers!

[Christian Ehrhardt  (paelzer)]

Hi Thiago,
I'm glad that you are happy about the change in general.
I lack the amd gpu to test it myself, but IMHO it would surely be:
a) test it on the very latest as things are still changing a lot (Ubuntu 19.10 at the time)
b) discuss things in a new bug, as the bug here "add virtgl" is resolved
c) maybe best to discuss upstream as well, as there might be more others with the right setup already working (or knowing why not).

You can file a bug on LP against (upstream) "Qemu" and add an Ubuntu task as well.
So you'd have one place for the combined discussion.