[RFC PATCH v2 1/1] drm/virtio: new fence for every plane update

[Kim, Dongwon]

Hi Dmitry,


> -----Original Message-----
> From: Dmitry Osipenko <dmitry.osipenko at collabora.com>
> Sent: Monday, November 13, 2023 8:16 AM
> To: Kim, Dongwon <dongwon.kim at intel.com>; dri-
> devel at lists.freedesktop.org
> Cc: kraxel at redhat.com; Kasireddy, Vivek <vivek.kasireddy at intel.com>
> Subject: Re: [RFC PATCH v2 1/1] drm/virtio: new fence for every plane update
> 
> 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 of client solutions we use but we primarily use QEMU GTK-UI
> w/ multi displays (QEMU with this params '-device virtio-
> vga,max_outputs=2,blob=true').
> > Thanks!
> 
> 

> I'm having trouble wit h reproducing the issue. For GTK-UI you should be
> using virtio-vga-gl, shouldn't you?

[Kim, Dongwon] 
I was trying to replicate the issue with more general case as our solution - Mesa kmsro (iris w/ render target imported from virtio-gpu), using 
i915 for render-only device and virtio-gpu as a display only device -https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9592
hasn't been upstreamed yet. But I got no luck. What I tried was Mesa - sw-rasterizer + virtio-gpu and it worked just fine without any issue.
I think the reason would be some timing difference. The problem happens when a cycle of prepare->update-plane->cleanup is overlapped with another,
but that didn't seem to happen in the test cases I tried.

> 
> I assume you meant that your simple case is reproducible using dGPU,
> correct? I need a test case that is reproducing using virgl and no dGPU.

[Kim, Dongwon] 
We use iGPU only. And we don’t use virgl. We enabled SR-IOV on iGPU so virtual machine can see it as a dedicated HW and it can run
HW driver (i915 + Iris) on it.  

> 
> Using virtio-vga-gl+virgl+max_outputs=2 I don't see any issues. In the same

[Kim, Dongwon] 
Yeah, this makes me think again the problem can be replicated only in our current setup - Iris/i915 + virtio-gpu and zero copy
virtio-gpu display sharing (blob=true)

> time switching to the second virtual display doesn't work with Qemu's GTK UI,
> I'm getting black screen for the second display. In the KDE settings I have two
> displays and it says both are active. For the first display that works, I don't
> see wrong frames ordering.

[Kim, Dongwon] 
You mean you switched to the second virtual display by changing between tabs? There were some issue with GTK-UI regarding
tab handling. I fixed some of them. What version of QEMU are you using? Have you tried the latest one like > 8.0?

Wrong ordering of frame is actually what the other patch - drm/virtio: drm_gem_plane_helper_prepare_fb for obj is solving.
The problem this patch is trying to solve is complete lock up of virtual display update and fence timeout errors (i915) on the dmesg. 

Anyway, I just can't say the problem I have been trying to solve can happen on most of general cases but wouldn't it makes sense
to you that the fence should be assigned per plane update instead of FB in general? Having fence per plane update is working in the
same way as before but it prevents any potential issue like our case. 

> 
> Please give me a test case that is reproducing using latest version of
> vanilla/upstream Qemu.
> 
> --
> Best regards,
> Dmitry