Re: [PATCH RFC 00/12] Remote Virgl support

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

_______________________________________________
Spice-devel mailing list
Spice-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/spice-devel




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]     [Monitors]