[FFmpeg-devel] [Patch] CUDA Thumbnail Filter

[Rostislav Pehlivanov]

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

> On Mon, 4 Sep 2017 19:07:02 +0100
> Rostislav Pehlivanov <atomnuker at gmail.com> wrote:
>
> > 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.
>
> 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 at 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.