Re: [PATCH v1 2/2] drm/virtio: Fix missed dmabuf unpinning in error path of prepare_fb()

[Dmitry Osipenko <dmitry.osipenko@collabora.com>]

On 3/27/25 10:14, Kasireddy, Vivek wrote:
>> Another question, why do we need this fencing for imported dmabuf?
>> Fencing isn't done host/guest blobs in this code, while dmabuf is
>> essentially a guest blob. Could you please clarify why this fence is
>> needed? Maybe we shouldn't allocate fence in the first place for the dmabuf.
> At-least for the non-virgl use-cases (where the rendering is done in the Guest such
> as in passthrough), this Guest/Host synchronization fence serves two purposes:
> - It prevents the Guest from reusing/destroying the submitted buffer (Guest compositor
>   FB) until the Host is done using it. Otherwise, the Guest compositor might render
>   into this buffer at the same time while the Host is consuming it, leading to issues
>   such as tearing/flickering. This problem is more noticeable in cases where the
>   Guest compositor has only one backbuffer such as Xorg + dirtfyFb.
> 
> - It also prevents the Guest compositor from rendering faster than the Host refresh
>   rate. In other words, it just sets the upper bound in terms of the buffer submission
>   rate as there is no point in going over the Host refresh rate, which would likely
>   lead to wastage of GPU cycles and dropped frames.
> 
> Therefore, this fence is really needed for Guest blobs including imported dmabufs.

Thanks a lot

-- 
Best regards,
Dmitry