[HN Gopher] OpenBSD: Viogpu(4), a VirtIO GPU driver, added to -c...
___________________________________________________________________
OpenBSD: Viogpu(4), a VirtIO GPU driver, added to -current
Author : peter_hansteen
Score : 88 points
Date : 2023-04-21 12:42 UTC (10 hours ago)
(HTM) web link (www.undeadly.org)
(TXT) w3m dump (www.undeadly.org)
| FloatArtifact wrote:
| Sharing a one/multiple physical GPUs with multiple virtual
| environments?
| st_goliath wrote:
| 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 wrote:
| Can this actually be done today, or would a lot things have
| to be implemented in that chain?
| st_goliath wrote:
| 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_ac
| celer...
|
| [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...
| rwmj wrote:
| Arch's wiki (as usual) is the best summary of the
| situation:
|
| https://wiki.archlinux.org/title/QEMU/Guest_graphics_accele
| r...
| FloatArtifact wrote:
| 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 wrote:
| 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 wrote:
| This looks like a para-virtualised GPU driver and probably more
| similar to accelerated indirect OpenGL rendering than PCI(e)
| passthrough.
| 0xbkt wrote:
| 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 wrote:
| Usually only enabled for server class GPUs, from what I've
| seen.
| adestefan wrote:
| 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.
| digitallyfree wrote:
| What's the difference between Viogpu and the older Virgil3d?
| wahern wrote:
| 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...
| ianlevesque wrote:
| Is there good documentation on virtio GPU's protocol somewhere?
| I'm curious if it's forwarding opengl calls or what.
| mullr wrote:
| https://docs.oasis-open.org/virtio/virtio/v1.2/cs01/virtio-v...
| nazgulsenpai wrote:
| 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...
| qalmakka wrote:
| 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.
| ridgered4 wrote:
| 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.
___________________________________________________________________
(page generated 2023-04-21 23:01 UTC)