[RFC 0/1] Use dmabufs for display updates instead of pixman

[Vivek Kasireddy]

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 <kraxel@redhat.com>
Cc: Marc-André Lureau <marcandre.lureau@redhat.com>
Cc: Dongwon Kim <dongwon.kim@intel.com>
Cc: Daniel Vetter <daniel.vetter@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