[Bug 743345] glupload: Add support for dmabuf

[GStreamer (GNOME Bugzilla)]

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

--- Comment #53 from Matthew Waters <ystreet00 at gmail.com> ---
(In reply to Lubosz Sarnecki from comment #45)
> == video_frame_map() with dmabufs ==
> 
> video_frame_map() seems to not be needed in pipelines with dmabuf:
> https://git.collabora.com/cgit/user/lubosz/gst-plugins-bad.git/commit/
> ?h=dmabuf-dev&id=f7d7d2b55b84d1eadb0463981c9a815b8e2d3b05

It's also not technically needed for regular 2D textures except for the
GLMemory state machinery to know where the most recent texture data is to
upload/download as necessary.  Don't add a conditional path just because "it is
not needed".  Mapping when the texture data is already in the correct place is
a no-op.  You may need to map(WRITE | GL) when creating the texture to ensure
that the GLMemory state machinery knows where the latest data is.

> Since I am using GL_TEXUTRE_2D in above patches, there needs to be an
> additional way to distinguish between dmabuf and non-dmabuf textures in the
> sink, besides the texture target.

Why?

> _gl_mem_copy() can also be skipped for dmabuf gl buffers with GL_TEXTURE_2D,
> which is mandatory with GL_TEXTURE_EXTERNAL_OES, as seen in:
> http://cgit.freedesktop.org/gstreamer/gst-plugins-bad/diff/gst-libs/gst/gl/
> gstglmemory.c?id=e61d504556870adf2b5d58b86b09a3327816dec2

What bad thing happens if dmabuf textures are copied?  If nothing, why are you
proposing to skip copying dmabuf textures?

> == Usage of GL_TEXTURE_EXTERNAL_OES ==
> I was not able to negotiate the EXTERNAL_OES target with glconvert this way.
> Any ideas how to make this work properly?

Depends on exactly what doesn't work.  Caps negotiation? GL errors? etc

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