[RFC,v1,0/6] drm: Add support for DRM_CAP_RELEASE_FENCE capability

Message

Kasireddy, Vivek Sept. 13, 2021, 11:35 p.m. UTC

The main idea behind DRM_CAP_RELEASE_FENCE is to add an additional
signaling mechanism for a pageflip completion in addition to out_fence
or DRM_EVENT_FLIP_COMPLETE event. This allows a compositor to start
a new repaint cycle with a new buffer instead of waiting for the
old buffer to be free. 

Why?
So, an atomic pageflip completion indicates two things to a compositor:
- that it can repaint again and
- that the old fb is free and can be reused (that was submitted in
  the previous repaint cycle)

Essentially, DRM_CAP_RELEASE_FENCE is about separating out the above
two assumptions. DRM_EVENT_FLIP_COMPLETE event or out_fence would 
serve as a signal to repaint and newly added release_fence would 
provide a way to determine when old fbs can be re-used again. 

This separation is really needed when the fb(s) associated with a
pageflip are shared outside of the OS -- which is indeed the 
case with Virtio-gpu, a Virtual KMS driver. The Virtio-gpu driver
runs in a Virtual Machine and can share the fb with the Host -- 
via Wayland UI -- in a zero-copy way. And, in this particular
environment where the Host and Guest/VM are running Wayland based
compositors, it would be desirable to have the Guest compositor's
scanout fb be placed directly on a hardware plane on the Host --
to improve performance when there are multiple Guests running.
To ensure 60 FPS and to prevent Guest and Host compositors from
using an fb at the same time, the signaling of Guest's release_fence
is tied to Host's wl_buffer_release event and DRM_EVENT_FLIP_COMPLETE/
out_fence signaling is tied to Host compositor's frame callback event.

Implementation:
Since release_fence is almost identical to out_fence, it is implemented
by making use of the existing out_fence machinery. And, although, the
drm core creates the release_fence, the Virtio-gpu driver takes care
of signaling it when it gets notified by the Host that the fb is free.

This work is based on the idea/suggestion from Simon and Pekka.

And, this patch series provides a solution for this Weston issue:
https://gitlab.freedesktop.org/wayland/weston/-/issues/514

Tested with:
Weston MR:
https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/668
and
Qemu patches:
https://lists.nongnu.org/archive/html/qemu-devel/2021-09/msg03463.html

Earlier version/discussion of this patch series can be found at:
https://lists.freedesktop.org/archives/dri-devel/2021-July/317672.html

Cc: Daniel Vetter <[e-mail]>
Cc: Gerd Hoffmann <[e-mail]>
Cc: Pekka Paalanen <[e-mail]>
Cc: Simon Ser <[e-mail]>
Cc: Michel Dänzer <[e-mail]>
Cc: Tina Zhang <[e-mail]>
Cc: Dongwon Kim <[e-mail]>
Cc: Satyeshwar Singh <[e-mail]>

Vivek Kasireddy (6):
  drm/atomic: Move out_fence creation/setup into a separate function
  drm/atomic: Add support for release_fence and its associated property
  drm: Add a capability flag to support additional flip completion
    signalling
  drm/virtio: Probe and implement VIRTIO_GPU_F_RELEASE_FENCE feature
  drm/virtio: Prepare set_scanout_blob to accept a fence
  drm/virtio: Add a fence to set_scanout_blob

 drivers/gpu/drm/drm_atomic_uapi.c        | 100 ++++++++++++++++++-----
 drivers/gpu/drm/drm_crtc.c               |   2 +
 drivers/gpu/drm/drm_ioctl.c              |   3 +
 drivers/gpu/drm/drm_mode_config.c        |   6 ++
 drivers/gpu/drm/virtio/virtgpu_debugfs.c |   1 +
 drivers/gpu/drm/virtio/virtgpu_drv.c     |   1 +
 drivers/gpu/drm/virtio/virtgpu_drv.h     |   5 +-
 drivers/gpu/drm/virtio/virtgpu_fence.c   |   9 ++
 drivers/gpu/drm/virtio/virtgpu_kms.c     |   9 +-
 drivers/gpu/drm/virtio/virtgpu_plane.c   |  63 ++++++++++++--
 drivers/gpu/drm/virtio/virtgpu_vq.c      |   7 +-
 include/drm/drm_atomic.h                 |   1 +
 include/drm/drm_file.h                   |   9 ++
 include/drm/drm_mode_config.h            |  15 ++++
 include/uapi/drm/drm.h                   |   1 +
 include/uapi/linux/virtio_gpu.h          |   2 +
 16 files changed, 200 insertions(+), 34 deletions(-)