[Spice-devel] RFC: Integrating Virgil and Spice

[David Airlie]

----- Original Message -----
> From: "Gerd Hoffmann" <kraxel at redhat.com>
> To: "Dave Airlie" <airlied at gmail.com>
> Cc: "Hans de Goede" <hdegoede at redhat.com>, "spice-devel" <spice-devel at lists.freedesktop.org>, "Dave Airlie"
> <airlied at redhat.com>
> Sent: Wednesday, 9 October, 2013 6:44:58 PM
> Subject: Re: [Spice-devel] RFC: Integrating Virgil and Spice
> 
> On Mi, 2013-10-09 at 08:46 +1000, Dave Airlie wrote:
> > > 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.
> > 
> > No real hw doesn't work like that, that is how we program real hw at the
> > moment,
> > but for example wayland won't do this, and neither does Windows mostly,
> > 
> > real hw can have multiple separate framebuffers with separate strides,
> > and separate
> > scanouts from them, and the kms device drivers fully support this mode
> > of operation,
> > just the X server prevents it from being useable.
> 
> Ok.  So scratch that idea.  It's probably better to have the gfx card
> register multiple QemuConsoles then (one for each virtual connector),
> with some infrastructure bits in the ui core + frontends to allow
> enabling/disabling them.

Yes that seems likely,

> When the guests virtual gfx card doesn't let the gpu render into a
> dma-buf we have to copy the bits anyway.  Ideally just memcpy from guest
> framebuffer to a dma-buf (not sure drm allows that), so we can hand out
> a dma-buf handle for rendering no matter whenever the guest uses virgil
> or cirrus.

Oh I suppose we could do that, though it could be a bit messy as the dma-buf
stuff is pretty bound up in having a gpu device to attach through, which
you won't have when using virgil.

> 
> > > 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.
> > 
> > Scatter-gather for the framebuffer is fine as long as
> > its not VESA LFB. I already have virtio-vga device allocating a
> > non-contig framebuffer
> > and just using DMA operations to move data in/out.
> 
> Sure it's possible.  All qemu UIs want a linear framebuffer they can
> operate on though.  So with scatter-gather you have to copy the data
> into a linear buffer in qemu memory.  Without scatter-gather you can
> pass a reference to guest memory to the UIs and avoid the extra copy.


The thing is for GL rendered UI there is no requirement for linear framebuffer
and actually SDL has no real requirement either, SDL2.0 pretty much says
you need to upload things to the final buffer anyways. But I expect we can
make virtio-vga have a feature for a linear framebuffer addition in the mmio
space if we have pci or mmio support.

> 
> What is virtio-vga btw?  The virgil virtual vga device or something
> else?

Its my attempt to write a clean device from scratch, the current virgil
codebase is a pile of hacks to qemu just so I could get to the 3D rendering
as soon as possible, so I've started a virtio-gpu device which does 
proper virtio->pci->vga layering and I'm going to try and create a multi-head
gpu that has no acceleration then add the 3D accel as a feature with an
additional vq.

Though virtio-vga is a bit behind where I'd like it to be, I just managed
to fix SDL2.0 input today so I could at least type into my VMs again.

Dave.