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.

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Reply via email to