VirtIO-GPU Vulkan Driver Looks To Go Upstream In Mesa

[leipero]

I know that it is early version of Linux VirtIO-GPU Vulkan Driver, but let me dream a little bit about Windows support

Windows version of VirtIO-GPU Vulkan Driver + DXVK means DirectX9/10/11 support in Windows VM without GPU passthrough!

And if virglrenderer is anything to go by, you will be left with that dream. It's in terrible shape, there's no proper Windows support, and it have tons of bugs and rendering issues,

zexelon
Use QEMU, it should work, if you experience rendering issues, downgrade to the 0.7.0 version and symlink it with libvirglrenderer.so.1 (if needed, depending on the QEMU version), it should work semi-decently afterwards.

[zexelon]

zexelon
Use QEMU, it should work, if you experience rendering issues, downgrade to the 0.7.0 version and symlink it with libvirglrenderer.so.1 (if needed, depending on the QEMU version), it should work semi-decently afterwards.

Unfortunately I have tried qemu also and its the exact same issue. I have qemu 5.0 installed and nothing will render using virtio-gpu with 3D enabled. Everything appears to boot properly but nothing is ever displayed, not even the bios/efi load screens... total black screen.

This is pretty much my exact issue: https://bbs.archlinux.org/viewtopic.php?id=254271

Unfortunately the qemu version on Pop_OS 20.10 does not appear to have been compiled with SDL support so I can not test that aspect. I can confirm that the GTK front end is black screen only.

[oiaohm]

Alas in the end I cant get virtio-gpu to work at all on my machines. All I get is a black screen in the viewer... have tried both virt-manager, and qemu-gtk. Based on a ton of digging it looks like it may be an Nvidia driver issue. The VM appears to boot just fine but no display after enabling virtio-gpu with 3D acceleration. The machine is still reachable via the network. Seen a couple of bug reports about this over the last several months, and the only commonality I can see is Nvidia hardware.

Nvidia drivers have a lot of annoying quriks. Like until recently you are running two X11 servers on two different TTY when you would switch between them the X11 server that lost monitor connection would have its opengl/vulkan processing completely stopped when using Nvidia closed source drivers. The new drivers opengl/vulkan will processed on the off screen render just slower when using consumer level GPUs.

Zexelon need to check if it all the same kind of Nvidia gpu as well like all geforce cards as that would be consumer. Nvidia has been restricting stuff on consumer cards for quite some time that is not linked to hardware capability.

[Quackdoc]

And if virglrenderer is anything to go by, you will be left with that dream. It's in terrible shape, there's no proper Windows support, and it have tons of bugs and rendering issues,

zexelon
Use QEMU, it should work, if you experience rendering issues, downgrade to the 0.7.0 version and symlink it with libvirglrenderer.so.1 (if needed, depending on the QEMU version), it should work semi-decently afterwards.

To be fair, there was little reason to do so in the first place. Virgl renderer is cool and all, but that is about it. gl preformance wasn't really good enough to do anything worth while in the first place. if you were doing any real work, you would be using some kind of gpu passthroughm whether it be SR-IOV/vGPU, or if you didn't need that kind of preformance, you would just use qxl or vmware gpu.

Now there is real incentive to make the program good, especially with google wanting it for commercial purposes, where as virgl was always a cool but kinda pointless thing. so there at the very least is incentive to make it better now, then what it was before.

Microsoft has a degree of incentive too, as this will allow them to have gpu accelerated virtual machines running under a linux host, without them needing to open source the GPU-PV host junk. and with the work they are doing to get hyper-v able to run on a linux host, I personally don't see much demerit for them, but do see plenty of benefit.

[fdelapena]

Regarding virtio-gpu on Windows guests, take a look to:

https://www.phoronix.com/forums/forum/software/distributions/1247581-rhel-8-4-bringing-virtio-gpu-support-on-windows-guest-drivers

[Mario Junior]

Alas in the end I cant get virtio-gpu to work at all on my machines. All I get is a black screen in the viewer... have tried both virt-manager, and qemu-gtk. Based on a ton of digging it looks like it may be an Nvidia driver issue. The VM appears to boot just fine but no display after enabling virtio-gpu with 3D acceleration. The machine is still reachable via the network. Seen a couple of bug reports about this over the last several months, and the only commonality I can see is Nvidia hardware.

Same problem with AMD gpus.

[leipero]

Unfortunately I have tried qemu also and its the exact same issue. I have qemu 5.0 installed and nothing will render using virtio-gpu with 3D enabled. Everything appears to boot properly but nothing is ever displayed, not even the bios/efi load screens... total black screen.

This is pretty much my exact issue: https://bbs.archlinux.org/viewtopic.php?id=254271

Unfortunately the qemu version on Pop_OS 20.10 does not appear to have been compiled with SDL support so I can not test that aspect. I can confirm that the GTK front end is black screen only.

&@allhavingissuewithablackscreen
All you have to do to wrok around that issue is, in virt-manager, when you start your VM and get the black screen, (force) shut down VM but do not close the VM window, then start it again from that window, it should work, try it.
Alternatively, don't use spice (I think that's the issue, didn't test it extensively), use quemu options (change sdl to gtk, it shouldn't matter):
-vga virtio -display sdl,gl=on

Or search my username on github (same as here) and you have a script that willl create VM for you, if you do so, temporary disable IOMMU in UEFI/BIOS because script detects if it's enabled and does try to modify bootloader options (for passthrough), if it's disabled, it will not do that.

[leipero]

To be fair, there was little reason to do so in the first place. Virgl renderer is cool and all, but that is about it. gl preformance wasn't really good enough to do anything worth while in the first place. if you were doing any real work, you would be using some kind of gpu passthroughm whether it be SR-IOV/vGPU, or if you didn't need that kind of preformance, you would just use qxl or vmware gpu.

Now there is real incentive to make the program good, especially with google wanting it for commercial purposes, where as virgl was always a cool but kinda pointless thing. so there at the very least is incentive to make it better now, then what it was before.

Microsoft has a degree of incentive too, as this will allow them to have gpu accelerated virtual machines running under a linux host, without them needing to open source the GPU-PV host junk. and with the work they are doing to get hyper-v able to run on a linux host, I personally don't see much demerit for them, but do see plenty of benefit.

True, it's actually good for Linux guests, performance are near native (at least for DEs etc.), granted, for some professional work, Windows and if you need GPU features, it's next to useless.

[zexelon]

leipero Unfortunately your suggestions do not seem to work, at least not on the Nvidia card I have. So far the issues wrt Nvidia seem to be on 1000 series and up cards based on the bug reports I have seen, and my personal experience.

I have tried all of the following:
1) Virt-Manager Spice
2) Qemu GTK
3) Qemu SDL <-- this last one does not work on Ubuntu 20.04/20.10 systems as they do not compile with SDL support

I have heard hints that SDL may work on Nvidia, but I would have to recompile qemu for that, and its not worth it for me.

[WorBlux]

All of this because AMD and Nvidia don't want to provide hardware virtualization. Hopefully Intel will put an end to this behaviour.

Partly that, and partly the fact that the traditional GPU virtualization doesn't fit too well into desktop. Both AMD and Nvidia solutions involve static partition of resources.

Intel does have a paravirtualization solution GVT-s which seems ideal if not under-developed for destkop virtualization.