[FFmpeg-devel] [PATCH] Load CUDA driver API dynamically when needed

[Hendrik Leppkes]

On Thu, May 26, 2016 at 8:12 PM, Andrey Turkin <andrey.turkin at gmail.com> wrote:
>
> Enabling CUDA support adds some extremely useful features but it also
> adds hard runtime dependency on NVidia driver. This commit removes that
> dependency; driver library would be loaded when required.
> This allows to use same CUDA-enabled FFMpeg build on machines with and
> without NVidia cards.
> CUDA toolkit is still needed at build time. scale_npp filter still adds
> runtime dependency on libnppc and libnppi (which is fine since these
> libraries have to be redistributed with FFMpeg anyway, and they load
> CUDA internally on demand as well).
> ---
> Same patch was sent to libav ML
>
>  configure                      |   9 ++--
>  libavcodec/nvenc.c             |  24 ++++++----
>  libavfilter/vf_hwupload_cuda.c |  22 ++++++---
>  libavfilter/vf_scale_npp.c     |  12 ++++-
>  libavutil/Makefile             |   4 +-
>  libavutil/cuda_api.c           | 102 +++++++++++++++++++++++++++++++++++++++++
>  libavutil/cuda_api.h           |  53 +++++++++++++++++++++
>  libavutil/hwcontext_cuda.c     |  36 +++++++++------
>  8 files changed, 227 insertions(+), 35 deletions(-)
>  create mode 100644 libavutil/cuda_api.c
>  create mode 100644 libavutil/cuda_api.h
>

I really don't like adding factually public API/ABI to avutil for this
(avpriv is still part of the public ABI), we've been over this with
whole topic with QSV and the same conclusion applies here.
We have support for a variety of external libraries, which require an
external SDK to build and impose redistribution and runtime
restrictions. I don't see a convincing argument why CUDA should be
special, and litter avutil API/ABI with cuda-specifics to achieve
that.

- Hendrik