Hi Dmitry,
> -Original Message-
> From: Dmitry Osipenko
> Sent: Monday, November 13, 2023 8:16 AM
> To: Kim, Dongwon ; dri-
> de...@lists.freedesktop.org
> Cc: kra...@redhat.com; Kasireddy, Vivek
> Subject: Re: [RFC PATCH v2 1/1] drm/virtio: new fence for every pl
On 10/23/23 20:31, Kim, Dongwon wrote:
...
>> 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
> -Original Message-
> From: Dmitry Osipenko
> Sent: Monday, October 23, 2023 5:24 AM
> To: Kim, Dongwon ; dri-devel@lists.freedesktop.org
> Cc: kra...@redhat.com; Kasireddy, Vivek
> 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
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
