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

[Gerd Hoffmann]

> 1) Currently, the only way to fill a resource in virtio-gpu is either via a
> transfer from the backing memory to the resource, or to submit commands
> that render to the resource. This is not optimal for software rendering or
> texture upload situations because of the additional copy this transfer
> necessitates. I propose that an additional virtio-gpu command, perhaps
> gated by a virtio feature bit, be made that allows the guest to request
> mapping of a resource directly into guest physical address space.

Yes, feature bit would be required for this.

> With this
> virtio command, requests to mmap a virgio-gpu resource by the guest's user
> space applications, perhaps through a DRM ioctl on the buffer object handle
> or an mmap on the dmabuf/prime FD, could be fulfilled without additional
> copy operations to flush data that was written.

I'd rather try to do it the other way around:  Turn the guest resources
into host dma-bufs.  Needs a some help from the linux kernel of course,
with a little helper driver, or by pimping up vgem.

> 2) Currently, the virglrenderer library allocates host side GPU memory for
> backing resources using standard OpenGL texture creation functions. While
> virglrenderer does support exporting resources, this does not work very
> well on Chrome OS. More details about that can be found at
> http://crbug.com/779356 . The root of the issue seems to be that
> EGL_MESA_image_dma_buf_export, the extension used by virglrenderer to
> export resources, does not function properly.

Fix it then?

> The solution that was agreed
> upon was to use gbm (minigbm in the case of Chrome OS), to allocate all
> buffers that are destined to be exported because this is the well tested
> path. However, virglrenderer has no API for importing any kind of buffer,
> so one would need to be added.

I think it makes sense to have that.  When operating with dma-bufs for
guest resources (as outlined above) that'll be needed too so
virglrenderer can use them without copying.

Puts current ressource management upside down though.  Right now
virglrenderer manages ressources, this would basically move resource
management into the hands of crosvm/qemu.

Also we need to take care that we don't create security holes that way.
Anything which needs verification can not use a shared mapping.  Not
fully sure whenever that applies to anything beside the exec buffer
(which isn't a resource anyway).

cheers,
  Gerd