[Bug 743345] glupload: Add support for dmabuf

[GStreamer (GNOME Bugzilla)]

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

--- Comment #82 from Nicolas Dufresne (stormer) <nicolas.dufresne at collabora.co.uk> ---
Ok, I've rebased on git master today, to find out it didn't work. Looks like
mesa debug (or some of our doing?) have a nice little fence against GL
operation run on the wrong thread. While fixing that, I realize that we could
do a little better in term of code organization. So here's what I propose:

In _accept():
1) Only wrap the dmabufs into EGLImage

Right now we also create and bind a texture. This seems like something to be
done in the perform() step. Also this is what was run on the wrong thread,
while creating EGLImage can be done from any thread.

2) Use the GstEGLImageMemory wrapper

By wrapping the EGLImage from dmabuf, we will not be able to cache those. As my
experiment on MALI showed, there is good load of kernel and GL stack CPU that
can be saved by associating the EGLImages with the incoming DMABufMemory. In a
first experiment, I'll simply attach a quark to each DMABufMemory. Seems fair
method considering the one-to-one relation with the DMABuf. Also, as EGLImage
are not associate with a context, they can be used from multiple sink (even
though this will not happen, as tee will like prevent that).

3) Replace the quark with parent_buffer_meta

As I get to know this new meta, it is indeed an excellent fit for out needs
here.

All this will make that uploader much more similar to other uploaders. And will
be able to benifit from pools when that is implemented for _raw and
_gl_upload_meta.

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