Hi Gerd,
Thank you for taking the time to explain how support for blob resources needs
to be added. We are going to get started soon and here are the tasks we are
planning to do in order of priority:

1) Add support for VIRTIO_GPU_BLOB_MEM_GUEST +
VIRTIO_GPU_BLOB_FLAG_USE_SHAREABLE
2) Upgrade Qemu GTK UI from 3.22 to 4.x
3) Add explicit sync support to GTK4 and Qemu UI
4) Add support for VIRTGPU_BLOB_MEM_HOST3D 

We'll start sending patches as we go along.

Thanks,
Vivek


> > [Kasireddy, Vivek] Sure, we'll take a look at your work and use that
> > as a starting point. Roughly, how much of your work can be reused?
> 
> There are some small udmabuf support patches which can probably be reused pretty much
> as-is.  Everything else needs larger changes I suspect, but it's been a while I looked at this
> ...
> 
> > Also, given my limited understanding of how discrete GPUs work, I was
> > wondering how many copies would there need to be with blob
> > resources/dmabufs and whether a zero-copy goal would be feasible or not?
> 
> Good question.
> 
> Right now there are two copies (gtk ui):
> 
>   (1) guest ram -> DisplaySurface -> gtk widget (gl=off), or
>   (2) guest ram -> DisplaySurface -> texture (gl=on).
> 
> You should be able to reduce this to one copy for gl=on ...
> 
>   (3) guest ram -> texture
> 
> ... by taking DisplaySurface out of the picture, without any changes to the guest/host
> interface.  Drawback is that it requires adding an opengl dependency to virtio-gpu even
> with virgl=off, because the virtio-gpu device will have to handle the copy to the texture
> then, in response to guest TRANSFER commands.
> 
> When adding blob resource support:
> 
> Easiest is probably supporting VIRTIO_GPU_BLOB_MEM_GUEST (largely identical to
> non-blob resources) with VIRTIO_GPU_BLOB_FLAG_USE_SHAREABLE
> (allows the host to create a shared mapping).  Then you can go create a udmabuf for the
> resource on the host side.  For the non-gl code path you can mmap() the udmabuf (which
> gives you a linear mapping for the scattered guest pages) and create a DisplaySurface
> backed by guest ram pages (removing the guest ram -> DisplaySurface copy).  For the gl
> code path you can create a texture backed by the udmabuf and go render on the host
> without copying at all.
> 
> Using VIRTIO_GPU_BLOB_MEM_GUEST +
> VIRTIO_GPU_BLOB_FLAG_USE_SHAREABLE for resources needs guest changes too,
> either in mesa (when using virgl) or the kernel driver's dumb buffer handling (when not
> using virgl).
> 
> Alternatively (listed more for completeness):
> 
> You can create a blob resource with VIRTGPU_BLOB_MEM_HOST3D (requires virgl,
> see also virgl_drm_winsys_resource_create_blob in mesa).  It will be allocated by the
> host, then mapped into the guest using a virtual pci memory bar.  Guest userspace (aka
> mesa driver) can mmap() these resources and has direct, zero-copy access to the host
> resource.
> 
> Going to dma-buf export that, import into i915, then let the gpu render implies we are
> doing p2p dma from a physical (pci-assigned) device to the memory bar of a virtual pci
> device.
> 
> Doing that should be possible, but frankly I would be surprised if that actually works out-
> of-the-box.  Dunno how many dragons are lurking here.
> Could become an interesting challenge to make that fly.
> 
> > > Beside the code duplication this is also a maintainance issue.  This
> > > adds one more configuration to virtio-gpu.  Right now you can build
> > > virtio-gpu with virgl (depends on opengl), or you can build without
> > > virgl (doesn't use opengl then).  I don't think it is a good idea to add a third mode,
> without virgl support but using opengl for blob dma-bufs.
> > [Kasireddy, Vivek] We'll have to re-visit this part but for our
> > use-case with virtio-gpu, we are disabling virglrenderer in Qemu and
> > virgl DRI driver in the Guest. However, we still need to use
> > Opengl/EGL to convert the dmabuf (guest fb) to texture and render as part of the
> UI/GTK updates.
> 
> Well, VIRTGPU_BLOB_MEM_HOST3D blob resources are created using virgl renderer
> commands (VIRGL_CCMD_PIPE_RESOURCE_CREATE).  So supporting that without
> virglrenderer is not an option.
> 
> VIRTIO_GPU_BLOB_MEM_GUEST might be possible without too much effort.
> 
> > > > On a different note, any particular reason why Qemu UI EGL
> > > > implementation is limited to Xorg and not extended to
> > > > Wayland/Weston for which there is GTK glarea?
> > >
> > > Well, ideally I'd love to just use glarea.  Which happens on wayland.
> > >
> > > The problem with Xorg is that the gtk x11 backend uses glx not egl
> > > to create an opengl context for glarea.  At least that used to be
> > > the case in the past, maybe that has changed with newer versions.
> > > qemu needs egl contexts though, otherwise dma-bufs don't work.  So
> > > we are stuck with our own egl widget implementation for now.  Probably we will be
> able to drop it at some point in the future.
> 
> > [Kasireddy, Vivek] GTK X11 backend still uses GLX and it seems like
> > that is not going to change anytime soon.
> 
> Hmm, so the egl backend has to stay for the time being.
> 
> > Having said that, I was wondering if it makes sense to add a new
> > purely Wayland backend besides GtkGlArea so that Qemu UI can more
> > quickly adopt new features such as explicit sync. I was thinking about the new backend
> being similar to this:
> > https://cgit.freedesktop.org/wayland/weston/tree/clients/simple-dmabuf
> > -egl.c
> 
> I'd prefer to not do that.
> 
> > The reason why I am proposing this idea is because even if we manage
> > to add explicit sync support to GTK and it gets merged, upgrading Qemu
> > GTK support from 3.22 to > 4.x may prove to be daunting. Currently,
> > the way I am doing explicit sync is by adding these new APIs to GTK and calling them
> from Qemu:
> 
> Well, we had the same code supporting gtk2+3 with #ifdefs.  There are also #ifdefs to
> avoid using functions deprecated during 3.x lifetime.
> So I expect porting to gtk4 wouldn't be too bad.
> 
> Also I expect qemu wouldn't be the only application needing sync support, so trying to get
> that integrated with upstream gtk certainly makes sense.
> 
> > Lastly, on a different note, I noticed that there is a virtio-gpu Windows driver here:
> > https://github.com/virtio-win/kvm-guest-drivers-windows/tree/master/vi
> > ogpu
> >
> > We are going to try it out but do you know how up to date it is kept?
> 
> No, not following development closely.
> 
> take care,
>   Gerd