Hi, > > But it is different from how multihead works on physical hardware these > > days. Experience shows that usually it works better long-term when you > > model virtual hardware as close as possible to physical hardware. > > I though multi-monitor (on same gpu) was more often done in hw with a > single scanout buffer. xorg userspace drivers used to work that way, yes. I think kms drivers don't (not fully sure though, possibly it depends on the driver). Wayland has per-scanout framebuffers. > > The later would be very similiar to the gl scanout model. I also > > suspect the later would be _way_ easier to implement. With the former > > model all surfaces are suddenly shared memory between client and server, > > and that probably renders a bunch of assumptions all over the spice code > > base invalid. > > If you create a "primary" surface with surface_create, that's > basically all you need to start displaying. It could quite easily > learn to take a shm fd while keeping the rest of the Spice > qxl/2od/canvas semantic. But then you still stream all the qxl commands and image data over the socket, so you don't save much compared to non-shm case. > > /me wonders whenever it is possible to translate a qxl command stream > > into an opengl command stream. That would allow quite efficient > > server-side rendering ... > > It exists > (http://cgit.freedesktop.org/spice/spice-common/tree/common/gl_canvas.c), but it is incomplete (not too bad, mainly missing off-surface). Beside it was really to slow too send to gpu, render, and read back to cpu before handling compression and streaming. Now that we are looking a gpu accelerated encoding or locale gl display, it could bring better results. Agree. gfx memory tends to be slow for cpu read access, so chances are high that the read back killed the performance. cheers, Gerd _______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/spice-devel