[RFC,00/12] -- 2021: The year of the context type

Message

Gurchetan Singh Aug. 26, 2021, 2:04 a.m. UTC

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(-)