Conda 虚拟环境中 cuDNN 版本获取问题

[lytning98]

您好，

我在使用 Conda 安装 paddlepaddle 2.0 后运行检测，结果显示

W0530 23:53:27.316645 18979 device_context.cc:346] device: 0, cuDNN Version: 7.4.

此时的主要环境为

(Ubuntu 16.04 LTS)
cudatoolkit               10.0.130                      0    https://mirrors.bfsu.edu.cn/anaconda/pkgs/main                                     
cudnn                     7.6.5                cuda10.0_0    https://mirrors.bfsu.edu.cn/anaconda/pkgs/main  
paddlepaddle-gpu    2.0.0rc0-py38_gpu_cuda10.0_many_linux
python                    3.8.2                hcf32534_0    https://mirrors.bfsu.edu.cn/anaconda/pkgs/main

可见 Conda 环境中的 cudnn 应为 7.6.5 版本，与 paddle.utils.run_check() 给出的结果不符；此版本号为我本地主机安装的 cuDNN 版本 7.4 （in /usr/local/cuda/include/cudnn.h）

更换 paddlepaddle 版本为 1.8.5，仅对 conda 虚拟环境进行如下操作：

The following packages will be DOWNGRADED:                                                                 
                                                                                                                                                 
  paddlepaddle-gpu    2.0.0rc0-py38_gpu_cuda10.0_many_linux --> 1.8.5-py38_gpu_cuda10.0_many_linux 

此时运行 paddle.fluid.install_check.run_check() 的输出提示 paddle 找到的 cuDNN 又变为了 conda 虚拟环境中的版本（in **/anaconda3/envs/ENV_NAME/include/cudnn.h），为

W0531 00:06:05.766619 36797 device_context.cc:260] device: 0, cuDNN Version: 7.6.  

而summary_env.py 给出的环境信息如下，似乎没有找到 cuDNN

****************************************
Paddle version: 1.8.5
Paddle With CUDA: True
OS: Ubuntu 16.04
Python version: 3.8.2
CUDA version: 10.0.130
cuDNN version: None.None.None
Nvidia driver version: 418.56
****************************************

请问这一结果是什么原因造成的？paddle 会优先使用 conda 虚拟环境下的 cudnn 还是主机中安装的 cudnn？

[paddle-bot-old]

您好，我们已经收到了您的问题，会安排技术人员尽快解答您的问题，请耐心等待。请您再次检查是否提供了清晰的问题描述、复现代码、环境&版本、报错信息等。同时，您也可以通过查看官网API文档、常见问题、历史Issue、AI社区来寻求解答。祝您生活愉快～

Hi! We've received your issue and please be patient to get responded. We will arrange technicians to answer your questions as soon as possible. Please make sure that you have posted enough message to demo your request. You may also check out the API，FAQ，Github Issue and AI community to get the answer.Have a nice day!

[ZHUI]

建议 不要混用 pip install paddlepaddle 和 conda install paddlepaddle.
conda install paddlepaddle 会优先按照 conda 环境配置。
pip install paddlepaddle 只会按照系统环境变量配置。

[lytning98]

建议 不要混用 pip install paddlepaddle 和 conda install paddlepaddle.
conda install paddlepaddle 会优先按照 conda 环境配置。
pip install paddlepaddle 只会按照系统环境变量配置。

您好，我在安装时全程使用的是 conda 安装，issue 中给出的环境信息都是 conda 的环境

[lytning98]

建议 不要混用 pip install paddlepaddle 和 conda install paddlepaddle.
conda install paddlepaddle 会优先按照 conda 环境配置。
pip install paddlepaddle 只会按照系统环境变量配置。

@ZHUI 您好，

我查阅并比较了 release/2.1 和 release/1.8 分支的相关源码，其中 1.8 源码中查找 cuDNN 动态链接库的相关逻辑是

Paddle/paddle/fluid/platform/dynload/dynamic_loader.cc

Lines 151 to 164 in e0aa1d6

	// 1. search in user config path by FLAGS
	void* dso_handle =
	GetDsoHandleFromSpecificPath(config_path, dso_name, dynload_flags);
	// 2. search in system default path
	if (nullptr == dso_handle) {
	dso_handle = GetDsoHandleFromDefaultPath(dso_name, dynload_flags);
	}
	// 3. search in extra paths
	if (nullptr == dso_handle) {
	for (auto path : extra_paths) {
	dso_handle = GetDsoHandleFromSpecificPath(path, dso_name, dynload_flags);
	}
	}

而 2.1 源码中的相关逻辑本与之一致，但在 PR #28117 中这三步逻辑中的第 2 步与第 3 步被交换了优先级，变为

Paddle/paddle/fluid/platform/dynload/dynamic_loader.cc

Lines 219 to 234 in c42ccf1

	for (auto dso : dso_names) {
	// 1. search in user config path by FLAGS
	dso_handle = GetDsoHandleFromSpecificPath(config_path, dso, dynload_flags);
	// 2. search in extra paths
	if (nullptr == dso_handle) {
	for (auto path : extra_paths) {
	VLOG(3) << "extra_paths: " << path;
	dso_handle = GetDsoHandleFromSpecificPath(path, dso, dynload_flags);
	}
	}
	// 3. search in system default path
	if (nullptr == dso_handle) {
	dso_handle = GetDsoHandleFromDefaultPath(dso, dynload_flags);
	}
	if (nullptr != dso_handle) break;
	}

其中 config_path 的值来自编译 flags，注释中所提到的 extra paths 即 path 的值是硬编码的路径

Paddle/paddle/fluid/platform/dynload/dynamic_loader.cc

Line 89 in c42ccf1

