[FFmpeg-devel] [PATCH] Vulkan hwcontext and filters

[Philip Langdale]

On Sat, 18 Jan 2020 20:27:12 +0000
Mark Thompson <sw at jkqxz.net> wrote:

> On 10/01/2020 21:05, Lynne wrote:
> > This is modelled as a transfer, as we have today, but where both
> > the src and the dst are hardware frames with hw contexts. We need
> > to be careful to ensure the contexts are compatible - particularly,
> > we cannot do transfers where one of the frames has been mapped via
> > a derived frames context - we can only do transfers for frames that
> > were directly allocated by the specified context.  
> 
> Why?  A derived frames context should be mostly treatable as a normal
> frames context in the mapped-to device, so I'm not seeing where this
> restriction is coming from.
> 
> (Is there some particular case which doesn't work that this helps to
> avoid?)

My experience was that when dealing with a mapped frame, it would chain
back to the original context to handle transfers, which let to broken
functionality in my testing. But also keep in mind that, in practice,
we don't have scenarios today where this is even interesting. In the
case of Intel/AMD and vaapi+vulkan, we can use mapping all the way
through, while on nvidia and cuda+vulkan, we use copies all the way
through.

If we actually come across a scenario where mixed mapping and copying
is useful, we can try and reason about it and see what needs to change.

--phil