Re: [Qemu-devel] [PATCH] Add QEMU DirectFB display driver

[Stefano Stabellini]

On Tue, 18 May 2010, Gerd Hoffmann wrote:
> On 05/18/10 11:29, Stefano Stabellini wrote:
> > On Tue, 18 May 2010, Gerd Hoffmann wrote:
> >> On 05/18/10 11:12, Stefano Stabellini wrote:
> >>> I think it would be better to implement an accelerated frontend for
> >>> rendering the framebuffer, like opengl or xv.
> >>
> >> Well.  xv is pretty pointless IMHO.  gl makes sense.  But to have some
> >> effect this needs some major restructions in qemu, the current
> >> DisplayState infrastructure can't handle anything but a simple, stupid
> >> framebuffer.  There isn't much to accelerate, except maybe scaling the
> >> guest display to fullscreen on the host.
> >>
> >> qxl + spice will change that though.  qxl is a paravirtualized gfx
> >> adapter.   Guest sends rendering commands.  The spice protocol sends the
> >> rendering commands over the wire to the spice client, which in turn will
> >> render them (and can use gl to accelerate that).
> >
> > Is the spice client going to live in qemu, or is it going to be
> > separate?
> 
> Separate.
> 
> project website: http://www.spice-space.org/
> spice bits: http://cgit.freedesktop.org/~kraxel/spice/log/?h=api.v6
> qemu patches: http://cgit.freedesktop.org/spice/qemu/log/?h=spice.v6.0

Then I guess we don't actually need any accelerated rendering in qemu,
even though it might still be nice for avoiding a memcpy.

I am curious about one thing: if the spice client is running on the same
host as the VM and qemu, is there any plan for sharing memory somehow
between the two components? OR is it not believed to be necessary to
reach good performances?