-
Notifications
You must be signed in to change notification settings - Fork 6.8k
[submodule] Remove soon to be obsolete dnnl nomenclature from mxnet #20606
Conversation
Hey @bartekkuncer , Thanks for submitting the PR
CI supported jobs: [unix-cpu, sanity, edge, centos-cpu, website, clang, windows-gpu, unix-gpu, centos-gpu, windows-cpu, miscellaneous] Note: |
a68a3ea
to
e6b4434
Compare
c7dc6aa
to
aaae390
Compare
@mxnet-bot ci run [miscellaneous] |
Undefined action detected. |
6c6fe03
to
7c06f57
Compare
@mxnet-bot run ci [centos-cpu, unix-gpu] |
Jenkins CI successfully triggered : [centos-cpu, unix-gpu] |
Is this change ready? |
Yes. |
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 have made review for docs directory.
For me it seems that we have to use flags and directories as "dnnl" but in description we should use official library name "oneDNN". Also I am not use if "Intel's OneDNN" is proper name and it should be just "oneDNN"
docs/python_docs/python/tutorials/performance/backend/dnnl/dnnl_readme.md
Outdated
Show resolved
Hide resolved
docs/python_docs/python/tutorials/performance/backend/dnnl/index.rst
Outdated
Show resolved
Hide resolved
@anko-intel I will apply other changes after all reviews are done. |
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.
@anko-intel Should python-side (or user-side in general) changes also use oneDNN
then?
9833a3c
to
749f01d
Compare
@mxnet-bot run ci [unix-cpu] |
Jenkins CI successfully triggered : [unix-cpu] |
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.
LGTM!
This PR is an answer to the statement from oneDNN:
"oneDNN decided to stop shipping and supporting mkldnn compatibility layer (old names of mkldnn instead of dnnl). The change that removes it is targeting v2.5.
Compatibility layer was introduced in v1.1 when library changed the name. At that time we posted an article how to smoothly transfer from mkldnn to dnnl in source codes and other places. Here's the article: https://oneapi-src.github.io/oneDNN/v2/dev_guide_transition_to_dnnl.html
Who's impacted?
Users who update oneDNN binaries without re-compilation of oneDNN won't see any effect from MKLDNN_somevar env variables.
Users who compile oneDNN from scratch are impacted more:
If user's build system utilizes oneDNN build switches starting with MKLDNN_ prefix, option won't affect the build, and likely CMake would spit a warning message saying such variables weren't used.
If source codes are still utilizing mkldnn namespace or types/APIs that contain mkldnn_ prefix, they won't be compiled successfully.
If end application is linked against libmkldnn.so, it won't be linked successfully.
Finally, MKLDNN_somevar env variables won't take affect in run-time.
We are kindly asking to make sure that mkldnn prefix is not used anywhere on your side, neither in product nor in testing environment.
v2.5 Branch cutoff October 29, 2021 (ww44.5), production release December 10, 2021. Feel free to ask questions. Thank you.".
This change also aims to unify names used to refer to dnnl library in mxnet.