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@xxxxxxxxxxxxx>
Sent: Wednesday, October 4, 2023 4:32 PM
To: Kim, Dongwon <dongwon.kim@xxxxxxxxx>; dri-devel@xxxxxxxxxxxxxxxxxxxxx
Cc: Kasireddy, Vivek <vivek.kasireddy@xxxxxxxxx>; kraxel@xxxxxxxxxx
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
