Hi, > > Sure, we can move the rendering to the server side and provide just the > > final result in a shared memory block to the local client (when a client > > supporting that connects). I think it makes sense to use new commands > > (be it extended gl-scanout or something else) for this. I'd expect > > Please, let's not try to fit something that is not in our radar. We > can easily add flags or new messages. Yes, makes sense. We are not even close to have some workable design for the shm approach. Lets focus on the gl bits, where we have working code. shm can follow later, or maybe not if it turns out there is no real need for it any more once we have gl. After thinking about shm a bit more I can't see any real advantages of shm, other than not requiring opengl + dma-bufs. There always will be one copy needed, from guest memory to host gpu memory. With gl qemu will do that, when copying the guest framebuffer into the texture. With shm spice client will have to do it instead, the copy doesn't go away even if we manage to export the qxl device memory as shm segment somehow so spice client has direct access. cheers, Gerd _______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/spice-devel