> > 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. _______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/spice-devel