[Bug 760916] gl: implement GstGLMemoryEGL

[GStreamer (GNOME Bugzilla)]

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

--- Comment #9 from Nicolas Dufresne (stormer) <nicolas.dufresne at collabora.co.uk> ---
Let's me clarify how it works and you'll judge by yourself. For dmabuf, there
is a buffer that comes into glupload, it's a GstBuffer with GstDMABufMemory
inside of it. For each of the DMABuf, we will need to create a EGLImage which
wraps the dmabuf FD. This EGLImage wrapper must be reused everything this
specific FD comes back. For this reason, we want to attach (I use qdata here),
the EGLImage to the GstDMBufMemory. Later, if I receive a dmabuf that always
have an EGLImage, we'll reuse it. Because of the memory flushing taking place
when an EGLImage is created, this is extremely important.

On the src pad side of glupload, we will need to create buffer that contains
memory with GL texture that are binded to the EGLImage. We don't need to keep a
reference to the EGLImage, the specification defines the GL will take care or
referencing the EGLImage. At this point, the notion of DMABuf is completly
gone. That's why an GstGLMemoryDMABuf seems rather useless to me. We would have
two owners of the EGLImage and could require wasting an FD by doing a dup3() on
the dmabuf FD. Or, we'd have a GstGLMemoryDMABuf that does not know about
dmabufs.

The true fact is very little difference between an GstGLMemoryEGL (an EGL
backed texture) whether it was used by omx decoder on the Pi, or backed by en
EGLImage. The difference reside on who you create the EGLImage, the rest is
abstracted by the concept of EGLImage exactly so you can share the same code.
You'll notice this point has been missed a lot in glupload as we have a lot of
duplicated EGLImage code.

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