RE: [RFC PATCH v2 1/1] drm/virtio: new fence for every plane update
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 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
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? 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. Using virtio-vga-gl+virgl+max_outputs=2 I don't see any issues. In the same 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. Please give me a test case that is reproducing using latest version of vanilla/upstream Qemu. -- Best regards, Dmitry
RE: [RFC PATCH v2 1/1] drm/virtio: new fence for every plane update
> -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 updated concurrently. So it is > > needed to allocate a fence for every plane state instead of the framebuffer. > > > > The plane state for virtio-gpu, "struct virtio_gpu_plane_state" is > > added for this. This structure represents drm_plane_state and it > > contains the reference to virtio_gpu_fence, which was previously in "struct > virtio_gpu_framebuffer". > > > > "virtio_gpu_plane_duplicate_state" is added as well to create a > > virtio_gpu_plane_state on top of duplicated drm plane state. > > > > Several drm helpers were slightly modified accordingly to use the > > fence in new plane state structure. virtio_gpu_plane_cleanup_fb was > > completely removed as dma_fence_put shouldn't be called here as it can > > mess up with the ref count of the fence. The fence should be put after > > the fence is signaled in virtio_gpu_resource_flush then released in > > virtio_gpu_array_add_fence while the next virtio message is being queued. > > > > Also, the condition for adding fence, (plane->state->fb != > > new_state->fb) was removed since we now allocate a new fence for the > > new plane state even if both old and new planes are pointing to the same > framebuffer. > > > > v2: removed virtio_gpu_plane_duplicate_state as the existing helper, > > drm_atomic_helper_plane_destroy_state does the same. > > > > Cc: Dmitry Osipenko > > Cc: Gerd Hoffmann > > Cc: Vivek Kasireddy > > Signed-off-by: Dongwon Kim > > --- > > drivers/gpu/drm/virtio/virtgpu_drv.h | 7 +++ > > drivers/gpu/drm/virtio/virtgpu_plane.c | 66 > > +- > > 2 files changed, 51 insertions(+), 22 deletions(-) > > 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! > > -- > Best regards, > Dmitry
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 updated concurrently. So it is needed to allocate a > fence for every plane state instead of the framebuffer. > > The plane state for virtio-gpu, "struct virtio_gpu_plane_state" is added for > this. This structure represents drm_plane_state and it contains the reference > to virtio_gpu_fence, which was previously in "struct virtio_gpu_framebuffer". > > "virtio_gpu_plane_duplicate_state" is added as well to create a > virtio_gpu_plane_state on top of duplicated drm plane state. > > Several drm helpers were slightly modified accordingly to use the fence in new > plane state structure. virtio_gpu_plane_cleanup_fb was completely removed as > dma_fence_put shouldn't be called here as it can mess up with the ref count > of the fence. The fence should be put after the fence is signaled in > virtio_gpu_resource_flush then released in virtio_gpu_array_add_fence while > the next virtio message is being queued. > > Also, the condition for adding fence, (plane->state->fb != new_state->fb) was > removed since we now allocate a new fence for the new plane state even if both > old and new planes are pointing to the same framebuffer. > > v2: removed virtio_gpu_plane_duplicate_state as the existing helper, > drm_atomic_helper_plane_destroy_state does the same. > > Cc: Dmitry Osipenko > Cc: Gerd Hoffmann > Cc: Vivek Kasireddy > Signed-off-by: Dongwon Kim > --- > drivers/gpu/drm/virtio/virtgpu_drv.h | 7 +++ > drivers/gpu/drm/virtio/virtgpu_plane.c | 66 +- > 2 files changed, 51 insertions(+), 22 deletions(-) Please write a guide how to test it. Are you using spice for the multi-display viewer? -- Best regards, Dmitry
