3D OpenGL Acceleration For Windows Guests On QEMU Using VirGL/VirtIO

[phoronix]

Phoronix: 3D OpenGL Acceleration For Windows Guests On QEMU Using VirGL/VirtIO

While there has been VirGL as one of the options for allowing 3D/OpenGL acceleration of Linux guests within QEMU/KVM virtual machines to allow the calls to be directed to the host system's OpenGL driver, that support hasn't been available when Windows is running as QEMU/KVM guest. That is changing though thanks in large part to this year's Google Summer of Code...

http://www.phoronix.com/scan.php?page=news_item&px=QEMU-3D-Windows-Guests

[s_j_newbury]

It must be possible to utilize the existing Mesa/Gallium code for some of this. The Windows code in Mesa/Gallium doesn't get any love mainly because there is no interest in running open drivers under windows, but this would be the ideal use for it. Ideally it would even be possible to use gallium-nine to implement d3d9 support.

[shmerl]

How can it be enabled on Debian (testing / Sid)? I never managed to enable virgl there even for Linux guests. It would have been nice to be able to use something like SR-IOV to have a normal accelerated desktop in Linux guests, and avoid this whole mess, but it looks like AMD don't plan to support it in consumer cards.

UPDATE: Looks like there is some progress after all: https://bugs.debian.org/cgi-bin/bugr...?bug=849569#55

[GizmoChicken]

How can it be enabled on Debian (testing / Sid)? I never managed to enable virgl there even for Linux guests. It would have been nice to be able to use something like SR-IOV to have a normal accelerated desktop in Linux guests, and avoid this whole mess, but it looks like AMD don't plan to support it in consumer cards.

UPDATE: Looks like there is some progress after all: https://bugs.debian.org/cgi-bin/bugr...?bug=849569#55

It has been several months since the last time that I tried Virgl on Debian or Ubuntu, but if I recall correctly, the QEMU available from the repositories for those distributions didn't yet support Virgl. For example, when I last tried to start a VM using commands including "-vga virtio" and "-display gtk,gl=on" (which I think are needed for Virgl), I got:

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

Debian Bug #839695 discusses a request to "build qemu with –enable-gtk" support. And Ubuntu Bug 1540692 discusses a request to support Virgl on Ubuntu. And so, as of now, Virgl support seems to be on the "wishlist" for both distributions (unless you are willing to compile QEMU yourself using the needed options).

But I hope that I'm wrong. If anyone has gotten Virgl to work on Debian or Ubuntu using the version of QEMU available from the repositories for those distributions, I hope to hear about it.

[shmerl]

As I linked above, it requires newer version of spice to work, which didn't arrive in Debian (but should soon). So Qemu alone won't help.

[GizmoChicken]

As I linked above, it requires newer version of spice to work, which didn't arrive in Debian (but should soon). So Qemu alone won't help.

But even once the newer version of spice arrives, the versions of QEMU available from the Debian/Ubuntu repositories still won't support Virgl soon. Does that seem correct? If correct, then it seems that multiple puzzle pieces still need to fall into place. Again, I hope that I'm wrong, and if I am, I hope someone will correct me here.

[shmerl]

But even once the newer version of spice arrives, the versions of QEMU available from the Debian/Ubuntu repositories still won't support Virgl soon. Does that seem correct? If correct, then it seems that multiple puzzle pieces still need to fall into place. Again, I hope that I'm wrong, and if I am, I hope someone will correct me here.

Yes, looks like it. Qemu was updated to support virgl, but then reverted back in Debian because "server" people complained about unwanted dependencies. Quite a mess. So this work needs to be redone now and packages somehow refactored.

[Keenuts]

Hi,

To actually test it, you may need to recompile QEMU to enable your SDL, virgl and other feature support. Along with, you'll need to compile VirGL if not available from official repositories.
I run my VMs on Archlinux, and you might be able to do so on Debian too.
Here is a link to David Airlie's blog, with some tips about how to enable VirGL (I had to use the SDL trick on arch)

https://www.kraxel.org/blog/tag/virgl/

[s_j_newbury]

I wrote a comment that seems to have disappeared, and I'm pretty sure I've brought this up before, but it must be easier to port the VirGL Mesa/Gallium driver to work on windows/qemu than to write a new OpenGL state tracker from scratch. Ideally, it would also be able to provide at least d3d9 support through gallium-nine and maybe give an impetus to resurrect and complete the d3d1x code.

The Windows Mesa/Gallium code is sitting there pretty much bit-rotting away since there's apparently no interest in open drivers on Windows.

[cb88]

I wrote a comment that seems to have disappeared, and I'm pretty sure I've brought this up before, but it must be easier to port the VirGL Mesa/Gallium driver to work on windows/qemu than to write a new OpenGL state tracker from scratch. Ideally, it would also be able to provide at least d3d9 support through gallium-nine and maybe give an impetus to resurrect and complete the d3d1x code.

The Windows Mesa/Gallium code is sitting there pretty much bit-rotting away since there's apparently no interest in open drivers on Windows.

That... is exactly what they are doing. I'm not sure how you missed that... Actually you may be right. If that is the case.. I'm very supprised as that would mean it is a largely wasted effort that will likely end up bittrotting itself.