[Spice-devel] [PATCH v2 spice-protocol 2/2] Add unix GL scanout messages

[Marc-André Lureau]

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.