[Spice-devel] [PATCH spice-protocol] Add unix GL scanout messages

Marc-André Lureau mlureau at redhat.com
Mon Dec 21 08:48:18 PST 2015


Hi

----- Original Message -----
> > 
> > Add 2 new messages to the display channel to stream pre-rendered GL
> > images of the display. This is only possible when the client supports
> > SPICE_DISPLAY_CAP_GL_SCANOUT capability.
> > 
> > The first message, SPICE_MSG_DISPLAY_GL_SCANOUT_UNIX, sends a gl image
> > file handle via socket ancillary data, and can be imported in a GL
> > context with the help of eglCreateImageKHR() (as with the 2d canvas, the
> > SPICE_MSG_DISPLAY_MONITORS_CONFIG will give the monitors
> > coordinates (x/y/w/h) within the image). There can be only one scanount
> > per display channel.
> > 
> > A SPICE_MSG_DISPLAY_GL_DRAW message is sent with the coordinate of the
> > region within the scanount to (re)draw on the client display. For each
> > draw, once the client is done with the rendering, it must acknowldge it
> > by sending a SPICE_MSGC_DISPLAY_GL_DRAW_DONE message, in order to
> > release the context (it is expected to improve this in the future with a
> > cross-process GL fence).
> > 
> > The relation with the existing display channel messages is that all
> > other messages are unchanged: the last drawing command received must be
> > displayed. However the scanout display is all or nothing. Consequently,
> > if a 2d canvas draw is received, the display must be switched to the
> > drawn canvas. In other words, if the last message received is a GL draw
> > the display should switch to the GL display, if it's a 2d draw message
> > the display should be switched to the client 2d canvas.
> > 
> > (there will probably be a stipped-down "gl-only" channel in the future,
> > or support for other streaming methods, but this protocol change should
> > be enough for basic virgl or other gpu-accelerated support)
> > 
> > Signed-off-by: Marc-André Lureau <marcandre.lureau at redhat.com>
> > ---
> > v2->v3:
> >  - change flags8 for flags32 (Frediano Ziglio)
> > 
> > spice.proto      | 25 ++++++++++++++++++++++++-
> >  spice/enums.h    |  9 +++++++++
> >  spice/protocol.h |  1 +
> >  3 files changed, 34 insertions(+), 1 deletion(-)
> > 
> > diff --git a/spice.proto b/spice.proto
> > index 3bca900..172d6e3 100644
> > --- a/spice.proto
> > +++ b/spice.proto
> > @@ -678,6 +678,10 @@ struct Head {
> >      uint32 flags;
> >  };
> >  
> > +flags32 gl_scanout_flags {
> > +    Y0TOP
> > +};
> > +
> >  channel DisplayChannel : BaseChannel {
> >   server:
> >      message {
> > @@ -915,7 +919,23 @@ channel DisplayChannel : BaseChannel {
> >          uint32 timeout_ms;
> >      } stream_activate_report;
> >  
> > - client:
> > +    message {
> > +        unix_fd fd;
> > +        uint32 width;
> > +        uint32 height;
> > +        uint32 stride;
> > +        uint32 format; /* drm fourcc */
> > +        gl_scanout_flags flags;
> > +    } gl_scanout_unix;
> > +
> 
> I think names like drm_dma_buf_fd and drm_fourcc_format are much clearer
> (other fields are fine).
> 
> I would like to see something like
> 
>    message {
>        /* dma buffer exported by the Linux DRM layer */
>        unix_fd drm_dma_buf_fd;
>        uint32 width;
>        uint32 height;
>        uint32 stride;
>        /* specifies the format of drm_dma_buf_fd defined in drm_fourcc.h */
>        uint32 drm_fourcc_format;
>        gl_scanout_flags flags;
>    } gl_scanout_unix;

Oops, I forgot that from the v2 thread. Fixed.

> 
> > +    message {
> > +        uint32 x;
> > +        uint32 y;
> > +        uint32 w;
> > +        uint32 h;
> > +    } gl_draw;
> > +
> 
> Why not "Rect box;" ?

As I explained in v2, Rect is quite weird (bottom/top/left/right) and misleading (negative values etc).

> > +client:
> >      message {
> >  	uint8 pixmap_cache_id;
> >  	int64 pixmap_cache_size; //in pixels
> > @@ -937,6 +957,9 @@ channel DisplayChannel : BaseChannel {
> >      message {
> >          image_compression image_compression;
> >      } preferred_compression;
> > +
> > +    message {
> > +    } gl_draw_done;
> >  };
> >  
> >  flags16 keyboard_modifier_flags {
> > diff --git a/spice/enums.h b/spice/enums.h
> > index 16885ac..613db52 100644
> > --- a/spice/enums.h
> > +++ b/spice/enums.h
> > @@ -303,6 +303,12 @@ typedef enum SpiceResourceType {
> >      SPICE_RESOURCE_TYPE_ENUM_END
> >  } SpiceResourceType;
> >  
> > +typedef enum SpiceGlScanoutFlags {
> > +    SPICE_GL_SCANOUT_FLAGS_Y0TOP = (1 << 0),
> > +
> > +    SPICE_GL_SCANOUT_FLAGS_MASK = 0x1
> > +} SpiceGlScanoutFlags;
> > +
> >  typedef enum SpiceKeyboardModifierFlags {
> >      SPICE_KEYBOARD_MODIFIER_FLAGS_SCROLL_LOCK = (1 << 0),
> >      SPICE_KEYBOARD_MODIFIER_FLAGS_NUM_LOCK = (1 << 1),
> > @@ -503,6 +509,8 @@ enum {
> >      SPICE_MSG_DISPLAY_MONITORS_CONFIG,
> >      SPICE_MSG_DISPLAY_DRAW_COMPOSITE,
> >      SPICE_MSG_DISPLAY_STREAM_ACTIVATE_REPORT,
> > +    SPICE_MSG_DISPLAY_GL_SCANOUT_UNIX,
> 
> Sometimes I think SPICE_MSG_DISPLAY_GL_SCANOUT_LINUX would be
> better in this case. dma_buf is really specific.
> But I can live with _UNIX too.

or DMA_BUF? I think I thought _UNIX postfix could help to identify messages that are only valid of unix socket.

> 
> > +    SPICE_MSG_DISPLAY_GL_DRAW,
> >  
> >      SPICE_MSG_END_DISPLAY
> >  };
> > @@ -511,6 +519,7 @@ enum {
> >      SPICE_MSGC_DISPLAY_INIT = 101,
> >      SPICE_MSGC_DISPLAY_STREAM_REPORT,
> >      SPICE_MSGC_DISPLAY_PREFERRED_COMPRESSION,
> > +    SPICE_MSGC_DISPLAY_GL_DRAW_DONE,
> >  
> >      SPICE_MSGC_END_DISPLAY
> >  };
> > diff --git a/spice/protocol.h b/spice/protocol.h
> > index 0c265ee..3e6c624 100644
> > --- a/spice/protocol.h
> > +++ b/spice/protocol.h
> > @@ -136,6 +136,7 @@ enum {
> >      SPICE_DISPLAY_CAP_STREAM_REPORT,
> >      SPICE_DISPLAY_CAP_LZ4_COMPRESSION,
> >      SPICE_DISPLAY_CAP_PREF_COMPRESSION,
> > +    SPICE_DISPLAY_CAP_GL_SCANOUT,
> >  };
> >  
> >  enum {
> > --
> > 2.5.0
> 
> Frediano
> _______________________________________________
> Spice-devel mailing list
> Spice-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel
> 


More information about the Spice-devel mailing list