Control: retitle -1 libvirglrenderer1 needs virgl-server for Vulkan support but
there is neither dependencies nor documentation for it, package description is
confusing
Control: affects -1 libvirglrenderer1 qemu-system-x86
Control: severity -1 important
Hi,
First of all, thanks for maintaining the virglrenderer package! It
works and it eventually allowed to me to play games with decent
performance in a VM with only integrated graphics!
However, when initially trying out the new Vulkan passthrough support
in Trixie, I got bitten by this bug too. The good news is that I
eventually got everything working and I saw some *massive* performance
improvements in combination with DXVK in the VM, but the bad news is
that it doesn't work out of the box but needs three tweaks:
1. The Linux kernel in Trixie is too old, at least 6.13 is needed on
the *host* (experimental currently has 6.16 which works). This is
mentioned in most guides for Vulkan passthrough (e.g. [0]) so it
isn't too difficult to discover.
2. QEMU doesn't enable Vulkan passthrough per default, but the extra
parameters needed to get things working are documented at [1].
3. On Debian, you MUST install the virgl-server package manually
even though the package description suggests that the package is
only intended for testing purposes. This is hard to discover
since there's no documentation and from what I can tell,
everybody expects /usr/libexec/virgl_render_server to just be
shipped along with libvirglrenderer1, see e.g. [1].
Problem #3 is made worse by the fact that the error messages if virgl-
server (and thus /usr/libexec/virgl_render_server) are missing are
*really* bad. Here's what you get with -display gtk,gl=on:
# Host dmesg immediatly after starting the VM:
Aug 06 11:17:27 shepard kernel: qemu-system-x86[27619]: segfault at
7f148effd990 ip 00007f1d2f3ae637 sp 00007ffc3533f310 error 4 in
libc.so.6[94637,7f1d2f342000+165000] likely on CPU 14 (core 6, socket 0)
# VM dmesg when launching vkcube:
[ 15.349658] [drm:virtio_gpu_dequeue_ctrl_func [virtio_gpu]] *ERROR*
response 0x1200 (command 0x10c)
[ 15.349697] [drm:virtio_gpu_dequeue_ctrl_func [virtio_gpu]] *ERROR*
response 0x1203 (command 0x208)
# VM stdio when launching vkcube
Selected WSI platform: xcb
vkCreateInstance failed.
Do you have a compatible Vulkan installable client driver (ICD) installed?
Please look at the Getting Started guide for additional information.
There are also some visual artifacts in the GTK window on the host but
at least the VM starts and OpenGL passthrough works without problems.
Here's what you get with -display sdl,gl=on:
# Host dmesg immediatly after starting the VM:
Aug 06 11:25:09 shepard gnome-shell[2182]: WL: error in client
communication (pid 28527)
The SDL window opens for a second and then closes (presumably because
the render thread/process has crashed); the main QEMU process remains
but is entirely unresponsive (doesn't show the console on stdio that I
have configured and doesn't react to SIGTERM, only SIGKILL works).
I had encountered the visual artifacts in the GTK window on the host
already on Bookworm (along with a lot of "eglMakeCurrent failed" error
messages on stdout/stderr on the host), which is why I was initially
only trying with -display sdl.
It took me a full day of troubleshooting until I finally installed the
virgl-server package just to see if *local* Vulkan forwarding worked
using these commands:
virgl_test_server --venus &
VN_DEBUG=vtest vkcube
This worked, so I gave up, thinking some other part of the stack (QEMU,
VM kernel, VM libraries, etc.) simply wasn't working (yet). However,
some time later tried again and then things miraculously worked without
*any* problems (both -display sdl and -display gtk, without any visual
artifacts). It took me another hour to understand that the *only* thing
that had changed was that I had now installed the virgl-server package.
IMHO /usr/libexec/virgl_render_server should simply be moved to the
libvirglrenderer1 package since without it core parts of its
functonality don't work and there are no clear error messages
(presumably because nobody expected the library to be shipped without
the helper binary). Alternatively a Depends: or at the very least a
Recommends: from libvirglrenderer1 to virgl-server would also work.
Thank you for your work and best regards
Alexander Kurtz
[0]
https://www.collabora.com/news-and-blog/blog/2025/01/15/the-state-of-gfx-virtualization-using-virglrenderer
[1]
https://www.qemu.org/docs/master/system/devices/virtio-gpu.html#virtio-gpu-virglrenderer
