RE: [PATCH 1/3] virtio-gpu uapi: Add VIRTIO_GPU_F_EXPLICIT_FLUSH feature

From: "Kasireddy, Vivek" <vivek.kasireddy@intel.com>
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: "dri-devel@lists.freedesktop.org" <dri-devel@lists.freedesktop.org>
Subject: RE: [PATCH 1/3] virtio-gpu uapi: Add VIRTIO_GPU_F_EXPLICIT_FLUSH feature
Date: Tue, 18 May 2021 05:45:03 +0000	[thread overview]
Message-ID: <9725d763e1474713adf5021a87df26a2@intel.com> (raw)
In-Reply-To: <20210514103834.vvfgjvfnc2hphr4f@sirius.home.kraxel.org>

Hi Gerd,

> > [Kasireddy, Vivek] Correct, that is exactly what I want -- make the Guest wait
> > until it gets notified that the Host is completely done processing/using the fb.
> > However, there can be two resources the guest can be made to wait on: wait for
> > the new/current fb that is being submitted to be processed (explicit flush)
> 
> That would be wait on resource_flush case, right?
[Kasireddy, Vivek] Yes, correct.

> 
> > or wait for the previous fb that was submitted earlier (in the
> > previous repaint cycle) to be processed (explicit sync).
> 
> That would be the wait on set_scanout case, right?
[Kasireddy, Vivek] Right.

> 
> And it would effectively wait on the previous fb not being needed by the
> host any more (because the page-flip to the new fb completed) so the
> guest can re-use the previous fb to render the next frame, right?
[Kasireddy, Vivek] Yup.

> 
> (also when doing front-buffer rendering with xorg/fbcon and then doing a
> virtual console switch the guest could wait for the console switch being
> completed).
> 
> > IIUC, Explicit sync only makes sense if 1) the Host windowing system also supports
> > that feature/protocol (currently only upstream Weston does but I'd like to add it to
> > Mutter if no one else does) or if there is a way to figure out (dma-buf sync file?) if
> > the Host has completely processed the fb and 2) if Qemu UI is not doing a blit and
> > instead submitting the guest fb/dmabuf directly to the Host windowing system.
> > As you are aware, 2) can possibly be done with dbus/pipewire Qemu UI backends
> > (I'll explore this soon) but not with GTK or SDL.
> 
> Well, I think we need to clearly define the wait flag semantics. 
[Kasireddy, Vivek] At-least with our passthrough use-case (maybe not with Virgl),
I think we need to ensure the following criteria:
1) With Blobs, ensure that the Guest and Host would never use the dmabuf/FB at
the same time. 
2) The Guest should not render more frames than the refresh rate of the Host so
that GPU resources are not wasted.

> Should resource_flush with wait flag wait until the host is done reading the
> resource (blit done)?
[Kasireddy, Vivek] I started with this but did not find it useful as it did not meet
2) above. However, I think we could have a flag for this if the Guest is using a
virtual vblank/timer and only wants to wait until the blit is done.

> Or should it wait until the host screen has been
> updated (gtk draw callback completed)?
[Kasireddy, Vivek] This is what the last 7 patches of my Blob series (v3) do. So,
we'd want to have a separate flag for this as well. And, lastly, we are going to
need another flag for the set_scanout case where we wait for the previous
fb to be synchronized.

> 
> Everything else will be a host/guest implementation detail then, and
> of course this needs some integration with the UI on the host side and
> different UIs might have to do different things.
[Kasireddy, Vivek] Sure, I think we can start with GTK and go from there.

> 
> On the guest side integrating this with fences will give us enough
> flexibility on how we want handle the waits.  Simplest would be to just
> block. 
[Kasireddy, Vivek] I agree; simply blocking (dma_fence_wait) is more than
enough for most use-cases.

>We could implement virtual vblanks, which would probably make
> most userspace work fine without explicit virtio-gpu support.  If needed
> we could even give userspace access to the fence so it can choose how to
> wait.
[Kasireddy, Vivek] Virtual vblanks is not a bad idea but I think blocking with
fences in the Guest kernel space seems more simpler. And, sharing fences with
the Guest compositor is also very interesting but I suspect we might need to
modify the compositor for this use-case, which might be a non-starter. Lastly,
even with virtual vblanks, we still need to make sure that we meet the two
criteria mentioned above. 

Thanks,
Vivek