[Bug 711155] wayland: add wl_drm support to wayland sink

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=711155

--- Comment #23 from Daniel Stone <daniel at fooishbar.org> ---
(In reply to Sebastian Dröge (slomo) from comment #22)
> (In reply to Nicolas Dufresne (stormer) from comment #19)
> > (In reply to Sebastian Dröge (slomo) from comment #16)
> > > Shouldn't waylandeglsink be the same as glimagesink (with libgstgl compiled
> > > with Wayland support and using Wayland/EGL at runtime)? Why yet another sink?
> > 
> > The glimagesink method is slightly less efficient, because we will do a
> > convertion to another texture, and then render to our GL context, which will
> > internally submit to the compositor.
> 
> Why don't we optimize this for this specific case on Wayland then?

Depends. Mesa does support the EGL_WL_create_wayland_buffer_from_image
extension, but this is not widely supported on other implementations. Any
implementation supporting this could skip the blit through GL (i.e. calling
glDrawArrays sourcing from the provided/imported EGLImage, and rendering to a
Wayland-backed EGLSurface) in the case where it could do a native import to
EGLImage, i.e. dmabuf.

I don't know how useful it is to optimise for this case though: if you have a
dmabuf, you can skip a lot of effort by just passing it directly through
Wayland's dmabuf protocol. Are there many cases where we get an EGLImage but it
doesn't come from dmabuf? I guess OpenMAX, but I've yet to see systems in the
wild which support both OMX and Wayland.

Also, as a quick aside - the reason most compositors don't advertise support
for YUV formats on SHM is two-fold. Firstly (but very easily fixed) is that we
lack a multi-planar SHM buffer creation protocol. Secondly, OpenGL ES 2.x lacks
native support for one- and two-component texture formats, which we'd need to
efficiently convert in the compositor. For that, you need ES3, or
GL_EXT_texture_rg.

Another quick aside - if you have data in shared memory, we'd massively prefer
for that to go through EGL, as it places the TexImage2D overhead in the client
(easy to account for when profiling/etc, lets others run in the meantime) to
the compositor (blocks the entire session).

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.