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

[Dave Airlie]

On 3 May 2018 at 09:21, Stéphane Marchesin <marcheu at chromium.org> wrote:
> 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.
>

I think for most things it does, tiling really matters, and we are never
going to get tiling inside the guest that is useful.

Even for vulkan we have to do linear buffer->image uploads for most
apps.

The iovec copy would be removable with a GL extension (granted
 a very messy and hard to test GL extension) that lets you pass
iovecs instead of flat pointers.

I also wonder if some variant on AMD_pinned_memory could be useful.

Dave.