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
python3Packages.pytorch: remove oneDNN dependency #96350
python3Packages.pytorch: remove oneDNN dependency #96350
Conversation
oneDNN was added as a dependency, but it is not actually used by PyTorch. PyTorch uses oneDNN from the vendored iDeep dependency. Using a system-provided oneDNN is currently not a supported build option.
361e1e5
to
a4ed797
Compare
@ofborg build python37Packages.pytorch python38Packages.pytorch |
cc: @alexarice @bhipple |
# pytorch still calls it by the old name mkldnn. | ||
# Unlike MKL, oneDNN (née MKLDNN) is FOSS, so we enable support for | ||
# it by default. PyTorch currently uses its own vendored version | ||
# of oneDNN through Intel iDeep. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sigh vendored dependencies . . . I guess it is what it is though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, it's a bit annoying that they do not provide some option to provide your own oneDNN. Doesn't help that CMake is hidden behind their own script that gates build flags :/.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would be really nice if you could contribute a patch upstream to support non-vendored distribution deps, but in the meantime this PR seems OK as it at least faithfully represents the status quo.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I will do that if I find some time. First some more BLAS implementation fights, erm, I mean benchmarks. Intel has removed MKL_DEBUG_CPU_TYPE
since MKL 2020 release 1, so Ryzen performance is abysmal. There is a workaround, but not too happy with it ;).
Motivation for this change
oneDNN was added as a dependency, but it is not actually used by
PyTorch. PyTorch uses oneDNN from the vendored iDeep dependency.
Using a system-provided oneDNN is currently not a supported build
option.
Things done
sandbox
innix.conf
on non-NixOS linux)nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
./result/bin/
)nix path-info -S
before and after)