[FFmpeg-devel] [Patch] CUDA Thumbnail Filter

[wm4]

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.