[Bug 743345] glimagesink: Add support for dmabuf

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=743345
  GStreamer | gst-plugins-bad | unspecified

Daniel Stone <daniel> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |daniel at fooishbar.org

--- Comment #1 from Daniel Stone <daniel at fooishbar.org> 2015-01-22 13:18:02 UTC ---
(In reply to comment #0)
> == Platform Support ==
> [...]
> 
> An EGL context is a requirement for the extension, but
> EGL_EXT_image_dma_buf_import is not necessarily an OpenGL ES only feature.
> But currently the Intel i965 driver does not implement it for Desktop GL.
> http://cgit.freedesktop.org/mesa/mesa/tree/src/mesa/drivers/dri/i965/intel_tex_image.c#n387
> 
> To achieve the dma_buf_import on ES, a GL_OES_EGL_image_external texture target
> is needed.

This can also work with targets such as TEXTURE_2D (it does on Mali for RGB
formats), but this is not implemented by Intel at all. In general, Intel's
support for this extension is quite immature, but it's not a huge amount of
work to fix.

> == Patch 3 [details] # glimagesink: implement dmabuf display
> 
> This patch was originally authored by George Kiagiadakis.
> The glsink needs to use the different texture target for displaying the dmabuf.
> The target needs also to be specified in the shader. To recognize a dmabuf,
> gst_is_dmabuf_memory is used.

Again, this can also use texture2D() if applicable. There are multiple
scenarios:
  - RGB imported buffer is accessed as a single buffer with texture2D()
  - planar YUV buffers are accessed as multiple buffers with texture2D() and
colourspace conversion done with shaders (supported by Weston)
  - planar YUV buffers are accessed as single buffer with textureExternalOES()
and colourspace conversion done internally for client to sample as RGB (also
supported by Weston)

In general, there is no way for users to detect which method should be used.
The eglQueryWaylandBufferWL() interface provides this capability for native
Wayland buffers; dmabuf would require something equivalent, or trial and error.

> == Patch 4 [details] # dmabuf: add drm format support without conversion
> To avoid inclusion of this header I am currently redefining these in a switch
> to convert from GStreamer to drm format.
> The "known working formats" problem could be solved by testing all drm formats
> and checking for EGL errors.

The problem is that the EGL implementation can also reject buffers for any
other constraints, such as alignment of buffer pitch, so it is very difficult
to come up with a generic test to see if formats are supported. There has been
a proposal to include an EGL query API to list the supported formats, but this
has not yet been moved through Khronos.

> == Patch 7 [details] # WIP: glconvert: enable conversion for dmabuf
> This shows how glconvert would needed to be modified to support conversion for
> formats drm does not support.
> All the shaders would require to be modified. In multiplane cases, more than
> the sampler type would needed to be changed.
> 
> After a new texture is created during conversion, the sink needs to display a
> GL_TEXTURE_2D target.
> The question is if this should be done at all, and how this could be solved in
> a proper way.

It would be nice if this was a capability from glsink, e.g. if it could be
negotiated that TEXTURE_EXTERNAL_OES was accepted instead of TEXTURE_2D to
potentially avoid format-converting blits.

> == Multiplane format support ==
> 
> I was not able yet to run multiplane support, since the Intel driver does not
> support it.
> 
> Following EGL error is reported when using I420:
> libEGL debug: EGL user error 0x3004 (EGL_BAD_ATTRIBUTE) in too many plane
> attributes
> 
> I hopefully will be able to test this on the Mali driver.

Making the Intel driver also support this is relatively trivial.

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.