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@xxxxxxxxxxxxx> > Cc: Gerd Hoffmann <kraxel@xxxxxxxxxx> > Cc: Vivek Kasireddy <vivek.kasireddy@xxxxxxxxx> > Signed-off-by: Dongwon Kim <dongwon.kim@xxxxxxxxx> > --- > 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? -- Best regards, Dmitry
