[FFmpeg-devel] [PATCH 1/5] configure: Add an explicit check and option for nvcc
timo at rothenpieler.org
Tue Feb 26 15:50:47 EET 2019
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
> 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
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
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 4538 bytes
Desc: S/MIME Cryptographic Signature
More information about the ffmpeg-devel