Date: Tue, 28 Jul 2026 19:48:14 +0800 From: yi zishun <zishun.yi.dev@gmail.com> To: FreeBSD Hackers <freebsd-hackers@freebsd.org> Cc: freebsd-virtualization@freebsd.org Subject: Worth adding another graphics option to bhyve? Message-ID: <CABjVtiZc-y9H0ob8Fxk94zpsSpsp5qZcPSSg0q4geLq3S0S7rw@mail.gmail.com>
index | next in thread | raw e-mail
Hi, hackers As the title suggests, briefly speaking, the proposed option is a combination of "vhost-user-gpu" and another display backend (for example, a D-Bus backend). Currently, bhyve has two main approaches for graphics rendering and display. One is fbuf+VNC for 2D graphics, and the other is GPU passthrough mainly for 3D workloads. Both approaches have some obvious drawbacks. For example, fbuf is non-accelerated and VNC does not support zero-copy transfer, which makes fbuf+vnc have poor performance. GPU pci passthrough has excellent performance. But due to its exclusive use, the host cannot access the GPU anymore, not to mention supporting multiple VMs. I understand why these two designs exist: because bhyve is part of the base system, we cannot introduce GPL-licensed software or heavy graphics dependencies. So it is better, if there is an option, with a minimal implementation without any heavy dependence, but still can use modern graphics stack render and display capabilities, and can support multiple VM. My motivation for this proposal stems from my GSoC work on udmabuf. With the underlying zero-copy buffer sharing mechanism now in place, I wanted to explore how bhyve could natively utilize it to overcome the current performance bottlenecks in graphics rendering and displaying. For rendering, we can implement a device which presents itself to the guest kernel as a virtio-gpu device, but does not process any commands internally, the main virtqueue is handled by a separate userspace program, vhost-user-gpu. And the device communicates to vhost-user-gpu using vhost-user protocol. One implementation of vhost-user-gpu is rust-vmm's vhost-device-gpu, which processes the data and sends the rendered image back to QEMU/bhyve for display, and currently supports gtk and dbus backend as far as I know. We can then implement a new display backend, dbus backend, to dispatch the display to another program, too. But we can't introduce dbus into the base system, so maybe we need another out-of-tree small proxy to do the conversion. In conclusion, this approach dispatches the actual rendering and display tasks to two separate programs. bhyve only presents itself as a virtio-gpu device from the guest's point of view, and communicates to the two programs internally. This option is minimal, modular, and secure, leveraging the modern graphics stack to support multiple VMs without requiring dedicated hardware support, while providing the benefits of virtio-gpu. I would appreciate any feedback and discussion on the feasibility of this approach. If the idea is considered worthwhile, I am willing to invest the time and effort required to implement it. Best, Zishun Yihome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CABjVtiZc-y9H0ob8Fxk94zpsSpsp5qZcPSSg0q4geLq3S0S7rw>