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