On 4 September 2017 at 19:44, wm4 <nfx...@googlemail.com> wrote: > On Mon, 4 Sep 2017 19:07:02 +0100 > Rostislav Pehlivanov <atomnu...@gmail.com> wrote: > > > 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. > > That doesn't matter for this filter. I'm fairly sure OpenCL got interop > too, although I've never tried it. > > > 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. > > Unlike Vulkan, OpenCL is rather stable and widely supported. Vulkan was > apparently made for games (including stability requirements), and > supported only with newer HW. In fact, OpenCL is literally the portable > equivalent to Cuda. So it would be the logical choice. > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel >
Vulkan was definitely not made for games only, it was made to be general purpose. As far as I know some vendors are replacing their OpenCL implementations by a Vulkan shim. Some vendors also have had a history of deliberately handicapping alternative compute APIs so their native ones perform better. Vulkan eliminates all that. Also using Vulkan elminates the need for an OpenCL/Vulkan interop for users using Vulkan. There's no other logical choice but Vulkan. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
