[virglrenderer-devel] coherent memory access for virgl

[Gurchetan Singh]

On Thu, Oct 4, 2018 at 9:53 PM Gerd Hoffmann <kraxel at redhat.com> wrote:
>
> > > Well, udmabuf can be used to get a linear mapping of a scattered
> > > resource.  Now qemu can map that udmabuf, the pass on the one-elem-iov
> > > to virglrenderer.  Or qemu can pass the udmabuf handle to virglrenderer.
> > >
> > > The later has the advantage that virglrenderer can possibly do more with
> > > the dmabuf than simply mmap()ing it (specifically let the gpu driver
> > > import it).  The former has the advantage that it works without
> > > virglrenderer changes.
>
> > So at Collabora, we are also looking at reducing copies during texture uploads.
> > We were thinking about the second conclusion: "qemu can pass the udmabuf handle to virglrenderer"
> > and I'd like to recapitulate what has been discussed here on this regard.
>
> > My understanding is that we'd require that the VMM allocates all the
> > memory of the machine in a single memfd region.
>
> Can be multiple memfd regions.  Otherwise correct.

By default, it seems QEMU allocates anonymous pages
(qemu_anon_ram_alloc).  Is the "object
memory-backend-memfd,id=mem1,size=1G" option needed to make udmabuf
work?

>
> > Then, when a client in the guest requests a texture upload, Mesa would create a virtio-gpu resource
> > to wrap the buffer that the client passed with the texture data.
> > virtio-gpu would pass the physical addresses backing that buffer to the virtio queue message
> > for creating a buffer or attaching memory to it.
> > When the VMM processes the message, it would create a dmabuf via udmabuf out of those physical addresses.
>
> Yes.
>
> > That dmabuf can then be mapped and the address can be directly passed to read_transfer_data in virglrenderer.
>
> Yes.
>
> > Did I get that right? If we agree with a plan, we will be happy to help with the implementation or the code review.
>
> Some experimental code is there already:
>
>   https://git.kraxel.org/cgit/linux/log/?h=drm-virtio-ttm
>   https://git.kraxel.org/cgit/qemu/log/?h=sirius/virtio-api
>
> Take care, both branches are moving targets as I'm busy hashing out the
> virtio protocol changes needed.  The current way (simply adding flags)
> will most likely not stay that way.
>
> Also I havn't touched 3d mode and virglrenderer yet, right now I'm
> testing with dumb gem objects in 2d mode.
>
> cheers,
>   Gerd
>