virglrenderer for 3d support

QEMU 9.2 is now also being tested by Proxmox:
Did anyone try it out? Unfortunately no video encoding is supported by Virtio-GPU Venus yet. This means using it as a Gaming (headless) Server, Encoding server etc. will not work. But using it as an Compute VM might work.

@t.lamprecht Are there any params we can set in the VMs config to enable Venus, if we use QEMU 9.2?

For reference: I did use QEMU 9.2 locally. Running non-demanding Games like Northgard I could run one instance of it in a VM and one instance on the host at the same time with my RX 6800 flawlessly. Also more demanding Games like Metro Exodus or The Witcher III launch. They also do render with high FPS. But while Northgard was a really nice experience, there was still stutter in The Witcher and Metro. I guess there have to be some bottlenecks adressed in future qemu-releases on the virtio guest driver as well.


EDIT: Well, as far as I know you'll need Kernel 6.13 for it to work. So maybe we need to wait a little longer...
 
Last edited:
So? Any updates on QEMU Venus? We gave Kernel 6.13+, Qemu 9.2. Seems like Mesa 24 is the last missing thing.
Hello?
 
Last edited:
Thanks, @t.lamprecht ! I admit that I have trouble navigating Debian's package listing site. It's weirdly intuitive, at least for me.

@DocMAX I'm sure several of us would be happy to help test this. Are there written directions somewhere for setting it up in Proxmox? I assume it's similar to the old VirGL setup.
Basically if virglrenderer + qemu + mesa is all updated to the current version it should work out of the box with VirGL driver (in the Proxmox GUI). You will have Vulkan available on (also current) Linux OSes (not Windows of course!)
 
Basically if virglrenderer + qemu + mesa is all updated to the current version it should work out of the box with VirGL driver (in the Proxmox GUI). You will have Vulkan available on (also current) Linux OSes (not Windows of course!)
Oh, good. I was hoping it'd be a drop-in replacement.

So, Venus completely replaces the old system in Mesa 25/VirGLrenderer? It's not possible to accidentally run the old version of VirGL? I'm very good at doing things accidentally. :P
 
Thanks, @t.lamprecht ! I admit that I have trouble navigating Debian's package listing site. It's weirdly intuitive, at least for me.
Can relate to that, I'm probably just visiting them more often and am used to them.
FWIW, maybe the tracker is more intuitive for you, it has also a lot of information, but some are grouped nicely, like the version information table on the left, that shows what version is in what suite (stable == current stable release, which is bookworm until trixie was officially released), see: https://tracker.debian.org/pkg/mesa
 
  • Like
Reactions: SInisterPisces
Can relate to that, I'm probably just visiting them more often and am used to them.
FWIW, maybe the tracker is more intuitive for you, it has also a lot of information, but some are grouped nicely, like the version information table on the left, that shows what version is in what suite (stable == current stable release, which is bookworm until trixie was officially released), see: https://tracker.debian.org/pkg/mesa
That's awesome! And yes, the tracker does seem easier to understand.

Debian's entire online aesthetic is very "cutting edge 2005 web site." That's not a criticism, but it definitely makes me feel like I'm going back in time.
 
Code:
kvm: -device virtio-vga-gl,id=vga,bus=pcie.0,addr=0x1,venus=on: old virglrenderer, venus unsupported
TASK ERROR: start failed: QEMU exited with code 1

I overlooked the current files of PVE 8.4 and it seems we have everything for venus. The error suggests that virgelrenderer is too old, so i compiled the current one. But still the same. Is PVE somehow launching a virglrenderer internally? Or we really need a newer MESA version? Here is my conf file:

Code:
agent: 1
bios: ovmf
boot: order=scsi0;net0
cores: 16
cpu: host
efidisk0: zpool-nfs:110/vm-110-disk-0.qcow2,efitype=4m,pre-enrolled-keys=1,size=528K
machine: q35
memory: 16384
meta: creation-qemu=8.1.5,ctime=1718311224
name: archlinux
net0: virtio=BC:24:11:13:F9:49,bridge=vmbr0,firewall=1
numa: 0
ostype: l26
scsi0: zpool-nfs:110/vm-110-disk-1.qcow2,discard=on,iothread=1,size=512G
scsihw: virtio-scsi-single
smbios1: uuid=5a595ab9-72a4-46e1-a395-06135be6c769
sockets: 1
vga: none
args: -display egl-headless,gl=core -device virtio-vga-gl,id=vga,bus=pcie.0,addr=0x1,venus=on
 
Last edited:
Code:
kvm: -device virtio-vga-gl,id=vga,bus=pcie.0,addr=0x1,venus=on: old virglrenderer, venus unsupported
TASK ERROR: start failed: QEMU exited with code 1

I overlooked the current files of PVE 8.4 and it seems we have everything for venus. The error suggests that virgelrenderer is too old, so i compiled the current one. But still the same. Is PVE somehow launching a virglrenderer internally? Or we really need a newer MESA version? Here is my conf file:

Code:
agent: 1
bios: ovmf
boot: order=scsi0;net0
cores: 16
cpu: host
efidisk0: zpool-nfs:110/vm-110-disk-0.qcow2,efitype=4m,pre-enrolled-keys=1,size=528K
machine: q35
memory: 16384
meta: creation-qemu=8.1.5,ctime=1718311224
name: archlinux
net0: virtio=BC:24:11:13:F9:49,bridge=vmbr0,firewall=1
numa: 0
ostype: l26
scsi0: zpool-nfs:110/vm-110-disk-1.qcow2,discard=on,iothread=1,size=512G
scsihw: virtio-scsi-single
smbios1: uuid=5a595ab9-72a4-46e1-a395-06135be6c769
sockets: 1
vga: none
args: -display egl-headless,gl=core -device virtio-vga-gl,id=vga,bus=pcie.0,addr=0x1,venus=on
What does mesautils say its current version is?
 
mesa-utils (8.5.0-1) and i hadn't installed them. are they needed? the issue is the same.
It has troubleshooting and info tools that could be useful for troubleshooting this.

Install it INSIDE THE VM you're trying to do this with, and run glxinfo. That will give information about the version of Mesa the VM is using, among other things. What's the output?

(You'll have to revert the KVM flags that keep the VM from booting, so this might not show Venus-related information, but we can verify the version of Mesa it's using.)

Otherwise, as this is a KVM error, it might be worth filing a support/bug ticket upstream at the KVM project.