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) or wait for the previous fb that was submitted earlier (in the previous repaint cycle) to be processed (explicit sync). 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. Ideally, I'd like to have Explicit sync but until 2) above happens, Explicit flush can be a reasonable alternative given the blit that happens with GTK/SDL backends. By making the Guest wait until the UI has submitted the buffer to the Host windowing system, we can theoretically tie the Guest repaint freq to the Host vblank and thus have Guest apps render at 60 FPS by default instead of 90 FPS that I see without expflush. This feature would also help Windows guests that can only do frontbuffer rendering with Blobs. > > I still think it makes sense extend the resource_flush and set_scanout > commands for that, for example by adding a flag for the flags field in > the request header. That way it is clear what exactly you are waiting > for. You can also attach a fence to the request which you can later > wait on. [Kasireddy, Vivek] Yeah, I am reluctant to add a new cmd as well but I want it to work for all Guests and Hosts. Anyway, let me try your idea of adding specific flags and see if it works. Thanks, Vivek > > take care, > Gerd
