[Spice-devel] RFC: Integrating Virgil and Spice

[Gerd Hoffmann]

  Hi,

> The basic idea is to use qemu's console layer (include/ui/console.h)
> as an abstraction between the new virtio-vga device Dave has in mind
> (which will include optional 3D rendering capability through VIRGIL),
> and various display options, ie SDL, vnc and Spice.
> 
> The console layer would need some extensions for this:
> 
> 1) Multi head support, a question which comes up here, is do we only
> add support for multiple heads on a single card, or do we also want
> to support multiple cards each driving a head here ? I myself tend
> to go with the KISS solution for now and only support a single
> card with multiple heads.

Support for multiple cards is there.  Well, at least the groundwork.
The ui core can deal with it.  spice can deal with it.  Secondary qxl
cards used to completely bypass the qemu console subsystem.  This is no
longer the case with qemu 1.5+.

Not all UIs can deal with it in a sane way though.  With SDL and VNC the
secondary qxl card is just another console, so ctrl-alt-<nr> can be used
to switch to it.

Once I had an experimental patch to make the gtk ui open a second window
for the secondary card.  Didn't end up upstream, not in my git tree any
more, IIRC I've dropped it at one of the rebases.  Isn't hard to do
though.


That leaves the question how to do single-card multihead.  I think the
most sensible approach here is to go the spice route, i.e. have one big
framebuffer and define scanout rectangles for the virtual monitors.
This is how real hardware works, and is also provides a natural fallback
mode for UIs not supporting scanout rectangles:  They show a single
window with the whole framebuffer, simliar to old spice clients.

To get that done we effectively have to handle the monitor config
properly at qemu console level instead of having a private channel
between qxl and spice.


> 2) The ability for a video-card generating output to pass a dma-buf
> context to the display (ui in qemu terms) to get the contents from,
> rather then requiring the contents to be rendered to some memory
> buffer. This way we can save the quite expensive read-back from gpu
> memory of the rendered result and then copying that back to the
> framebuffer of the gpu for local displays (ie gtk, SDL),

Hmm?  Not sure what you are asking for...

First, reading from gpu memory isn't expensive.  It's all virtual, no
slow read cycles as with real hardware.  There is almost no difference
between gpu memory and main memory for kvm guests.  It's not clear to me
why you are copying stuff from/to gpu memory.

Second, you can have your scanout framebuffer in main memory.  That
isn't a problem at all.  It only needs to be contiguous in guest
physical memory, scatter-gather for the framebuffer isn't going to fly.

> For proper multi-head support in the ui layer for local displays,
> we will need to use SDL-2, either by porting the current SDL ui code
> to SDL-2, or by introducing a new SDL-2 ui component.

/me votes for new SDL-2 ui component, the historical grown SDL code can
use a rewrite anyway ;)

cheers,
  Gerd