On 4 September 2017 at 18:18, wm4 <nfx...@googlemail.com> wrote: > 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 >
OpenCL does no presenting, so interops there would remove CUDA's point. However, Vulkan is general purpose so interops must exist in order to avoid copying when presenting. OpenGL got a CUDA interop for this very reason. Hence, since a Vulkan interop will soon exist, I object to this patch. I see no reason to add more vendor exlcusive code when a generic solution will appear and we could use that. Unlelss someone manages to convince me otherwise. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
