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

[Mark Thompson]

On 19/01/2020 16:41, Philip Langdale wrote:
> 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.

I'm curious what the specific case where it goes wrong actually is

> 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.

Yeah, fair enough.

- Mark