-
Notifications
You must be signed in to change notification settings - Fork 21.3k
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鈥檒l occasionally send you account related emails.
Already on GitHub? Sign in to your account
[1.9.1] [collect_env] collect_env does not collect actual runtime-loaded cudnn version #78489
Comments
|
Just wanted to post the same :P |
I guess it is what's happening. But for debugging it makes sense to also report the version linked in / discovered by PyTorch. A lazy version (if PyTorch installation is workable enough to be imported) could just report this As is, it's quite confusing, since requires to manually find linked in versions, since they are quite relevant Bonus for making the printed message clearer to explain what exactly collect_env is trying to discover/report (version at build time, version at linking time, dynamically loaded version, etc) Reporting both env AND actual pytorch found one is important for debugging some linking/loading issues when PyTorch is loading a version different from what it is compiled against |
Related: #80637 |
So probably can be done by reading f"/proc/{os.getpid()}/maps" (on Unix machines, and if this file exists) and filtering cudnn/blas/actually loaded dependencies .so files |
Also, there is some improved collect_env in detectron2: https://github.com/facebookresearch/detectron2/blob/main/detectron2/utils/collect_env.py#L55 |
馃悰 Describe the bug
In opposite,
torch.backends.cudnn.version()
does collect it correctly.Originally reported by @grazder in a comment: #78475 (comment)
This occurred on old-ish version of 1.9.1, not sure if it still happens on 1.11.0
Versions
1.9.1
cc @csarofeen @ptrblck @xwang233
The text was updated successfully, but these errors were encountered: