Time for a status update for virtio-gpu development, so lets go ...

Before we begin: If you want follow development and discussions more closely head over to the virgl project at freedesktop gitlab. Git repos are there, most discussions are happening in gitlab issues.

What happened

Over the course of the last year (2019) a bunch of cleanups happened in the virtio-gpu linux kernel driver code base, to prepare for the planned changes and to reduce the code size by using common drm code. Memory management was switched over to use the shmem helpers instead of ttm. fbdev support (for the framebuffer console) was switched over to the generic drm fbdev emulation. fence support was improved. Various bugfixes.

Planned feature: shared mappings

Little change to reduce image data copying. Currently resources have a guest and a host buffer, and there are transfer commands to copy data between the two. Shared mappings allow the host to use the guest buffer directly.

On the guest side this is pretty simple, the guest only needs to inform the host that a shared mapping for the given resource -- so the host might see changes without explicit transfer commands -- is fine.

On the host side this is a bit more involved. Qemu will create a dma-buf for the resource, using the udmabuf driver. Which in turn allows qemu create a linear mapping of the resource, even if it is scattered in guest memory. That way the resource can be used directly (i.e. a pixman image created for it, ...)

Status: Almost ready to be submitted upstream.

Planned feature: blob resources

Currently virtio-gpu resources always have a format attached to it. So they are all-in-one objects, handling both memory management and image metadata. Combining both works ok for opengl, because we have a 1:1 relationship there. It will not work for vulkan though because the memory management works radically different there.

The drm subsystem has separate entities too: gem objects for memory management and framebuffer objects for the format metadata. That is difficuilt to model for virtio-gpu. virtio-gpu supports only a single format for dumb framebuffers because of that. dma-buf imports can't be supported too.

Blob resources will all fix that. A blob resource is just a bunch of bytes, i.e. it has only the memory management aspect.

Status: Proof-of-concept works. Various details are to be hashed out. Next in line after "shared mappings" feature.

Planned feature: metadata query

Allows guest userspace to query host renderer for capabilities and allocation requirements. Simliar to capsets but more flexible.

Status: Some test code exists. Not fully clear yet whenever that'll makes sense as feature on its own. Maybe it'll be folded into vulkan support.

Planned feature: host memory

For some features -- coherent memory for example, which is required by vulkan and at least one opengl extension -- the host gpu driver must allocate resources. So the model of using guest allocated memory for resources doesn't work, we have to map the host-allocated resources into the guest address space instead.

Virtio recently got support for (host-managed) shared memory, because virtiofs needs this for dax support. The plan is to use that for virtio-gpu too.

Status: Incomplete test code exists. Alot of the kernel driver cleanups where done to prepare the driver for this.

Planned feature: vulkan support

It's coming, but will surely take a while to actually arrive. As you have proably noticed while reading the article plans are already done with vulkan in mind, even if features are useful without vulkan, so we don't have to change things again when vulkan actually lands.