On Sun, 17 Feb 2019 06:24:05 +0000 Soft Works <softwo...@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 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel