On Thu, Jun 09, 2022 at 06:24:43AM +0200, Gerd Hoffmann wrote:
> On Fri, Jun 03, 2022 at 02:18:49PM -0700, Dongwon Kim wrote:
> > Having one fence for a vgfb would cause conflict in case there are
> > multiple planes referencing the same vgfb (e.g. Xorg screen covering
> > two displays in extended mode) being flushed simultaneously. So it makes
> > sence to use a separated fence for each plane update to prevent this.
> >
> > vgfb->fence is not required anymore with the suggested code change so
> > both prepare_fb and cleanup_fb are removed since only fence creation/
> > freeing are done in there.
>
> The fences are allocated and released in prepare_fb + cleanup_fb for a
> reason: atomic_update must not fail.
In case fence allocation fails, it falls back to non-fence path so it
won't fail for primary-plane-update.
For cursor plane update, it returns if fence is NULL but we could change
it to just proceed and just make it skip waiting like,
if (fence) {
dma_fence_wait(&fence->f, true);
dma_fence_put(&fence->f);
}
Or maybe I can limit my suggested changes to primary-plane-update only.
What do you think about these?
>
> I guess virtio-gpu must be fixed to use drm_plane_state->fence
> correctly ...
I was thinking about this too but current functions (e.g.
virtio_gpu_cmd_transfer_to_host_2d) takes "struct virtio_gpu_fence".
Not sure what is the best way to connect drm_plane_state->fence to
virtio_gpu_fence without changing major function interfaces.
>
> take care,
> Gerd
>
