[Bug 776927] vaapi: plugins: accept GLMemory buffers from upstream

[GStreamer (GNOME Bugzilla)]

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

--- Comment #12 from Matthew Waters (ystreet00) <ystreet00 at gmail.com> ---
(In reply to Matt Fischer from comment #11)
> Created attachment 343387 [details] [review]
> Patch to add dmabuf export to gldownload
> 
> Here's a very hacked-together patch that implements the gldownload strategy.
> It still needs a bunch of work before it would be ready to go in, but it
> seems to work correctly, at least on my system.
> 
> Questions about this patch:
>   1.  The way this is set up, it will export the dmabuf every frame.  That's
> too much work, we should be able to just export the buffer once and then
> hang on to the exported dmabuf fd.  What's the best way to set that up?

That would probably be best performed by a buffer pool somewhere.

>   2.  Right now it performs this export whenever it can.  Would there be
> situations where we wouldn't want a dmabuf export?  It seems like as long as
> the resulting buffer is mappable, the downstream plugins can still get at it
> in software if they want to, so things would still work the way they expect.
> But I'm not too familiar with the intricacies of dmabufs, so I don't know if
> there would be other reasons that we might not want to do a dmabuf export in
> some cases.

I'm not sure either however it is certainly possible for dmabuf's to be
unmappable by software elements which is where the caps feature is useful in
order to explicitly request (or not) a certain feature.

An option is to push a completely new memory type from gldownload so that symem
mapping will always work (as far as is permitted by GL and dmabuf).

Another completely different option is for vaapi to propose a glbufferpool that
already deals with creating the egl images attached to textures. (probably not)

The other option is for vaapi to do the transformation to eglimages itself
although that's less exciting. (probably not)

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