[DNNL][Relay extern-schedule] DNNL Conv2D Kernel enable by assigning "-libs=mkldnn"

[Qianshui-Jiang]

This PR mainly about mapping oneDNN OP implementation in X86 Relay Op Strategy. we've observed that nn.dense kernel that could be dispatched to DNNL by assigning "-libs=mkldnn" and there is also conv2d kernel implemented in runtime/contrib/dnnl.

so we mapping it in X86 Relay Op Strategy and optimized the kernel implementation to let DNNL choose blocked format according to different input shape, as performance-profiling example discribed in oneDNN doc.

Here is the details:

• Adjust DNNL Conv2D implementation to let it support NHWC format and automate reorder for input/weights/outputs to abtain best performace.
• Add 'target.libs=mkldnn' branch in Relay X86 OP strategy for both NCHW and NHWC Conv2D kernel.
• Add 2 test funtions for case mentioned above.

We are trying to enable more DNNL kernels including different format and datatypes this way.

[Qianshui-Jiang]

@comaniac @AndrewZhaoLuo @junrushao1994 @masahi could you pls help review and have some suggestions on how to organized the file to USE_MKLDNN not only for cblas ? should the test case added in test_dnnl.py?

[comaniac]

Will take a look early next week.

[Qianshui-Jiang]

@yangulei thanks for your suggesttion ! : ) and I've added the check for registed external function in test case, seems it works~

[comaniac]

The name is a bit confusing...so does the use of libraries. We now have USE_MKLDNN (for cblas with matmul/dense) and USE_DNNL (for DNNL/OneDNN with matmal/dense/conv2d). AFAIK, MKL-DNN can be covered by DNNL, so should we deprecate MKL-DNN and use DNNL for both cases (e.g., -libs and BYOC)?

[Qianshui-Jiang]

I agree with that should be a unified name of DNNL, we already have USE_DNNL_CODEGEN and USE_MKLDNN for BYOC and -libs，I suggest to have USE_DNNL_LIBS for -libs and USE_DNNL_CODEGEN for BYOC, and change 'mkldnn' to 'dnnl' in codes.

[comaniac]

I don't think we really need to have 2 flags? It seems fine to enable both libs and BYOC when USE_DNNL is ON.

[Qianshui-Jiang]

Yep, that would be more concise, 💯
I'll try and commit later.

[Qianshui-Jiang]

@comaniac hi，I change the cmake config flags and the symbol mkldnn to dnnl, now setup USE_DNNL can make both -libs and dnnl_codegen enabled.
BTW，seems a lot of files are influenced, shoud we splite this PR into 2 threads? pls take a look and comments more. thx a lot !

[comaniac]

It's a good idea. Please split the part that unifies MKL-DNN and DNNL to a separate PR.
Since it involves compatibility changes (e.g., config.cmake), it may need more reviews and visibility.

cc @masahi @areusch

[Qianshui-Jiang]

@comaniac @masahi @areusch, hi guys，new PR created in #11638 , I would rebase this PR after that updated in mainline.
pls take a look, thx !

[Qianshui-Jiang]

@comaniac I reset this PR to compatible with current mainline (use mkldnn), only contains the change described in title. or we can update them all later in #11638 ?

[comaniac]

The current scope seems good to me. You could either make this PR upstream compatible and rebase #11638, or rebase this PR after 11638 has merged. I'm fine with either way.

[Qianshui-Jiang]

The current scope seems good to me. You could either make this PR upstream compatible and rebase #11638, or rebase this PR after 11638 has merged. I'm fine with either way.

Seems #11638 was suggested to support -libs=mkldnn continuously but translated it to -libs=dnnl, litlle bit more tiny change would be considered,
Could you pls approvel merge this one at first? so that we could updating all of which related to -libs=mkldnn together in 11638.

[comaniac]

LGTM. cc @masahi