[FFmpeg-devel] [Patch] CUDA Thumbnail Filter

[Rostislav Pehlivanov]

On 4 September 2017 at 18:18, wm4 <nfxjfg at googlemail.com> wrote:

> On Mon, 4 Sep 2017 18:03:51 +0100
> Rostislav Pehlivanov <atomnuker at gmail.com> wrote:
>
> > On 4 September 2017 at 17:25, Timo Rothenpieler <timo at 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 at 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 at 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.