On Wed, May 12, 2021 at 09:18:37PM +0000, Kasireddy, Vivek wrote: > Hi Gerd, > > > > However, as part of this feature (explicit flush), I'd like to make the Guest wait until > > > the current resource (as specified by resource_flush or set_scanout) is flushed or > > > synchronized. But for a different feature I am thinking of (explicit sync), I'd like to > > > make the Guest wait for the previous buffer/resource submitted (available via > > > old_state->fb). > > > > For page-flipping I guess? i.e. you want submit a new framebuffer, then > > wait until the host doesn't need the previous one? That is likewise > > linked to a command, although it is set_scanout this time. > [Kasireddy, Vivek] Mainly for page-flipping but I'd also like to have fbcon, Xorg that > do frontbuffer rendering/updates to work seamlessly as well. > > > > > So, right now qemu simply queues the request and completes the command > > when a guest sends a resource_flush our set_scanout command. You want > > be notified when the host is actually done processing the request. > [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? > 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? 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? (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. Should resource_flush with wait flag wait until the host is done reading the resource (blit done)? Or should it wait until the host screen has been updated (gtk draw callback completed)? 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. 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. 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. take care, Gerd
