OpenBSD: Viogpu(4), a VirtIO GPU driver, added to -current | Hacker News Reader

OpenBSD: Viogpu(4), a VirtIO GPU driver, added to -current

undeadly.org

105 pointspeter_hansteen19 comments

I wish more progress was made on this feature. Vmware has had paravirtualized 3D acceleration in guests for over a decade even on their free player product and it is the one real feature I really miss.

I'd even just settle for a way to offload video decoding to the host GPU somehow.

VirGL works very well but it sorely misses a Windows driver. It would be a gamechanger, but writing such a driver is probably very complex and a massive PITA, so I understand why no one has done it yet.

With modern software such as DXVK, Zink and VKD3D a lot of the burden of implementing Direct3D and OpenGL would probably be reduced by writing a Vulkan implementation and piggybacking over it for the rest though.

Is there good documentation on virtio GPU's protocol somewhere? I'm curious if it's forwarding opengl calls or what.

Can't find any documentation but here is the source on the GitHub mirror of their CVS: https://github.com/openbsd/src/blob/e208b5629e93dc00cc43012e... https://github.com/openbsd/src/blob/e208b5629e93dc00cc43012e...

https://docs.oasis-open.org/virtio/virtio/v1.2/cs01/virtio-v...

I’m excited for this to be used for paravirtualization of the arm64 port on an M1 Mac. Right now you have to use the EFI framebuffer which is not good.

Since I can not figure out how to get the actual changes from this page, here's the commit in the github mirror... https://github.com/openbsd/src/commit/e208b5629e93dc00cc4301...

What's the difference between Viogpu and the older Virgil3d?

virtio-gpu is 2D. virgl is an extension mode for 3D rendering offload. TIL virtio is properly standardized: https://docs.oasis-open.org/virtio/virtio/v1.2/virtio-v1.2.h... The new OpenBSD driver seems to reflect (directly or indirectly) an earlier revision: https://docs.oasis-open.org/virtio/virtio/v1.1/virtio-v1.1.h...

Does anybody know about the current status of SR-IOV for graphics cards? It is highlighted for NICs but I want to know if there is anything upcoming for GPUs too.

Usually only enabled for server class GPUs, from what I've seen.

Sharing a one/multiple physical GPUs with multiple virtual environments?

I think you mean PCI pass-through? That allows you to isolate PCI resources and pass them through directly to the guest VM. The host doesn't need to have a driver or understand what that device is at all. Ideally the host should not even touch the device during boot, e.g. if it is a graphics cards.

Virtio GPU is something different, namely a para-virtualized graphics adapter that uses the VirtIO guest-to-host communication to expose hardware accelerated graphics to the VM.

For instance, on the guest side, you could have Mesa3D implementing OpenGL userspace and internally using its "Virgl" driver (or "Venus", for Vulkan) that serializes a command stream, sends that through a guest side kernel driver that passes it on through the VirtIO device to Qemu on the host side, that then uses existing OpenGL userspace graphics APIs to do the actual accelerated rendering.

Can this actually be done today, or would a lot things have to be implemented in that chain?

Arch's wiki (as usual) is the best summary of the situation:

https://wiki.archlinux.org/title/QEMU/Guest_graphics_acceler...

According to the Arch Wiki, the Linux side is "fairly mature"[0]. The Mesa3D documentation leaves a similar impression regarding OpenGL[1], mentioning that the Linux drivers, including the ones for 3D support, are mainline since 4.4 (released in 2016[2]) with Qemu support since version 2.5 (released around 2015[2]), so I guess, the assessment from the Arch Wiki sounds about right.

The Venus driver for Vulkan is described as "experimental" [4], with Linux kernel side support merged in version 5.16 (release in early 2022[5]).

RedHat is developing VirtIO drivers for Windows[6], but apparently they gave up the work on the OpenGL ICD driver in favor of Vulkan[7]?

That said, I have no clue what the situation on various BSDs looks like. I guess on OpenBSD, this is a first step towards making this chain work?

[0] https://wiki.archlinux.org/title/QEMU/Guest_graphics_acceler...

[1] https://docs.mesa3d.org/drivers/virgl.html

[2] https://kernelnewbies.org/Linux_4.4

[3] https://lists.gnu.org/archive/html/qemu-devel/2015-12/msg027...

[4] https://docs.mesa3d.org/drivers/venus.html

[5] https://kernelnewbies.org/Linux_5.16

[6] https://www.linux-kvm.org/page/WindowsGuestDrivers/Download_...

[7] https://lists.freedesktop.org/archives/virglrenderer-devel/2...

I believe with pass through it dedicates the entire physical device to the to a single virtual environment. I was hoping there's progress here to share across multiple virtual environments with even a single physical gpu.

Pass-through dedicates an entire d/b/s/f to a guest OS, but you could plausibly have a single GPU "device" (slot) providing multiple "functions," with the hardware multiplexed between guest consumers internally ("Multi-Function Devices"). I believe some SmartNICs do this? "SR-IOV" is a related concept.

This looks like a para-virtualised GPU driver and probably more similar to accelerated indirect OpenGL rendering than PCI(e) passthrough.

Reply on news.ycombinator.com