On Mon, 4 Sep 2017 18:03:51 +0100 Rostislav Pehlivanov <atomnu...@gmail.com> wrote:
> On 4 September 2017 at 17:25, Timo Rothenpieler <t...@rothenpieler.org> > wrote: > > > We have av_pixelutils_sad_fn which does SAD and has SIMD, there's no point > >> in reinventing the wheel. > >> > >> I also don't see why this needs to be implemented with CUDA. You're not > >> even doing the SAD in CUDA. I bet it'll be just as fast if not faster in C > >> (unless you cheat somehow). > >> > > > > The point is to do it on CUDA frames without copying them to system ram > > first. > > > > > > _______________________________________________ > > ffmpeg-devel mailing list > > ffmpeg-devel@ffmpeg.org > > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > > > > I think they should provide a Vulkan interop so we could drop all CUDA > filters and instead treat all filter GPU acceleration in a generic way. Its > just a matter of months before one exists, I bet. You could say the same about OpenCL. Too bad NVIDIA keep pushing their dumb vendor specific APIs. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
