Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Stream Executor: perform a cudnn library vs. binary check, add relu6/x support. #1987

Merged
merged 1 commit into from
Apr 19, 2016

Conversation

vrv
Copy link

@vrv vrv commented Apr 16, 2016

During initialization, we check whether the loaded version
of the cudnn library matches the version of the library that
the binary was compiled against. When there is a mismatch,
throw an error.

Example: I built with cudnnv5 but I am loading V4, and I get:

E tensorflow/stream_executor/cuda/cuda_dnn.cc:298] Loaded cudnn library: 4007 but source was compiled against 5004. If using a binary install, upgrade your cudnn library to match. If building from sources, make sure the library loaded matches the version you specified during compile configuration.

I then copy the v5 version of libcudnn.so into /usr/local/cuda/lib64
and when I re-run the program, the error goes away.

Thoughts, @zheng-xq, @leary-google, @zffchen78 ?

During initialization, we check whether the loaded version
of the cudnn library matches the version of the library that
the binary was compiled against.  When there is a mismatch,
throw an error.

Example: I built with cudnnv5 but I am loading V4, and I get:

E tensorflow/stream_executor/cuda/cuda_dnn.cc:298] Loaded cudnn library: 4007 but source was compiled against 5004.  If using a binary install, upgrade your cudnn library to match.  If building from sources, make sure the library loaded matches the version you specified during compile configuration.

I then copy the v5 version of libcudnn.so into /usr/local/cuda/lib64
and when I re-run the program, the error goes away.

Thoughts, @zheng-xq, @leary-google ?
@martinwicke
Copy link
Member

+1. Should I merge this?

@martinwicke
Copy link
Member

However, aren't cuDNN backwards compatible, at least to some degree? Should we check >=?

@vrv
Copy link
Author

vrv commented Apr 19, 2016

Not really. Even when the api is the same it sometimes doesn't work

On Tue, Apr 19, 2016, 9:15 AM Martin Wicke notifications@github.com wrote:

However, aren't cuDNN backwards compatible, at least to some degree?
Should we check >=?


You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
#1987 (comment)

@zheng-xq
Copy link
Contributor

Ideally, we only want to check the major versions, since the minor versions
and patch levels do not affect backward compatibility. That is true for all
official binaries starting from RC.

However, given we have a number of EA binaries floating around, this is not
necessarily true any more. So the current check is a bit too strict, but
fine in practice.

On Tue, Apr 19, 2016 at 9:19 AM, Vijay Vasudevan notifications@github.com
wrote:

Not really. Even when the api is the same it sometimes doesn't work

On Tue, Apr 19, 2016, 9:15 AM Martin Wicke notifications@github.com
wrote:

However, aren't cuDNN backwards compatible, at least to some degree?
Should we check >=?


You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
<
https://github.com/tensorflow/tensorflow/pull/1987#issuecomment-212000836>


You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#1987 (comment)

@martinwicke martinwicke merged commit dfcad66 into tensorflow:master Apr 19, 2016
fsx950223 pushed a commit to fsx950223/tensorflow that referenced this pull request Nov 28, 2023
…upstream-sync-230201

Develop upstream sync 230201
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants