Hi ----- Original Message ----- > On Do, 2015-12-17 at 10:53 -0500, Marc-André Lureau wrote: > > Hi > > > > > > How whould that be compatible with the spice MonitorConfig messages? I > > > > don't think it's necessary, and it could easily be added later if > > > > needed. > > > > > > Ahem, scratch that. MonitorConfig isn't going to fly with virtio-gpu > > > (at least not with multiple heads defined that way). With virtio_gpu we > > > will have one display channel per head, so we can use the channel id to > > > identify the scanout. > > > > It's not so clear to me, it sounds like it would be more > > efficient/synchronized to have a single scanout, especially with a gl > > context. > > 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. > > And I still don't understand the reason to have a scanout ID, if you > > have one scanout per channel. > > Ok, seems like a misunderstanding. /me figured meanwhile (but after the > very first email) that we don't need a scanout id because we can use the > channel id instead. So, full agreement here. > > > > Sure, we could create shm segments, then try using the X11 mit-shm > > > extension to display without copying again. > > > > Yeah, that already exists in client side at least, with some drawbacks > > (could be improved with proper cairo usage I believe). But anyway, I > > think this is different, and could use the existing > > 2d/surface/format/monitor messages with a small addition. > > Depends on whenever you keep the qxl rendering on the client side, then > switch to shm memory transport (instead of socket) for all surface > content, or whenever you switch to server side rendering and just have a > single shm for the whole scanout/framebuffer. > > 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. > /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. It would be worth investigating eventually. But the cpu/pixman backend is quite fast already. Good opengl skills needed to improve it. _______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/spice-devel