static constexpr char cuda_lib_path[] = "/usr/local/cuda/lib64";

这一改动导致了

在不重新编译的情况下，paddlepaddle 只会首先从硬编码的 cuda 路径中寻找 cuDNN，因此在硬编码的路径有效的情况下该路径下的 cuDNN 会被直接采用，LD_LIBRARY_PATH 等环境变量会被直接忽略，从而导致 conda 环境中的 cuDNN 无法被优先加载。

PR 中没有对此处修改进行任何说明。与之对比，加载位置优先级未被修改的 1.8 版本则无需任何额外操作就能正确加载 conda 环境中的 cuDNN。

而通常 linux 系统的普通用户没有权限对硬编码的路径 /usr/local/cuda/lib64 进行任何操作，这导致我无法对 paddlepaddle 加载 cuDNN 的行为进行任何的干涉。

请问我目前遇到的问题除了自行编译 paddlepaddle 外当前是否有其他简单解决方法？

also @ PR author @zhouwei25

[zhwesky2010]

@lytning98 您好，请问 /usr/local/cuda/lib64中路径是cudnn7.4吗

[zhwesky2010]

@lytning98 可以删除/usr/local/lib下的系统默认CUDA，只保留conda中的CUDA

[zhwesky2010]

@lytning98 也可以通过export FLAGS_cuda_dir=**conda的cuda安装路径** 来设置下

[lytning98]

@lytning98 您好，请问 /usr/local/cuda/lib64中路径是cudnn7.4吗

是的

@lytning98 短时间可以删除/usr/local/lib下的系统默认CUDA，只保留conda中的CUDA，后面我们会再调整一下
@lytning98 也可以通过export FLAGS_cuda_dir=**conda的cuda安装路径** 来设置下

本机的 /usr 目录我是没有权限的，我尝试了一下 flags 的方法，export FLAGS_cudnn_dir=xxx 似乎没有作用，debug 信息如下（export GLOG_v=3）

W0607 12:58:31.874564  1672 device_context.cc:404] Please NOTE: device: 0, GPU Compute Capability: 6.1, Driver API Version: 10.1, Runtime API Version: 10.1                                                            
I0607 12:58:31.874581  1672 dynamic_loader.cc:225] extra_paths: /usr/local/cuda/lib64
I0607 12:58:31.874588  1672 dynamic_loader.cc:168] Try to find library: libcudnn.so from specific path: /usr/local/cuda/lib64                                                                                          
W0607 12:58:31.879654  1672 device_context.cc:422] device: 0, cuDNN Version: 7.4.

对照代码来看应该还是使用了第二种方法查找 cudnn.so

Paddle/paddle/fluid/platform/dynload/dynamic_loader.cc

Lines 220 to 228 in c42ccf1

	// 1. search in user config path by FLAGS
	dso_handle = GetDsoHandleFromSpecificPath(config_path, dso, dynload_flags);
	// 2. search in extra paths
	if (nullptr == dso_handle) {
	for (auto path : extra_paths) {
	VLOG(3) << "extra_paths: " << path;
	dso_handle = GetDsoHandleFromSpecificPath(path, dso, dynload_flags);
	}
	}

并且 flags 值似乎没有成功传入，flags 是空值，否则会有 debug 信息，参考如下代码

Paddle/paddle/fluid/platform/dynload/dynamic_loader.cc

Lines 162 to 169 in c42ccf1

	static inline void* GetDsoHandleFromSpecificPath(const std::string& spec_path,
	const std::string& dso_name,
	int dynload_flags) {
	void* dso_handle = nullptr;
	if (!spec_path.empty()) {
	// search xxx.so from custom path
	VLOG(3) << "Try to find library: " << dso_name
	<< " from specific path: " << spec_path;

我也尝试了使用 paddle.fluid.set_flags 设置 flags 的值，但会报错如下

>>> paddle.fluid.set_flags({'FLAGS_cudnn_dir': '/somewhere/anaconda3/lib'})
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/data/zhaoyao/anaconda3/envs/paddle/lib/python3.8/site-packages/paddle/fluid/framework.py", line 6159, in set_flags
    raise ValueError(
ValueError: Flag FLAGS_cudnn_dir cannot set its value through this function.

请问是哪里有问题呢，还有什么方法能够手动设置 flags 的值吗，如果能成功手动设置这一项 flag 确实应该是能解决问题的
@zhouwei25

[yang20085936]

我也遇到了类似的问题，paddle2.1 不能准确识别虚拟环境中的cudnn版本。在复现“https://www.paddlepaddle.org.cn/documentation/docs/zh/tutorial/cv_case/convnet_image_classification/convnet_image_classification.html”时候出现

device: 0. The installed Paddle is compiled with CUDNN 8.1, but CUDNN version in your machine is 8.0, which may cause serious incompatible bug. Please recompile or reinstall Paddle with compatible CUDNN version.

FatalError: Segmentation fault is detected by the operating system.
[TimeInfo: *** Aborted at 1623375974 (unix time) try "date -d @1623375974" if you are using GNU date ***]
[SignalInfo: *** SIGSEGV (@0x0) received by PID 13986 (TID 0x7f1401a65700) from PID 0 *]
Process finished with exit code 139 (interrupted by signal 11: SIGSEGV)`

[yang20085936]

@lytning98 可以删除/usr/local/lib下的系统默认CUDA，只保留conda中的CUDA
/usr/local/lib下面只有python2.7和python3.6两个文件包，并没有CUDA。怎么回事呢？

[yang20085936]

@lytning98 也可以通过export FLAGS_cuda_dir=**conda的cuda安装路径** 来设置下

您好，请问这是在那里设置的？