[RFC PATCH 3/3] drm/virtio: drm_gem_plane_helper_prepare_fb for obj synchronization

[Kim, Dongwon]

Hi Dmitry,

Resource flush is what is waiting for the fence to be signaled. 

(in current code before my patches are applied)
static void virtio_gpu_resource_flush(struct drm_plane *plane,
                                      uint32_t x, uint32_t y,
                                      uint32_t width, uint32_t height)
......
                virtio_gpu_notify(vgdev);

                dma_fence_wait_timeout(&vgfb->fence->f, true,
                                       msecs_to_jiffies(50));
.......

We use gtk on the host.

Thanks!

-----Original Message-----
From: Dmitry Osipenko <dmitry.osipenko at collabora.com> 
Sent: Wednesday, October 4, 2023 4:32 PM
To: Kim, Dongwon <dongwon.kim at intel.com>; dri-devel at lists.freedesktop.org
Cc: Kasireddy, Vivek <vivek.kasireddy at intel.com>; kraxel at redhat.com
Subject: Re: [RFC PATCH 3/3] drm/virtio: drm_gem_plane_helper_prepare_fb for obj synchronization

On 9/6/23 00:08, Kim, Dongwon wrote:
> 
> I don't believe the guest will start rendering on the same FB while 
> host is consuming it because the virtio-gpu driver on the guest won't 
> release the FB for the next frame before it gets the virtio resp for 
> the resource flush command and the host (QEMU) will hold the response 
> until the rendering is finished.

The virgl_cmd_set_scanout() shouldn't hold the response if you're using SDL because frame swapping won't be vsynced. It may hold the response implicitly if you're using GTK for the Qemu's display. Are you using SDL?

--
Best regards,
Dmitry