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

[Gerd Hoffmann]

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.

> 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.

/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 ...

cheers,
  Gerd