VirtIO-GPU Vulkan Driver Looks To Go Upstream In Mesa

[zexelon]

WorBlux Heck I would take course grain partitioning at this point! If I could split up my 3090 into 2 or maybe 3 cards, and arbitrarily assign outputs to these partitions that would be amazing!

I am sure any GPU engineer reading this is cringing at the changes required for such a concept. But hey, its easy for me to say, I have no idea how hard it is to implement

[nxij]

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. ...

Virgl is actually great for driving user interfaces at native feeling speeds. Linux distros and even Android vms with virgl support run their interfaces at 60fps without feeling like VNC.
For Windows guests one would require a dx11 passthrough or emulation of sorts, vmware actually does this and is able to run the Windows desktop with dwm at a native feeling 60fps framerate and its great for that, it would be great to have some sort of a guest driver that does dx11 on guest side through hosts Vulkan on qemu aswell.

The performance for heavier tasks though is not up to par or not even close to native sadly, but that is already something else.

[leipero]

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.

I see, well, I can speak only about AMD hardware and Mesa. I do get black screen on the first run when using virt-manager, forcing shutdown of the VM while keeping window open and starting it again does seem to work. As fot your issue, you may want to try Jacob Zimmermann's PPA, after quick search I've found that repository:

https://launchpad.net/~jacob/+archive/ubuntu/virtualisation

Not sure if it would work on Pop_OS, if I remember correctly it's Ubuntu based, so..., it should. So no need to compile anything to test, I do find it strange that it's not compiled with sdl, that's quite odd choice.

[zexelon]

leipero I agree not compiling with SDL is a very odd choice, but I found quite a bit of chatter with the Ubuntu managers and they chose to drop support for SDL in qemu in their main repos after I think it was 18.04.

Thanks for the pointer I will look at that PPA, yes Pop_OS is Ubuntu based so if it works for Ubuntu typically it will work just fine for Pop_OS.

[Quackdoc]

Virgl is actually great for driving user interfaces at native feeling speeds. Linux distros and even Android vms with virgl support run their interfaces at 60fps without feeling like VNC.
For Windows guests one would require a dx11 passthrough or emulation of sorts, vmware actually does this and is able to run the Windows desktop with dwm at a native feeling 60fps framerate and its great for that, it would be great to have some sort of a guest driver that does dx11 on guest side through hosts Vulkan on qemu aswell.

The performance for heavier tasks though is not up to par or not even close to native sadly, but that is already something else.

That and really old linux games is about all it is useful for though, of course it is useful to a degree. but to what degree? I can't think of very many use cases that would greatly benefit from flushing it out in its current state. Opengl is just too limited on what you can do with it to get a large ammount of preformance. compare that with the... mostly usable state of it, (from my testing it is great for distro testing). I dont really see that much incentive. making window drivers... kind of, I can see a small degree of benefit. but nothing more than it being worth a side project. Vulkan on the otherhand can completely change this.

Thankfully it shouldn't be to hard, assuming the vulkan and opengl drivers can be made for windows, Directx can be done to a... competent degree using DXVK and WineD3D I believe. but I haven't tested it yet, though do plan to do so, Running everything under DXVK and WineD3D

[nxij]

Vulkan on the otherhand can completely change this.

Not so sure about it, OpenGL inherently isnt really that limited, virgl in this sense would be slowed down by the overhead in the graphics translation stack, if one could bypass this overhead with Vulkan they should be able to do the same with OpenGL too, I assume.

Directx can be done to a... competent degree using DXVK and WineD3D I believe

It would be great if dxvk could be loaded so the dwm (the compositing engine of the Windows desktop) was able to be accelerated by it, otherwise i'd imagine diminishing returns having only specific applications accelerated (which would only be smooth in fullscreen due to compositor applying itself over windows applications).

In that sense the vmware method is ideal as it does exactly what one would expect, I do not know how they do it exactly since its closed source but it works great. Parallels on Mac OS does it well too to the extent where people with M1 macs are able to play newer games and have a smooth UI experience in a Windows vm - thats pretty impressive.

[Quackdoc]

Not so sure about it, OpenGL inherently isnt really that limited, virgl in this sense would be slowed down by the overhead in the graphics translation stack, if one could bypass this overhead with Vulkan they should be able to do the same with OpenGL too, I assume.

Sure they might be able to, but the amount of difficulty would be so pointless. OpenGL IS inherently limited in comparison to vulkan, which is why well optimized vulkan games can achieve 2-4x performance increases over well optimized openGL equivalents. this is why Google is deeming it worthy to port it to vulkan in the first place. as most android apps still support openGL.

It would be great if dxvk could be loaded so the dwm (the compositing engine of the Windows desktop) was able to be accelerated by it, otherwise i'd imagine diminishing returns having only specific applications accelerated (which would only be smooth in fullscreen due to compositor applying itself over windows applications).

In that sense the vmware method is ideal as it does exactly what one would expect, I do not know how they do it exactly since its closed source but it works great. Parallels on Mac OS does it well too to the extent where people with M1 macs are able to play newer games and have a smooth UI experience in a Windows vm - thats pretty impressive.

I would expect that it could, I dont really see why it wouldn't be possible.

[darkbasic]

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.

It would still be waaaaaaaay better than the current situation.

[darkbasic]

Virgl is actually great for driving user interfaces at native feeling speeds. Linux distros and even Android vms with virgl support run their interfaces at 60fps without feeling like VNC.
For Windows guests one would require a dx11 passthrough or emulation of sorts, vmware actually does this and is able to run the Windows desktop with dwm at a native feeling 60fps framerate and its great for that, it would be great to have some sort of a guest driver that does dx11 on guest side through hosts Vulkan on qemu aswell.

The performance for heavier tasks though is not up to par or not even close to native sadly, but that is already something else.

Unfortunately virgl is still a no go for windows guests and even when you use it with linux guests you sill won't be able to use it remotely with spice: it won't run over a tcp connection. Because of this I basically have no use for virgl.

[Quackdoc]

Unfortunately virgl is still a no go for windows guests and even when you use it with linux guests you sill won't be able to use it remotely with spice: it won't run over a tcp connection. Because of this I basically have no use for virgl.

virgl + spice locally works when specifying socket. but thats it I believe sadly