We do often include affiliate links to earn us some pennies. See more here.

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:

YouTube Thumbnail
YouTube videos require cookies, you must accept their cookies to view. View cookie preferences.
Accept Cookies & Show   Direct Link
Article taken from GamingOnLinux.com.
25 Likes
About the author -
author picture
I am the owner of GamingOnLinux. After discovering Linux back in the days of Mandrake in 2003, I constantly checked on the progress of Linux until Ubuntu appeared on the scene and it helped me to really love it. You can reach me easily by emailing GamingOnLinux directly. You can also follow my personal adventures on Bluesky.
See more from me
The comments on this article are closed.
All posts need to follow our rules. For users logged in: please hit the Report Flag icon on any post that breaks the rules or contains illegal / harmful content. Guest readers can email us for any issues.
11 comments

morphles Dec 1, 2021
Hm, and if somehow it ends up having x86 emulated machines with vulkan while on ARM host... one can only dream of possibilities. Linux on ARM might end up playing more Windows games than Windows on ARM. One can hope :)
kokoko3k Dec 1, 2021
This wcould mean Windows Virtual Machines going almost native speed by cpu and gpu side, nice!


Last edited by kokoko3k on 1 December 2021 at 2:40 pm UTC
ljrk Dec 1, 2021
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 ;)
Julius Dec 1, 2021
Clearly aimed at ARM based Chrome-books. Not much to see here from a "normal" GNU/Linux gaming perspective.
skyrrd Dec 1, 2021
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)
Shmerl Dec 1, 2021
Btw, does virgl work with user session Qemu/KVM or only with regular session? I didn't manage to make it work with user session ones.
gardotd426 Dec 1, 2021
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.
Purple Library Guy Dec 1, 2021
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?
Marlock Dec 2, 2021
The first thing that came to my mind was the Apple M1 beast, then Raspberry Pi 4 and only then the ARM Chromebooks...

Definitely useful in multiple fronts :)
ljrk Dec 2, 2021
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?
Marlock Dec 17, 2021
afaik the only way to not need the host OS support for the graphics API called from the guest (plus the interfacing support for it between guest and host) is using a gpu passthrough method...

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
While you're here, please consider supporting GamingOnLinux on:

Reward Tiers: Patreon. Plain Donations: PayPal.

This ensures all of our main content remains totally free for everyone! Patreon supporters can also remove all adverts and sponsors! Supporting us helps bring good, fresh content. Without your continued support, we simply could not continue!

You can find even more ways to support us on this dedicated page any time. If you already are, thank you!
The comments on this article are closed.