[CPU] FP16 support - ARM changes #18394
Conversation
| continue; | ||
| } | ||
|
|
||
| #if defined(OV_CPU_WITH_ACL) |
There was a problem hiding this comment.
Can we add more details why it is not working specifically for convolution node?
There was a problem hiding this comment.
@dmitry-gorokhov could you please propose the details I need to add here?
There was a problem hiding this comment.
As I can wee previously where was no post-ops support for FP16 precision, but it was introduced in openvinotoolkit/oneDNN@f0229f0. So I would propose to remove FP16 fusion limitations added in this PR and see if it still allows to use ACL Conv and MatMul/FC impls.
src/plugins/intel_cpu/tests/functional/single_layer_tests/instances/common/eltwise.cpp
Outdated
Show resolved
Hide resolved
|
Please also rebase PR on latest master and rebase merge conflicts |
github-actions
bot
added
the
category: IE Tests
github-actions
bot
added
category: Core
github-actions
bot
removed
category: Core
github-actions
bot
removed
the
category: IE Tests
src/plugins/intel_cpu/CMakeLists.txt
Outdated
| set(OV_CPU_WITH_ACL ON) | ||
| endif() | ||
|
|
||
| if (OV_CPU_WITH_ACL AND APPLE) |
There was a problem hiding this comment.
@EgorDuplensky @alvoron In fact condition which arch is used for ACL is determined here: https://github.com/openvinotoolkit/openvino/blob/master/src/plugins/intel_cpu/thirdparty/ACLConfig.cmake#L107. So once it will be changed this condition will become invalid.
Does it make sense to introduce intermidiate fp16 support variable inside ACLConfig which will contribute to OV_CPU_WITH_ACL_FP16 condition there?
There was a problem hiding this comment.
maybe we need to detect it directly in cpp code? E.g. when compiler enables FP16, it provides some macro like __ARM_FEATURE_FP16_VECTOR_ARITHMETIC
There was a problem hiding this comment.
The intention is the following: the decision on FP16 support on product level (assuming CPU arch) should be made based on the plugin feedback. The plugin itself defines (based os some internal considirations) corresponding variable and bypass it all other parts of the product (including CPU third-parties).
We don't want to use HW specific flags, as long as HW level FP16 support is not equal to product level FP16 support. Such differentiation might be also usefull for HW-agnostic conditional compilation (e.g. to enable compilation w/o FP16 support).
Also CPU build w/o some backends (like ACL) might result in the fact we cannot support FP16 efficiently due to lack of optimized impls. For such cases FP16 support on CPU level should be disabled as well.
| endif() | ||
|
|
||
| set(ARM_COMPUTE_TARGET_ARCH "${ARM_COMPUTE_TARGET_ARCH_DEFAULT}" CACHE STRING "Architecture for ARM ComputeLibrary") | ||
| set_property(CACHE ARM_COMPUTE_TARGET_ARCH PROPERTY STRINGS ${ARM_COMPUTE_TARGET_ARCHS}) |
There was a problem hiding this comment.
why have you removed cache variables? In case use useful to select ARM arch via cmage-gui and see possible values for architectures
4 participants
Ticket: CVS-110644
oneDNN PR: openvinotoolkit/oneDNN#205