5 ms·

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

105 points by peter_hansteen 4y ago

FloatArtifact 4y ago
Sharing a one/multiple physical GPUs with multiple virtual environments?
- st_goliath 4y ago
  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.
  - actionfromafar 4y ago
    Can this actually be done today, or would a lot things have to be implemented in that chain?
    - rwmj 4y ago
      Arch's wiki (as usual) is the best summary of the situation: https://wiki.archlinux.org/title/QEMU/Guest_graphics_acceleration https://wiki.archlinux.org/title/QEMU/Guest_graphics_acceler...
    - st_goliath 4y ago
      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_acceleration#Virgil3d_virtio-gpu_paravirtualized_device_driver https://wiki.archlinux.org/title/QEMU/Guest_graphics_acceler... [1] https://docs.mesa3d.org/drivers/virgl.html https://docs.mesa3d.org/drivers/virgl.html [2] https://kernelnewbies.org/Linux_4.4 https://kernelnewbies.org/Linux_4.4 [3] https://lists.gnu.org/archive/html/qemu-devel/2015-12/msg02731.html https://lists.gnu.org/archive/html/qemu-devel/2015-12/msg027... [4] https://docs.mesa3d.org/drivers/venus.html https://docs.mesa3d.org/drivers/venus.html [5] https://kernelnewbies.org/Linux_5.16 https://kernelnewbies.org/Linux_5.16 [6] https://www.linux-kvm.org/page/WindowsGuestDrivers/Download_Drivers https://www.linux-kvm.org/page/WindowsGuestDrivers/Download_... [7] https://lists.freedesktop.org/archives/virglrenderer-devel/2021-January/001897.html https://lists.freedesktop.org/archives/virglrenderer-devel/2...
  - FloatArtifact 4y ago
    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.
    - loeg 4y ago
      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.
- crest 4y ago
  This looks like a para-virtualised GPU driver and probably more similar to accelerated indirect OpenGL rendering than PCI(e) passthrough.
ianlevesque 4y ago
Is there good documentation on virtio GPU's protocol somewhere? I'm curious if it's forwarding opengl calls or what.
- nazgulsenpai 4y ago
  Can't find any documentation but here is the source on the GitHub mirror of their CVS: https://github.com/openbsd/src/blob/e208b5629e93dc00cc43012e18092d238479df80/sys/dev/pv/viogpu.c https://github.com/openbsd/src/blob/e208b5629e93dc00cc43012e... https://github.com/openbsd/src/blob/e208b5629e93dc00cc43012e18092d238479df80/sys/dev/pv/viogpu.h https://github.com/openbsd/src/blob/e208b5629e93dc00cc43012e...
- mullr 4y ago
  https://docs.oasis-open.org/virtio/virtio/v1.2/cs01/virtio-v1.2-cs01.html#x1-3650007 https://docs.oasis-open.org/virtio/virtio/v1.2/cs01/virtio-v...
digitallyfree 4y ago
What's the difference between Viogpu and the older Virgil3d?
- wahern 4y ago
  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.html 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.html https://docs.oasis-open.org/virtio/virtio/v1.1/virtio-v1.1.h...
ridgered4 4y ago
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.
qalmakka 4y ago
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.
0xbkt 4y ago
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.
- toast0 4y ago
  Usually only enabled for server class GPUs, from what I've seen.
adestefan 4y ago
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.
winrid 3y ago
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/e208b5629e93dc00cc43012e18092d238479df80 https://github.com/openbsd/src/commit/e208b5629e93dc00cc4301...

FloatArtifact 4y ago

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

st_goliath 4y ago
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.
- actionfromafar 4y ago
  Can this actually be done today, or would a lot things have to be implemented in that chain?
  - rwmj 4y ago
    Arch's wiki (as usual) is the best summary of the situation: https://wiki.archlinux.org/title/QEMU/Guest_graphics_acceleration https://wiki.archlinux.org/title/QEMU/Guest_graphics_acceler...
  - st_goliath 4y ago
    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_acceleration#Virgil3d_virtio-gpu_paravirtualized_device_driver https://wiki.archlinux.org/title/QEMU/Guest_graphics_acceler... [1] https://docs.mesa3d.org/drivers/virgl.html https://docs.mesa3d.org/drivers/virgl.html [2] https://kernelnewbies.org/Linux_4.4 https://kernelnewbies.org/Linux_4.4 [3] https://lists.gnu.org/archive/html/qemu-devel/2015-12/msg02731.html https://lists.gnu.org/archive/html/qemu-devel/2015-12/msg027... [4] https://docs.mesa3d.org/drivers/venus.html https://docs.mesa3d.org/drivers/venus.html [5] https://kernelnewbies.org/Linux_5.16 https://kernelnewbies.org/Linux_5.16 [6] https://www.linux-kvm.org/page/WindowsGuestDrivers/Download_Drivers https://www.linux-kvm.org/page/WindowsGuestDrivers/Download_... [7] https://lists.freedesktop.org/archives/virglrenderer-devel/2021-January/001897.html https://lists.freedesktop.org/archives/virglrenderer-devel/2...
- FloatArtifact 4y ago
  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.
  - loeg 4y ago
    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.
crest 4y ago
This looks like a para-virtualised GPU driver and probably more similar to accelerated indirect OpenGL rendering than PCI(e) passthrough.

ianlevesque 4y ago

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

nazgulsenpai 4y ago
Can't find any documentation but here is the source on the GitHub mirror of their CVS: https://github.com/openbsd/src/blob/e208b5629e93dc00cc43012e18092d238479df80/sys/dev/pv/viogpu.c https://github.com/openbsd/src/blob/e208b5629e93dc00cc43012e... https://github.com/openbsd/src/blob/e208b5629e93dc00cc43012e18092d238479df80/sys/dev/pv/viogpu.h https://github.com/openbsd/src/blob/e208b5629e93dc00cc43012e...
mullr 4y ago
https://docs.oasis-open.org/virtio/virtio/v1.2/cs01/virtio-v1.2-cs01.html#x1-3650007 https://docs.oasis-open.org/virtio/virtio/v1.2/cs01/virtio-v...

digitallyfree 4y ago

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

wahern 4y ago
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.html 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.html https://docs.oasis-open.org/virtio/virtio/v1.1/virtio-v1.1.h...

ridgered4 4y ago

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.

qalmakka 4y ago

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.

0xbkt 4y ago

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.

toast0 4y ago
Usually only enabled for server class GPUs, from what I've seen.

adestefan 4y ago

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.

winrid 3y ago

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/e208b5629e93dc00cc43012e18092d238479df80 https://github.com/openbsd/src/commit/e208b5629e93dc00cc4301...