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.
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.
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.
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.
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.
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?
I'd even just settle for a way to offload video decoding to the host GPU somehow.