[Spice-devel] [PATCH RFC 00/12] Remote Virgl support

Gerd Hoffmann kraxel at redhat.com
Mon Jul 18 08:56:49 UTC 2016


On Fr, 2016-07-15 at 14:49 +0100, Frediano Ziglio wrote:
> This patch is an improve to last one. There are still many work
> to be done. The main reason I'm posting is to discuss the Qemu
> API changes ("Define a new interface for Qemu to pass texture"
> patch). This code add dependency to EGL directly.

I'm not convinced it is a good idea to pass around texture ids instead
of dma bufs, especially as we'll also receive dma-bufs in the future
(intel-vgpu will export the guest display as dma-buf).

> The main idea is still extracting raw data and passing to the
> normal flow (display_channel_process_draw).

What is the state of the hardware supported encoding?
How can we pass buffers to the hardware encoder?

> Changes from last version:
> - this set supports all cards using a different protocol from Qemu
>   that now can pass EGL information (display and context) and
>   texture directly. This allows spice-server to choose dma buffers
>   or just GL data;

I think we should decouple the scanout buffer passing and the egl
context handling.

qemu already has functions for context management in ui/console.h:

  QEMUGLContext dpy_gl_ctx_create(QemuConsole *con,
                                  QEMUGLParams *params);
  void dpy_gl_ctx_destroy(QemuConsole *con, QEMUGLContext ctx);
  int dpy_gl_ctx_make_current(QemuConsole *con, QEMUGLContext ctx);
  QEMUGLContext dpy_gl_ctx_get_current(QemuConsole *con);

We should use them to create a EGL context for spice-server.  I can
think of two ways to do this:

 (1) Extend the display channel interface to have callbacks for these
     (and thin wrapper functions which map spice display channel to
     QemuConsole so spice-server doesn't need to worry about that).

 (2) Have qemu create one context per spice-server (or per display
     channel) and create a new spice_server_set_egl_context() function
     to hand over the context to spice-server.

(2) is simpler, (1) is more flexible.  Not sure we actually need the
flexibility though.

cheers,
  Gerd



More information about the Spice-devel mailing list