mozga-intel opened a new issue #20353: URL: https://github.com/apache/incubator-mxnet/issues/20353
## Overview This RFC targets discussing the strategies for building MXNet with Intel DNNL. Currently, `#if` has become a critical directive in solving massive including-problem. Every single file that implements OneDNN's operator has to be placed between #if-scope. This ensures that its functionality will be either disabled, when MxNet has not built with a OneDNN, or disabled otherwise. This functionality is controlled by a global flag: `MXNET_USE_MKLDNN` If the flag is set on **1,** then an operator is marked as an implemented. Otherwise, any one is marked as unimplemented. Note, that during a compile time, if a global flag `DUSE_MKLDNN=OFF` isn't set on, then files will be still added to the workflow - but the operator won't be supported. This observation leads to simple conclusion that these `includings are relatively costly because of the if-scope. For theoretical guarantees, every single files might be skipped and not to be added to the workflow - furthermore, it could be steer on a CMake level. If the flag is set on 1, the internal implementation is added thusly: ```cpp #if MXNET_USE_MKLDNN == 1 #include "../../nn/mkldnn/mkldnn_base-inl.h" #include "../../nn/mkldnn/mkldnn_convolution-inl.h" #include "../../nn/convolution-inl.h" #include "../quantization_utils.h" .... ``` ## Motivate ## This document describes the flow for OneDNN. This is motivated by: 1. A dozen of files is added during a compile-time. 2. Easily read operators placed in #if scope. 3. Enabling/Disabling should be controlled by a CMake file. 4. To avoid a pattern that causes conflicts. 5. Only one CMake-file controls the whole flow. Note that the workflow is controlled by only one CMake. ## Proposed solutions ## We propose control this workflow from the CMake lvele. Since CMake has a special flag ` -DUSE_MKLDNN=ON` saying whether OneDNN framework is enabled, we can move towards a logic. Putting a logic inside, we ensure that files will not be added to the workflow. How to search a file? For brevity: every single files (i.e OneDNN dedicated only) have an `mkldnn_` prefix. These information might be useful to be used to detect these narrow dedicated files. Unfortunately, there is only one CMake file to do everything. It has an relatively "huge" impact on a readibilty of the global CMake file. To improve the readability of the a file, an appropriate structure of CMake file might be placed in MKLDNN dir. It could be looks like: ```cpp |── CMakeList.txt <------ General CMake │ ├── log_softmax.cu │ ├── lrn.cc │ ├── lrn.cu │ ├── lrn-inl.h │ ├── mkldnn │ │ ├── **CMakeList.txt** <------ Aditional CMake │ │ ├── mkldnn_act.cc │ │ ├── mkldnn_act-inl.h │ │ ├── mkldnn_adaptive_pooling.cc ``` After that, this file might be directly included in the global CMake file. ## Further steps ## Following this path, we can try to create an appropriate layout for the CMake files. At the moment, there is only one CMake File that manages everything. Maybe, is not better to have only one to everything, but many to one thing. [? Open] ## References - Example of [mkldnn_quantized_conv.cc](https://github.com/apache/incubator-mxnet/blob/3f9235e228887eb1a13cc50e335a25cc5e66162b/src/operator/quantization/mkldnn/mkldnn_quantized_conv.cc#L26) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@mxnet.apache.org For additional commands, e-mail: issues-h...@mxnet.apache.org
