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

[Philip Langdale]

On Sun, 17 Feb 2019 06:24:05 +0000
Soft Works <softworkz at hotmail.com> wrote:

> Hi,
> 
> 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