[FFmpeg-devel] FW: Requirements for compiling with CUDA_SDK option enabled

[Soft Works]

> > in the above context I'm wondering about whether it is mandatory to
> > treat the "cuda_sdk" option as a non-free option?
> >
> > In case of libnpp it's obviously required to statically link to
> > proprietary Nvidia code code for which there's not public source code
> > available.
> >
> > But for yadif_cuda and scale_cuda it's just about dynamic linking to
> > a system component (driver), which seems to be allowed by the GPL or
> > GPLv3 at least.
> >
> > Are my assumptions correct?
> >
> > If yes, could we move 'cuda_sdk' from the
> > HWACCEL_LIBRARY_NONFREE_LIST to the HWACCEL_LIBRARY_LIST in order to
> > allow using the cuda filters even with GPL builds?
>
> Unfortunately, it is not possible, and I say this as someone who has
> spent some time investigating how to remove the SDK dependency from the
> filters. While it is possible to adjust the CPU-side filter code to use
> the nv-codec-headers, the cuda kernels cannot be built without
> statically linking them against a library that ships with the SDK,
> under the GPL-incompatible SDK licence.
>
> To completely remove the dependency, you'd need to rewrite the kernels,
> and I'm not even sure that works in practice. The clang nvptx compiler
> works for a subset of the cuda API but even that seems to require the
> same SDK library to actually link and fully resolve all symbols. I
> imagine one could write a kernel using only core primitives, but that
> would require implementing your own versions of a bunch of the higher
> level code used by the kernels we have today. (eg: You couldn't use
> texture or surface references, and would need to pass raw memory and do
> all your own bounds checking, etc)
>
> --phil

Hi Phil,

thanks for replying. I was just about to start migrating the filters to
dynamic loading (nv-codec-headers)..

>From your explanations, the situation doesn't seem to be as bad as it
could be. When the CPU code of the filters can be changed to dynamic
linking, then there's just the CUDA kernel code left to deal with.

The GPL may forbid to include and distribute it inside or as part of
ffmpeg. But it cannot forbid ffmpeg to copy some external binary code
at runtime from the filesystem to the GPU and execute it there (different
process, different harware). That would be similar like a non-GPL
application being allowed to bundle ffmpeg.exe (GPL-compiled).

At least from my understanding it would be perfectly legal to exclude
the CUDA kernel code from ffmpeg and add an option to the filters
for specifying a file containing the compiled CUDA kernel to be loaded
at runtime (via cuModuleLoadData).

What do you think?

--softworkz