[Spice-devel] RFC: Integrating Virgil and Spice

[Marc-André Lureau]

----- Original Message -----
> >
> > 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.

Boxes, for the display part, is just plain gtk+, regular x11 cairo (the animation part is using clutter/gl, but we bypass that for display)

Although this is limited to local rendering, we could teach the spice-gtk API to provide a gl texture or RBO. The client interface and further integration for this could be prototyped using the spice 2d gl canvas today. For gtk/cairo, there is a cairo_gl_surface_create_for_texture(), but for some reason it is not advertized. I also wonder if somebody tried to teach gtk+ to use a cairo gl surface (apparently not upstream).  Without this, cairo will have to do ReadPixels... Or the gtk widget could embedd its own GL window, that's probably the way to go. I wondered how webkit-gtk does webgl. It looks like they use an offscreen gl window. I will try to verify this.

> >
> >> 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.

That would possibly open the possibility to run the remote server out of qemu.