[FFmpeg-devel] [PATCH 1/5] configure: Add an explicit check and option for nvcc

[Timo Rothenpieler]

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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4538 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20190226/63f51ec0/attachment.bin>