On 21.02.2019 04:57, Philip Langdale wrote:
The use of nvcc to compile cuda kernels is distinct from the use of cuda sdk libraries and linking against those libraries. We have previously not bothered to distinguish these two cases because all the filters that used cuda kernels also used the sdk. In the following changes, I'm going to remove the sdk dependency from those filters, but we need a way to ensure that nvcc is present and functioning, and also a way to explicitly disable its use so that the filters are not built.Note that, unlike the cuda_sdk dependency, using nvcc to compile a kernel does not cause a build to become non-free. Although nvcc is distributed with the cuda sdk, and is EULA encumbered, the compilation process we use does not introduce any EULA covered code or libraries into the build. In this sense, using nvcc is just like using any other proprietary compiler like msvc - compiling free code doesn't suddently make it non-free. There was previously some confusion on this topic, but the important distinction is that we use nvcc to generate ptx files - these are not compiled GPU binaries, but rather an intermediate assembly representation that is JIT compiled (and I think linked with certain nvidia library code) when you actually try and run the kernel. nvidia use this technique to relax machine code compatibility between hardware generations. From here, we can make two observations: * The ptx files that we include in libavfilter are aggregated rather than linked, from the perspective of the (L)GPL * No proprietary code is included with the ptx files. That code is only linked in at the final compilation step at runtime.
From a technical standpoint, this whole series looks fine to me.However, it really does not fell non-nonfree to me that the only way to build these filters remains to register with nvidia, accept their various EULAs and download their SDK for nvcc and the libs around it.
Even moving them out of ffmpeg and loading them at runtime (which would be a major ABI, API and usability break) does not solve that. You still need to either get said SDK and build them yourself, or get someone else to do it an run into the same issue with redistributability there.
If the general majority agrees that this series way of doing things is conforming, it is is good to go.
But I myself won't make that call.I'd still like to get this merged asap, so if in doubt, keep nvcc in the nonfree list for now, and discuss its removal from there in a separate patch.
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel