[Spice-devel] RFC: Integrating Virgil and Spice

[Dave Airlie]

>
> Ah, host dma-buf not guest dma-buf.  It makes more sense then.

yes host side for the viewer.
>
> So virgil just opens one of those new render-only drm nodes, asks the
> gpu to process the rendering ops from the guest & store the results in a
> dma-buf, then this dma-buf must be displayed somehow, correct?

Yes, the viewer would essentially be a compositing process, taking the outputs
from multiple VMs and deciding where to draw them. I suppose like boxes
does now.

>
>> When displaying locally (so SDL-2 or gtk ui), we want to avoid the read by
>> passing a kernel dma_buf handle from the virtual card (in this case
>> virtio-vga with Virgil) to the ui (in this case SDL-2), so it can then
>> directly ask the GPU to blit from that dma_buf to its own visible surface.
>
> Hmm.  Both SDL and gtk ui have the problem that they effectively bind
> your VM to the desktop session.  Which is not what you want for anything
> but short-running test VMs.  It's also a PITA to maintain them with
> libvirt.

Yeah I've hit that. So far virgil is only running via libvirt with a very hacked
insecure config to draw to the local X server of my user. Getting past that
is however going to involve a bit of lifting all over the place.

>
> Any plans for a separate UI process?  Something using a unix socket for
> control commands and to hand over a dma-buf handle using fd descriptor
> passing maybe?

That would be the local rendering solution I think we'd prefer,

qemu runs as qemu user, uses EGL to talk to the drm render-nodes,
has some sort of unix socket that the viewer connects to and can hand
fds across, then the client viewer uses EGL or GLX to render on-screen
and import the handles into EGL and displays the contents, there may
be a small bit of sync info to send across.

For remoting then we'd have an extra readback (slow) from the GPU and
then spice or vnc encoding stages.

Dave.