On 19/01/2020 16:41, Philip Langdale wrote: > On Sat, 18 Jan 2020 20:27:12 +0000 > Mark Thompson <s...@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 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
