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

[Gerd Hoffmann]

On Tue, Mar 02, 2021 at 12:03:57AM -0800, Vivek Kasireddy wrote:
> 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.

Yes, it surely makes sense to go into that direction.
The patch as-is doesn't, it breaks the guest/host interface.
That's ok-ish for a quick proof-of-concept, but clearly not
merge-able.

> TODO:
> - Use Blob resources for getting meta-data such as modifier, format, etc.

That is pretty much mandatory.  Without blob resources there is no
concept of resources shared between host and guest in virtio-gpu,
all data is explicitly copied with transfer commands.

Which implies quite a bit of work because we don't have blob resource
support in qemu yet.

> - Test with Virgil rendered BOs to see if this can be used in that case..

That also opens up the question how to go forward with virtio-gpu in
general.  The object hierarchy we have right now (skipping pci + vga
variants for simplicity):

  TYPE_VIRTIO_GPU_BASE (abstract base)
   -> TYPE_VIRTIO_GPU (in-qemu implementation)
   -> TYPE_VHOST_USER_GPU (vhost-user implementation)

When compiled with opengl + virgl TYPE_VIRTIO_GPU has a virgl=on/off
property.  Having a single device is not ideal for modular builds.
because the hw-display-virtio-gpu.so module has a dependency on
ui-opengl.so so that is needed (due to symbol references) even for the
virgl=off case.  Also the code is a bit of a #ifdef mess.

I think we should split TYPE_VIRTIO_GPU into two devices.  Remove
virgl+opengl support from TYPE_VIRTIO_GPU.  Add a new
TYPE_VIRTIO_GPU_VIRGL, with either TYPE_VIRTIO_GPU or
TYPE_VIRTIO_GPU_BASE as parent (not sure which is easier), have all
opengl/virgl support code there.

I think when using opengl it makes sense to also require virgl, so we
can use the virglrenderer library to manage blob resources (even when
the actual rendering isn't done with virgl).  Also reduces the
complexity and test matrix.

Maybe it even makes sense to deprecate in-qemu virgl support and focus
exclusively on the vhost-user implementation, so we don't have to
duplicate all work for both implementations.

> 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?

There is graphic_hw_gl_block + graphic_hw_gl_flushed for syncronization.
Right now this is only wired up in spice, and it is rather simple (just
stalls virgl rendering instead of providing per-buffer syncronization).

> - 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).

Well, if the guest does frontbuffer rendering we can't do much about it
and have to live with rendering glitches I guess.

take care,
  Gerd