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