Well this is quite exciting. Collabora, the open source consulting firm that often works with Valve, has announced the experimental Venus driver for 3D acceleration of Vulkan applications in QEMU. For those not familiar, QEMU is a generic and open source machine emulator and virtualizer.
"Running graphics applications in a Guest OS can be annoying as they are generally greedy of computing resources, and that can slow you down or give you a bad experience in terms of graphics performance. Being able to accelerate all this by offloading the workload to the hardware can be a great deal. The VirtIO-GPU virtual GPU device comes into play here, allowing a Guest OS to send graphics commands to it through OpenGL or Vulkan. While we are already there with OpenGL, we can not say the same for Vulkan. Well, until now."
The work has not been upstreamed yet but it's looking quite promising, Collabora mention that there's still plenty of work to be done yet before that happens. You can see a preview video of it running below:
Direct Link
Last edited by kokoko3k on 1 December 2021 at 2:40 pm UTC
Now we "only" need drivers for Windows and macOS to interface with that. Plus dxvk (dx9-11) und vkd3d for dx12 for Windows and MolteVK for macOS and we'd have pretty neat graphics accelaration ;)
Iirc dxvk is os-agnostic and can be used on Windows as well. Don't know about vkd3d and others.
I'm more curious about performance compared between wine+dxvk and VM+dxvk+Venus.
I guess it is not only the overhead of using a VM but that will hurt performance in this scenario. But might be really useful for other usecases. E.g. I might be able to run a Windows VM on my secondary monitor for CAD and other stuff that needs basic 3d rendering without the need to dualboot. But honestly I haven't checked yet if those do run satisfyingly inside a VM. (And no, wine is no option; said program does not work with wine)
Now we "only" need drivers for Windows and macOS to interface with that. Plus dxvk (dx9-11) und vkd3d for dx12 for Windows and MolteVK for macOS and we'd have pretty neat graphics accelaration ;)
None of that would be necessary. VirtIO-GPU virtual GPU with lib.vfio has already been shown to run Call of Duty Warzone in a Windows VM as if it's a native app using vGPU. You wouldn't need anything to do with vkd3d-proton, dxvk, or Windows drivers.
Clearly aimed at ARM based Chrome-books. Not much to see here from a "normal" GNU/Linux gaming perspective.Well, and Raspberry Pi-ish things, no?
But still, yeah, right now that's true. I do get the feeling that ARM things are going to gradually creep into the main stream, higher powered stuff. So in the future, who knows?
Definitely useful in multiple fronts :)
Now we "only" need drivers for Windows and macOS to interface with that. Plus dxvk (dx9-11) und vkd3d for dx12 for Windows and MolteVK for macOS and we'd have pretty neat graphics accelaration ;)
None of that would be necessary. VirtIO-GPU virtual GPU with lib.vfio has already been shown to run Call of Duty Warzone in a Windows VM as if it's a native app using vGPU. You wouldn't need anything to do with vkd3d-proton, dxvk, or Windows drivers.
But how provides the DX driver then?
a full gpu passthrough lets the guest OS take over full control of the specific hardware, so you need a second GPU hardware just for the windows guest... not ideal with current prices, to say the least, LOL (unless you have a spare one already)
there was work towards a gpu passthrough method where both host and guest could share the same hardware, but i'm not sure how that was meant to work and at what stage that work is now
See more from me