[Bug 760916] gl: implement GstGLMemoryEGL

[GStreamer (GNOME Bugzilla)]

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

--- Comment #11 from Nicolas Dufresne (stormer) <nicolas.dufresne at collabora.co.uk> ---
(In reply to Matthew Waters (ystreet00) from comment #10)
> Just double checking, but for dmabuf, the lifetime requirements are as
> follows:
> 
> dmabuf -> EGLimage: requires the dmabuf to keep the EGLImage alive.
> EGLImage -> GL texture: can discard the EGLImage (for 2D textures). For
> external-oes textures from an EGLImage, I believe there are extra
> synchronisation requirements that require us to keep a reference to the
> EGLImage so that it doesn't get reused too early.

Seems right, except that there is no external eos texture in those two use
cases (but that may exist on Android). For the dmabuf case, we use
GstParentBufferMeta with the buffer containing dmabuf to solve this one (the
EGLImage is just a wrapper really, what you do with it is not so important, as
long as you manage to reuse the same EGLImage for the same FD for performance
reason). For the OMX case, nothing to be done I believe, in this new version,
glupload will passthrough like it did a long time ago.

If you transform something with an asynchronous PBO though, you should
figure-out a way to keep a reference on the original, regardless if it's
another texture or an EGLImage binded texture (if it's not already the case I
mean).

> 
> Is the only problem that gsteglimagememory/gstglmemoryegl does not have a
> way to wrap existing EGLImage's?  If so, that's easy to add.  As you say it
> may need to be a refcounted EGLImage reference but still, dead simple to add.

Indeed.

> 
> For GstGLMemoryEGL, it would need to optionally take a EGLImage to create
> the GL texture from and then discard it (or not) if that's allowed/not
> required anymore.  That is entirely possible now with the
> GstGLVideoAllocationParams and you have a GL texture bufferpool for free! 
> The exact semantics would have to be defined for GstGLMemoryEGL but it is
> entirely possible.
> 
> If it ever makes sense to combine all three handles (dmabuf, EGLImage, GL
> texture) then a GstGLMemoryDMABUF would make sense (but I don't believe it
> does currently).

Nod.

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