This is still a WIP/RFC patch that attempts to use dmabufs for display updates with the help of Udmabuf driver instead of pixman. This patch is posted to the ML to elicit feedback and start a discussion whether something like this would be useful or not for mainly non-Virgl rendered BOs and also potentially in other cases.
This patch was tested to work OK with Weston version from here: https://gitlab.freedesktop.org/Vivek/weston/-/blob/virtgpu_dmabuf/libweston/backend-drm/drm-gbm.c#L282 and Qemu launched with these options: qemu-system-x86_64 -m 8192m .... -device virtio-gpu-pci,max_outputs=1 -display gtk,gl=on ..... -object memory-backend-memfd,id=mem1,size=8192M -machine memory-backend=mem1 TODO: - Use Blob resources for getting meta-data such as modifier, format, etc. - Test with Virgil rendered BOs to see if this can be used in that case.. Considerations/Challenges: - One of the main concerns with using dmabufs is how to synchronize access to them and this use-case is no different. If the Guest is running Weston, then it could use a maximum of 4 color buffers but uses only 2 by default and flips between them if it is not sharing the FBs with other plugins while running with the drm backend. In this case, how do we make sure that Weston and Qemu UI are not using the same buffer at any given time? This is complicated by the fact that the toolkits (that Qemu UI uses) do not seem to provide a way to wait for buffer events. For example, GTK does not apparently provide a way to either wait for "send done" events or register a listener for wl_buffer release events that native Wayland/Weston clients have access to. - If we have Xorg running in the Guest, then it gets even more interesting as Xorg in some cases does frontbuffer rendering (uses DRM_IOCTL_MODE_DIRTYFB). The same challenge arises in this case as well to determine how to safely destroy or reuse the buffer in the Guest while it might be used on the Host. Some of the potential solutions for addressing the above challenges include using syncronization primitives such as fences/sync objs in Qemu UI to determine when a buffer/dmabuf is consumed by the Host display server/compositor and hold up the vblank/flip done event until that time. But this one comes with a performance concern as the Guest would not be able to queue up another flip until the previous one finishes. Other options include caching 2 or more dmabufs and releasing the others but this may not be feasible without having to modify the Guest display server/ compositor to use all color buffers or create a new color buffer each time. Cc: Gerd Hoffmann <kra...@redhat.com> Cc: Marc-André Lureau <marcandre.lur...@redhat.com> Cc: Dongwon Kim <dongwon....@intel.com> Cc: Daniel Vetter <daniel.vet...@ffwll.ch> Vivek Kasireddy (1): virtio-gpu: Use dmabuf for display updates if possible instead of pixman hw/display/virtio-gpu.c | 133 +++++++++++++++++++++++++++++++++ include/hw/virtio/virtio-gpu.h | 12 +++ 2 files changed, 145 insertions(+) -- 2.26.2
