[Spice-devel] RFC: Integrating Virgil and Spice

[Gerd Hoffmann]

  Hi,

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

Did you mean "when not using virgil" ?

For the to-be-written 'drm' frontend (the qemu side for the separate gl
viewer app discussed in the other subthread) this is the way to go IMO.
When using virgil the drm frontend just hands over the drm-buf to the
viewer.  When not using virgil allocate a drm-buf + copy DisplaySurface
data to it.  The viewer only has to deal with a dma-buf which it can
hand over to wayland/x11 compositor for rendering, no matter what is
going on inside qemu.

Not sure how much sense that makes for the SDL frontend to do the same,
don't know SDL interfaces good enougth.  When SDL can deal with
drm-buf's directly this probably is the best way, otherwise maybe not.

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

DisplaySurfaces in qemu have to be linear, and I'm not sure this will
ever change.  The linear buffer assumption is in way to many places.  So
for anything you want scanout (and thus stuff into a DisplaySurface) it
is very useful to be linear.  You can use
qemu_create_displaysurface_from() then.  Otherwise it is
qemu_create_displaysurface() + copy data.

In virgil mode it doesn't matter I think.  The gpu will render stuff
into a dma-buf then, and if you mmap() the dma-buf I expect will be
linear in qemu's user address space no matter how it looks like in
physical memory.

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

virtio has feature bits (with negotiation) in the spec, no need to
reserve a mmio register for that.  I'd suggest to use a lfb
unconditionally for non-3d though.

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

/me looks forward to see patches @ qemu-devel.  It probably is useful to
start reviewing/merging virtio-vga before the 3d stuff is finished, to
sort multihead, to alert people something is coming, to get the ball
rolling for the other bits needed (such as vgabios).

cheers,
  Gerd