[FFmpeg-devel] [Patch] CUDA Thumbnail Filter

[wm4]

On Mon, 4 Sep 2017 20:41:19 +0100
Rostislav Pehlivanov <atomnuker at gmail.com> wrote:

> 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.

It certainly feels like it. So much around it is geared towards game
dev.

> As far as I know some vendors are replacing their OpenCL
> implementations by a Vulkan shim.

They probably could implement a Vulkan OpenCL backend, but even then
they'll provide a shader compiler as part of the OpenCL API, which is
superior to Vulkan again.

> Some vendors also have had a history of
> deliberately handicapping alternative compute APIs so their native ones
> perform better. Vulkan eliminates all that.

Then suggest better hardware with vendors which don't do that nonsense.

It remains to be seen whether Vulkan is really suitable for anything
but things centered around rasterization. The lack of a standard shader
compiler is definitely an issue. (Are you going to depend on vendor
extensions? On some shitty 3rd party compilers, like the half-broken
glslang? Or check in shader binaries into git?)

> Also using Vulkan elminates the
> need for an OpenCL/Vulkan interop for users using Vulkan. There's no other
> logical choice but Vulkan.

Using OpenCL wouldn't even require any interop with that much.