[Bug 783521] gl: Add "direct" dmabuf uploader

[GStreamer (GNOME Bugzilla)]

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

Matthew Waters (ystreet00) <ystreet00 at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #353352|none                        |needs-work
             status|                            |

--- Comment #7 from Matthew Waters (ystreet00) <ystreet00 at gmail.com> ---
Review of attachment 353352:
 --> (https://bugzilla.gnome.org/review?bug=783521&attachment=353352)

Looks mostly good.

Probing is not a blocker as long as we fallback correctly.  Same with
determining if the GPU can handle the conversion.
For clearing caches, the intent of the spec and general consensus has been that
if a texture is updated externally, the texture needs to be rebound (i.e.
glBindTexture()) in order to receive the new contents.  The actual
synchronisation happens inside the driver though.

A question on this dmabuf, what happens when mapping the textures to sysmem? 
Are they YUV or RGBA? is it even possible? Are they read-only?
You can test this out with a pipeline like so:
dmabuf-producer ! glupload ! gldownload ! xvimagesink

::: gst-libs/gst/gl/gstglupload.c
@@ +482,2 @@
 #if GST_GL_HAVE_DMABUF
+

spurious newline

@@ +652,3 @@
+    }
+
+    GST_TRACE ("Got GstEGLImage %p", (gpointer) (dmabuf->eglimage));

GST_TRACE_OBJECT

@@ +680,3 @@
+  ptr = (gpointer *) dmabuf->eglimage;
+  gst_gl_memory_setup_buffer (allocator, dmabuf->outbuf, dmabuf->params, NULL,
+      &ptr, 1);

erm, I don't gst_gl_memory_setup_buffer() is required to be performed in the
OpenGL thread so this entire function can be be merged with
_direct_dma_buf_upload_perform().

@@ +951,3 @@
 };

+

spurious newline

@@ +954,3 @@
 #endif /* GST_GL_HAVE_DMABUF */

+

spurious newline

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