[virglrenderer-devel] Proposals for virtio-gpu and virglrenderer

[Stéphane Marchesin]

On Wed, May 2, 2018 at 1:18 AM Gerd Hoffmann <kraxel at redhat.com> wrote:

>     Hi,

> > How does this deal with tiling/unmappable resources? Most of the
resources
> > we allocate end up in tile VRAM hopefully, this may not even be
mappable.
> > When you use the GL APIs to map it we end up getting a transfer not a
direct
> > map so you get a copy there. If we bypass GL and go straight to
exporting
> > the buffer, we just get a tiled buffer which isn't that useful.
> >
> > Lets then assume you only want to map linear strided resources, you
envisage
> > exporting a precreated resource to a dma-buf, and somehow mmaping
> > the pages behind that resource into the guest memory space.
> >
> > Now the rules for what you can map where in guest VM are a bit hazy for
me,
> > maybe someone can expend more on how we can do this, do we need a PCI
> > BAR to have these things appear in or can they end up in random guest
pages?
> > Gerd?

> Yes, using a PCI bar to reserve some address space would be a safe way
> to handle this.

> I still think we should try to do it the other way around:  Not map the
> host ressources into the guest, but make the guest resources usable by
> the host.  Have a little helper driver which can turn the virtio-gpu
> ressource iov into a dmabuf (standalone or pimped up vgem), then run
> with that, to avoid the memcpy.  Possibly the gpu driver still has to
> copy stuff then, or the gpu copy itself via dma, but the gpu driver
> should be able to do whatever is best for the given host hardware ...

The GPU driver doesn't necessarily have to do a copy; so why not work
towards a design which can avoid these copies? I have measured that about
half the time of virgl texture uploads is spent on iovec copies, so we
could double the texture upload rate easily with such a mechanism. In
particular, newer APIs like Vulkan on the host side can provide coherent
memory which is usually just a direct view into the actual memory (and
therefore there is no copy). This could easily be used as a host-side
mechanism to lay this functionality on top of.

Stéphane


> First attempt on a standalone driver:
>           git://git.kraxel.org/linux udmabuf-gup-broken

> Uses get-user-pages, not going to work reliable with fork(2) (due to cow
> being fundamentally incompatible with dma-bufs).

> Second attempt (wip still, due to being busy with other stuff atm,
> doesn't even compile ...), supporting only memfd/shmem as backing
> storage for dmabufs:
>           git://git.kraxel.org/linux udmabuf

> > This is a bit of a stickler for me, I'm not sure the qemu folks would
want to
> > pull a rust build dependency into the tree,

> As I've understand things this was ment as alternative implementation,
> so rust would be an optional dependency.  But of course it implies we
> will have to maintain both rust and C version of the code ...

> cheers,
>     Gerd

> _______________________________________________
> virglrenderer-devel mailing list
> virglrenderer-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/virglrenderer-devel