Hi all
As today, if ngraph is compiled with NGRAPH_GPU_ENABLE=TRUE (which ofcourse needs a nvidia ecosystem installed) then libngraph.so is hardly linked with few nvidia libs:
`ldd /tmp/ngraph/lib/libngraph.so

libcuda.so.1 => /usr/lib/x86_64-linux-gnu/libcuda.so.1
libnvrtc.so.8.0 => /usr/local/cuda-8.0/targets/x86_64-linux/lib/libnvrtc.so.8.0
libcublas.so.8.0 => /usr/local/cuda-8.0/targets/x86_64-linux/lib/libcublas.so.8.0
libcudnn.so.7 => /usr/local/cuda-8.0/targets/x86_64-linux/lib/libcudnn.so.7
libnvidia-fatbinaryloader.so.375.74 => /usr/lib/nvidia-375/libnvidia-fatbinaryloader.so.375.74
...
`

For production & deployment purpose, this is not practical because such a libngraph build wont be able to be loaded at all on machines without the nvidia gpu ecosystem, ie cpu only.

Thanks to the fact that the ngraph arch is pretty clean, this is only needed for some C function calls needed in the gpu backend only (ngraph/src/ngraph/runtime/gpu) : cublasCreate, cudnnCreate, cublasSetPointerMode, cublasDestroy, cuInit, cuDeviceGet, cuCtxCreate, nvrtcCreateProgram, nvrtcCompileProgram, nvrtcGetPTXSize, nvrtcGetPTX, nvrtcDestroyProgram, cuLaunchKernel, ...

It could be possible to dynamically load these libs using standard posix 'dl' :
http://man7.org/linux/man-pages/man3/dlopen.3.html

The PyTorch team seems to also try to do such :
pytorch/pytorch#3395

Before moving forward, would you be open to this idea or do you see any red flags ?

Kind
W.