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

[GStreamer (GNOME Bugzilla)]

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

--- Comment #19 from Matthew Waters (ystreet00) <ystreet00 at gmail.com> ---
(In reply to Matt Fischer from comment #15)
> Created attachment 343748 [details] [review]
> Patch to add dmabuf export to gldownload
> 
> I still don't really know what to say about the mappable vs. non-mappable
> issue.  Detecting it during playback and renegotiating caps seems kind of
> tricky.  I'm not an expert on dmabufs, so I really don't know how to predict
> whether in practice these exported images would always be mappable, or not. 
> So it's hard to know whether we're safe doing this all the time, or whether
> that will cause problems in some circumstances.

I think the general idea is that dma-buf's from the graphics driver are just
not mappable (unless you're using dumb buffers, which can't be allocated from
OpenGL).

(In reply to Matt Fischer from comment #17)
> Created attachment 343926 [details] [review]
> Patch to add dmabuf export to gldownload
> 
> One answer would be to negotiate the memory:DMABuf feature, and only attempt
> the export when that feature was negotiated.  For that to work, the VAAPI
> plugins would need to add memory:DMABuf as a possible input caps feature.  I
> don't know enough about the history of memory:DMABuf to know whether or not
> that will be an option.  Some of the discussion in
> https://bugzilla.gnome.org/show_bug.cgi?id=755072 made it seem like
> something that can't be used here.  Can you provide some context?

Why can't memory:DMABuf be used?  IIRC, memory:DMABuf is for this exact case
where the dmabuf is not mappable.

> Another possible option would be to invent a new meta that we could attach
> to the buffer.  So the main buffer would remain as it is, but dmabuf-aware
> elements could grab the meta and use it to perform the export.  This would
> require adding new code into vaapipluginbase to make use of it, though, and
> would add more complication to what seems to already be a very complicated
> issue, so maybe it's not a good option.

This is ugly :(

> Do you have any suggestions on how I might proceed with this patch?  Thanks
> for all of your help so far.

I think making the assumption (for now) that the DMABuf is not mappable and
therefore requiring the memory:DMABuf caps feature for gldownload to push
dmabuf's is the way forward.

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