Dear all,
I'm excited to share with you a ground-breaking and dare I say it even
shocking discovery in graphics virtualization.
The critics are raving -- many keen observers of VM graphics are
proclaiming 2021 to be "the year of the context type", eclipsing the
revolutionary blob resource of 2020.
The hype is justified; context types makes virtio-gpu 3D extensible,
opening the door to new designs and APIs. Traditionally, virtio-gpu
3D is designed around the Gallium Virgl protocol and the host-side
virglrenderer implementation (as reflected with VIRTIO_GPU_F_VIRGL).
With VIRTIO_GPU_F_VIRGL + VIRTIO_GPU_F_CONTEXT_INIT, GPU/display
virtualization defined by the context type is possible. It's entirely
possible the virglrenderer project isn't available on the host in this
scenario.
For example, the "gfxstream" [a] library is designed around (mostly) 1:1
auto-generated encode/decode of rendering commands. This is in contrast
to virgl, which has a Gallium intermediate layer that can be complex.
The Address Space Graphics (ASG) ring-buffer is used to stream these APIs
while minimizing syscall and vm-exit overhead (somewhat like io_uring).
The gfxstream library has been supporting GLES virtualization since 2011,
and CTS-compliant Vulkan virtualization since 2018.
gfxstream is used in a wide range of products, from the Cuttlefish [b] to
the Android Studio emulator [c].
With context types, both virglrenderer and gfxstream can formally use
virtio-gpu as the transport [d].
GFXSTREAM DESIGN
_________ __________ __________
| | | | | |
| RENDER | | GLES | | VULKAN |
| CONTROL | | ENCODER | | CEREAL | GUEST
| ENCODER | | | | ENCODER | ENCODERS
|_________| |__________| |__________|
^ ^ ^
| | | <--------- ASG ring
| | |
- - - | - - - - - - - - - | - - - - - - - - - | - - - - - virtio-gpu
| | |
____v____ ____v_____ _____v____
| | | | | |
| RENDER | | GLES | | VULKAN |
| CONTROL | | DECODER | | CEREAL | GUEST
| DECODER | | | | DECODER | DECODERS
|_________| |__________| |__________|
| | | | | | GRAPHICS
| EGL/GLX | | GLES | | Vulkan | LIBRARIES
|_________| |__________| |__________|
Indeed, context types are versatile enough to support display
virtualization too [e]. For example, one can passthrough guest Wayland
commands to enable seamless windowing.
1) Weston [guest] -> DRM/KMS virtio-gpu 2d -> VMM virtgpu 2d -> compositor
2) Sommelier [guest] -> virtio-gpu 3d -> VMM virtgpu context -> compositor
(1) is traditionally used, but (2) avoids API translations and has more
features. Wayland passthrough has been used laptops for many years. Here
are some videos on the subject:
https://www.youtube.com/watch?v=WwrXqDERFm8
https://www.youtube.com/watch?v=EkNBsBx501Q
With context types, seamless wayland windowing will be available to a wider
audience.
For virglrenderer, context types enable distinction between the virgl [f]
and the auto-generated "Venus" vulkan protocols [g].
In the future, GPU compute APIs or even vendor-specific protocols can use
the context type mechanism too.
Context types have been tested with crosvm and the feature is available on
the main branch.
[a] https://android.googlesource.com/device/generic/vulkan-cereal/
[b] https://source.android.com/setup/create/cuttlefish-ref-gpu
[c] https://developer.android.com/studio/run/emulator
[d] https://android.googlesource.com/device/generic/goldfish-opengl/+/refs/heads/master/system/vulkan_enc/ResourceTracker.cpp#1052
[e] https://chromium.googlesource.com/chromiumos/platform2/+/main/vm_tools/sommelier/virtualization/virtgpu_channel.cc#221
[f] https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7712
[g] https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/virtio/vulkan/vn_renderer_virtgpu.c#L63
Anthoine Bourgeois (2):
drm/virtio: implement context init: probe for feature
drm/virtio: implement context init: support init ioctl
Gurchetan Singh (10):
virtio-gpu api: multiple context types with explicit initialization
drm/virtgpu api: create context init feature
drm/virtio: implement context init: track valid capabilities in a mask
drm/virtio: implement context init: track {ring_idx, emit_fence_info}
in virtio_gpu_fence
drm/virtio: implement context init: plumb {base_fence_ctx, ring_idx}
to virtio_gpu_fence_alloc
drm/virtio: implement context init: stop using drv->context when
creating fence
drm/virtio: implement context init: allocate an array of fence
contexts
drm/virtio: implement context init: handle
VIRTGPU_CONTEXT_PARAM_POLL_RINGS_MASK
drm/virtio: implement context init: add virtio_gpu_fence_event
drm/virtio: implement context init: advertise feature to userspace
drivers/gpu/drm/virtio/virtgpu_debugfs.c | 1 +
drivers/gpu/drm/virtio/virtgpu_drv.c | 44 ++++-
drivers/gpu/drm/virtio/virtgpu_drv.h | 28 +++-
drivers/gpu/drm/virtio/virtgpu_fence.c | 30 +++-
drivers/gpu/drm/virtio/virtgpu_ioctl.c | 194 +++++++++++++++++++++--
drivers/gpu/drm/virtio/virtgpu_kms.c | 26 ++-
drivers/gpu/drm/virtio/virtgpu_plane.c | 3 +-
drivers/gpu/drm/virtio/virtgpu_vq.c | 19 +--
include/uapi/drm/virtgpu_drm.h | 27 ++++
include/uapi/linux/virtio_gpu.h | 18 ++-
10 files changed, 354 insertions(+), 36 deletions(-)
--
2.33.0.259.gc128427fd7-goog
