On Tue, 09 Mar 2021 22:53:18 +0100 Lynne <d...@lynne.ee> wrote: > Sorry, as we discussed on IRC the Vulkan hwcontext should be > improved first and this filter should be kept as a pure hardware > filter.
I changed my mind on this because: - I think it's reasonably self-contained as is, and actually simpler to implement this way. - There's no duplication of code within this patch. - Sharing the VkImages directly is simply not a good approach. It creates an unnecessary API hassle (as demonstrated by the multitude of solved and unsolved issues surrounding device negotiation, synchronization, etc.) - Therefore, it's better to share using an agreed-upon mechanism like a shared memory object exported/imported using the Vulkan API. - A good API for this already exists (dmabufs). - You can already derive a drm device from a vulkan device and export vulkan hwframes as drmprime frames. I plan on adding support for drmprime frames to this filter, which I think is the cleaner way to avoid the upload/download. But I wanted to get feedback on the current version, since it's *functionally* complete as-is. If you're worried about dmabufs being a Linux-only API, I would still rather see an approach based on Vulkan memory object imports/exports rather than attempting to share and synchronize the VkImages directly. Even just the fact that we can't each enable extensions/features we want enabled independently is a reason that trying to share a single vulkan device is a bad idea. Right now the result of that is that vf_libplacebo atop hwcontext_vulkan would simply be missing out on features and performance, compared to this version. _______________________________________________ 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".
