[RFC PATCH v2 1/1] drm/virtio: new fence for every plane update

[Kim, Dongwon]

> -----Original Message-----
> From: Dmitry Osipenko <dmitry.osipenko at collabora.com>
> Sent: Monday, October 23, 2023 5:24 AM
> To: Kim, Dongwon <dongwon.kim at intel.com>; dri-devel at lists.freedesktop.org
> Cc: kraxel at redhat.com; Kasireddy, Vivek <vivek.kasireddy at intel.com>
> Subject: Re: [RFC PATCH v2 1/1] drm/virtio: new fence for every plane update
> 
> On 10/3/23 04:00, Dongwon Kim wrote:
> > Having a fence linked to a virtio_gpu_framebuffer in the plane update
> > sequence would cause conflict when several planes referencing the same
> > framebuffer (e.g. Xorg screen covering multi-displays configured for
> > an extended mode) and those planes are updated concurrently. So it is
> > needed to allocate a fence for every plane state instead of the framebuffer.
> >
> > The plane state for virtio-gpu, "struct virtio_gpu_plane_state" is
> > added for this. This structure represents drm_plane_state and it
> > contains the reference to virtio_gpu_fence, which was previously in "struct
> virtio_gpu_framebuffer".
> >
> > "virtio_gpu_plane_duplicate_state" is added as well to create a
> > virtio_gpu_plane_state on top of duplicated drm plane state.
> >
> > Several drm helpers were slightly modified accordingly to use the
> > fence in new plane state structure. virtio_gpu_plane_cleanup_fb was
> > completely removed as dma_fence_put shouldn't be called here as it can
> > mess up with the ref count of the fence. The fence should be put after
> > the fence is signaled in virtio_gpu_resource_flush then released in
> > virtio_gpu_array_add_fence while the next virtio message is being queued.
> >
> > Also, the condition for adding fence, (plane->state->fb !=
> > new_state->fb) was removed since we now allocate a new fence for the
> > new plane state even if both old and new planes are pointing to the same
> framebuffer.
> >
> > v2: removed virtio_gpu_plane_duplicate_state as the existing helper,
> >     drm_atomic_helper_plane_destroy_state does the same.
> >
> > Cc: Dmitry Osipenko <dmitry.osipenko at collabora.com>
> > Cc: Gerd Hoffmann <kraxel at redhat.com>
> > Cc: Vivek Kasireddy <vivek.kasireddy at intel.com>
> > Signed-off-by: Dongwon Kim <dongwon.kim at intel.com>
> > ---
> >  drivers/gpu/drm/virtio/virtgpu_drv.h   |  7 +++
> >  drivers/gpu/drm/virtio/virtgpu_plane.c | 66
> > +++++++++++++++++---------
> >  2 files changed, 51 insertions(+), 22 deletions(-)
> 
> Please write a guide how to test it. Are you using spice for the multi-display
> viewer?

[DW] Yeah, let me come up with a simple test case. So we use virtio-gpu as KMS device. It is used to share the guest frame with QEMU.
SPICE is one of client solutions we use but we primarily use QEMU GTK-UI w/ multi displays (QEMU with this params '-device virtio-vga,max_outputs=2,blob=true').
Thanks!

> 
> --
> Best regards,
> Dmitry