RISC-V/AArch64: disable CPU features detection #25901

mshabunin · 2024-07-12T10:48:45Z

This PR is the first step in fixing current issues with NEON/RVV, FP16, BF16 and other CPU features on AArch64 and RISC-V platforms.

On AArch64 and RISC-V platforms we usually have the platform set by default in the toolchain when we compile it or in the cmake toolchain file or in CMAKE_CXX_FLAGS by user. Then, there are two ways to set platform options: a) "-mcpu=<some_cpu>" ; b) "-march=" (e.g. "rv64gcv"). Furthermore, there are no similar "levels" of optimizations as for x86_64, instead we have features (RVV, FP16,...) which can be enabled or disabled. So, for example, if a user has "rv64gc" set by the toolchain and we want to enable RVV. Then we need to somehow parse their current feature set and append "v" (vector optimizations) to this string. This task is quite hard and the whole procedure is prone to errors.

I propose to use "CPU_BASELINE=DETECT" by default on AArch64 and RISC-V platforms. And somehow remove other features or make them read-only/detect-only, so that OpenCV wouldn't add any extra "-march" flags to the default configuration. We would rely only on the flags provided by the compiler and cmake toolchain file. We can have some predefined configurations in our cmake toolchain files.

Changes made by this PR:

CMakeLists.txt:
- use CMAKE_CROSSCOMPILING instead of CMAKE_TOOLCHAIN_FILE to detect cross-compilation. This might be useful in cases of native compilation with a toolchain file
- removed obsolete variables ENABLE_NEON and ENABLE_VFPV3, the first one have been turned ON by default on AArch64 platform which caused setting CPU_BASELINE=NEON
- raise minimum cmake version allowed to 3.7 to allow using CMAKE_CXX_FLAGS_INIT in toolchain files
added separate files with arch flags for native compilation on AArch64 and RISC-V, these files will be used in our toolchain files and in regular cmake
use DETECT as default value for CPU_BASELINE also allow NATIVE, warn user if other values were used (only for AArch64 and RISC-V)
for each feature listed in CPU_DISPATCH check if corresponding CPU_${opt}_FLAGS_ON has been provided, warn user if it is empty (only for AArch64 and RISC-V)
use CPU_BASELINE_DISABLE variable to actually turn off macros responsible for corresponding features even if they are enabled by compiler
removed Aarch64 feature merge procedure (it didn't support -mcpu and built-in -march)
reworked AArch64 and two RISC-V cmake toolchain files (does not affect Android/OSX/iOS/Win):
- use CMAKE_CXX_FLAGS_INIT to set compiler flags
- use variables ENABLE_BF16, ENABLE_DOTPROD, ENABLE_RVV, ENABLE_FP16 to control -march
- AArch64: removed other compiler and linker flags
  - -fdata-sections, -fsigned-char, -Wl,--no-undefined, -Wl,--gc-sections - already set by OpenCV
  - -Wa,--noexecstack, -Wl,-z,noexecstack, -Wl,-z,relro, -Wl,-z,now - can be enabled by OpenCV via ENABLE_HARDENING
  - -Wno-psabi - this option used to disable some warnings on older ARM platforms, shouldn't harm
- ARM: removed same common flags as for AArch64, but left -mthumb and --fix-cortex-a8, -z nocopyreloc

opencv-alalek · 2024-07-18T05:41:53Z

cmake/OpenCVCompilerOptimizations.cmake


  set(CPU_DISPATCH "" CACHE STRING "${HELP_CPU_DISPATCH}")
  set(CPU_BASELINE "DETECT" CACHE STRING "${HELP_CPU_BASELINE}")

+  if(NOT CPU_BASELINE STREQUAL "DETECT")
+    message(FATAL_ERROR "RISC-V only supports CPU_BASELINE=DETECT, use CMAKE_CXX_FLAGS or cmake toolchain file options to change platform")


I propose to revert changes in this files and use:

cmake: try optimization feature check without extra flags first #25930

The main idea here is to avoid modifying arch compiler flags at all. If I understand correctly, changes in #25930 will still try to append custom flags and run compiler checks.

For example, with that patch, if we compile OpenCV with -DCMAKE_CXX_FLAGS="-mcpu=cortex-a72" -DCPU_BASELINE=NEON_FP16 options (cortex-a72 is armv8-a CPU), then our scripts will silently append -march=armv8.2-a+fp16 and make this build incompatible with explicitly requested CPU.

This behavior can cause compatibility, performance issues and compilation errors.

avoid modifying arch compiler flags at all

For dispatched optimization we still need to modify compiler flags anyway.

make this build incompatible with explicitly requested CPU

If compiler doesn't fail on try_compile() in that case then it could be workaronded through -DCPU_NEON_FP16_FLAGS_ON= CMake override.

Besides of DETECT, empty or other values of CPU_BASELINE are used for limiting of used features in OpenCV without touching compiler flags.

For dispatched optimization we still need to modify compiler flags anyway.

Yes, perhaps users will be required to manually provide flags for dispatched files via CPU_XXX_FLAGS_ON variables. Examples with our cmake-toolchain file from this PR:

Build with RVV as a baseline: -DENABLE_RVV=ON

Build without RVV in a baseline, but with dispatched RVV files: -DCPU_DISPATCH=RVV -DCPU_RVV_FLAGS_ON=-march=rv64gcv

empty or other values of CPU_BASELINE are used for limiting of used features

Doesn't CPU_BASELINE_DISABLE do this? I tried to use it with this PR and enabled RVV compiler flags: -DENABLE_RVV=ON -DCPU_BASELINE_DISABLE=RVV, but I'm not sure if correct macros are being set in cv_cpu_config.h:

// OpenCV CPU baseline features #define CV_CPU_COMPILE_RVV 1 #define CV_CPU_BASELINE_COMPILE_RVV 1 #define CV_CPU_BASELINE_FEATURES 0 \ , CV_CPU_RVV \ // OpenCV supported CPU dispatched features #define CV_CPU_DISPATCH_FEATURES 0 \

opencv-alalek · 2024-07-18T05:42:46Z

platforms/linux/arm.toolchain.cmake

@@ -57,6 +57,16 @@ if(NOT DEFINED CMAKE_CXX_FLAGS)

  set(CMAKE_CXX_FLAGS           "${CMAKE_CXX_FLAGS} -fdata-sections -Wa,--noexecstack -fsigned-char -Wno-psabi")
  set(CMAKE_C_FLAGS             "${CMAKE_C_FLAGS} -fdata-sections -Wa,--noexecstack -fsigned-char -Wno-psabi")
+  if(CMAKE_SYSTEM_PROCESSOR STREQUAL "aarch64")
+    # see https://gcc.gnu.org/onlinedocs/gcc/AArch64-Options.html
+    if(ENABLE_BF16)


ENABLE_BF16

Toolchain files have issue with cached variables (not available to them - just add message()),

I've checked this variable, it seem to be working. I build with -DENABLE_BF16=ON and got -march=armv8.6-a in the compiler string. We use this approach in XuanTie cmake toolchain: https://github.com/opencv/opencv/blob/4.x/platforms/linux/riscv64-071-gcc.toolchain.cmake (CORE variable)

Just add message() and run.
Also add message() for modified CMAKE_CXX_FLAGSbecause you got theelse()` branch in case of undefined value.

Oh, I remembered, it was an issue with CMAKE_CXX_FLAGS. As I understand, modern cmake (3.7+) have respective _INIT variables for toolchain files specifically (https://cmake.org/cmake/help/latest/variable/CMAKE_LANG_FLAGS_INIT.html). In new commit I've updated some of our toolchains to use them too.

opencv-alalek · 2024-07-18T05:46:11Z

platforms/linux/arm.toolchain.cmake

+    # see https://gcc.gnu.org/onlinedocs/gcc/AArch64-Options.html
+    if(ENABLE_BF16)
+      set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -march=armv8.6-a")
+      set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -march=armv8.6-a")


Toolchain files are not used for native compilation.

We need a robust solution for such cases too, e.g. through OPENCV_EXTRA_* flags (currently they are applied after the feature checks)

For native compilation we assume that toolchain have architecture flags set by default.

For example on Armbian 12 (OrangePi) I have:

g++ -march=native -Q --target-help | grep march -march= armv8.2-a+crypto+fp16+rcpc+dotprod

-march=native

It is not a default actually.

"Native" case is already properly handled by the current scripts: https://github.com/opencv/opencv/blob/4.10.0/cmake/OpenCVCompilerOptimizations.cmake#L167

For native compilation we can:

leave it to user - set CMAKE_CXX_FLAGS or write your own cmake toolchain file

make our own cmake toolchain files similar to those used for cross-compilation (feature controlling flags should be the same)

BTW, we don't handle -mcpu=native (equivalent to -march=native -mtune=native if I understand correctly). Example from Armbian:

orangepi@orangepi5:~$ gcc -Q --help=target | egrep 'mtune|mcpu|march' -march= armv8-a -mcpu= generic -mtune= generic orangepi@orangepi5:~$ gcc -march=native -Q --help=target | egrep 'mtune|mcpu|march' -march= armv8.2-a+crypto+fp16+rcpc+dotprod -mcpu= generic -mtune= generic orangepi@orangepi5:~$ gcc -mcpu=native -Q --help=target | egrep 'mtune|mcpu|march' -march= armv8.2-a -mcpu= cortex-a76.cortex-a55+crypto -mtune= cortex-a76.cortex-a55

opencv-alalek · 2024-08-02T02:41:20Z

platforms/linux/arm.toolchain.cmake

-  elseif(CMAKE_SYSTEM_PROCESSOR STREQUAL aarch64)
-    set(ARM_LINKER_FLAGS "-Wl,--no-undefined -Wl,--gc-sections -Wl,-z,noexecstack -Wl,-z,relro -Wl,-z,now")
+# == Compiler flags
+set(common_cc_opt "-fdata-sections -Wa,--noexecstack -fsigned-char -Wno-psabi")


Looks like these options are lost:

https://pullrequest.opencv.org/buildbot/builders/precommit_armv8/builds/100061

https://pullrequest.opencv.org/buildbot/builders/precommit_armv7/builds/100073

This is because cmake version on buildbot is too old (3.5.1) for this feature (CMAKE_<LANG>_FLAGS_INIT). I propose raising minimum cmake version to 3.7.

My experiments has shown that unfortunately FLAGS_INIT vars do not work with regular FLAGS variables as I expected. They are not appended to initial value, but override it:

cmake \ -DCMAKE_TOOLCHAIN_FILE=/work/opencv/platforms/linux/riscv64-clang.toolchain.cmake \ ../opencv # result: -march=rv64gc ... # this is flag from our toolchain file cmake \ -DCMAKE_TOOLCHAIN_FILE=/work/opencv/platforms/linux/riscv64-clang.toolchain.cmake \ -DCMAKE_CXX_FLAGS="-Werror" \ ../opencv # result: -Werror ... # no -march flags from toolchain file

Correct way to add custom flags to cross-compilation in this case will be via

CMAKE_<LANG>_FLAGS_<CONFIG> variable, or

<LANG>FLAGS environment variable, or

OpenCV-specific variables OPENCV_EXTRA_<LANG>_FLAGS, or

custom toolchain-file.

I believe this behavior is acceptable because this is how cmake works.

opencv-alalek · 2024-08-03T03:39:32Z

cmake/OpenCVCompilerOptimizations.cmake

+    set(CPU_BASELINE "DETECT" CACHE STRING "${HELP_CPU_BASELINE}")
+    set(CPU_DISPATCH "" CACHE STRING "${HELP_CPU_DISPATCH}")
+    if(NOT CPU_BASELINE STREQUAL "DETECT")
+      message(WARNING "ARM64 only supports CPU_BASELINE=DETECT, use CMAKE_CXX_FLAGS or cmake toolchain file options to change platform")


CPU_BASELINE=NATIVE should be supported.

cmake/OpenCVCompilerOptimizations.cmake

opencv-alalek · 2024-09-06T07:06:10Z

cmake/OpenCVCompilerOptimizations.cmake

+    # ok
+  elseif(NOT CPU_BASELINE STREQUAL "DETECT")
+    message(WARNING "Platform ${CMAKE_SYSTEM_PROCESSOR} only supports CPU_BASELINE=DETECT|NATIVE, use CMAKE_CXX_FLAGS or cmake toolchain file options to modify compiler options")
+    set(CPU_BASELINE "DETECT")


I'm still against forcing of DETECT. It could be default, but it should not be forced.
We should not block user to disable some OpenCV intrinsics, e.g. for debug/testing purposes. Even if they are "enabled in compiler".

I've added support of an empty CPU_BASELINE.

Currently this configuration is broken due to incorrect macros being used somewhere in DNN inline optimizations: compiler has feature enabled and some macros are enabled too, but some other macros from generated cv_cpu_config.hpp are disabled, thus causing missing symbols.

/usr/bin/ld: modules/dnn/CMakeFiles/opencv_dnn.dir/src/layers/cpu_kernels/conv_winograd_f63.cpp.o: in function `cv::dnn::runWinograd63(cv::_InputArray const&, cv::_InputArray const&, cv::_OutputArray const&, cv::Ptr<cv::dnn::FastConv> const&, int, float, float, cv::dnn::dnn4_v20240521::ActivationLayer*, bool)::{lambda(cv::Range const&)#1}::operator()(cv::Range const&) const': /work/opencv/modules/dnn/src/layers/cpu_kernels/conv_winograd_f63.cpp:205: undefined reference to `cv::dnn::winofunc_BtXB_8x8_F32(float const*, int, float*, int, int, int)' /usr/bin/ld: modules/dnn/CMakeFiles/opencv_dnn.dir/src/layers/cpu_kernels/conv_winograd_f63.cpp.o: in function `cv::dnn::runWinograd63(cv::_InputArray const&, cv::_InputArray const&, cv::_OutputArray const&, cv::Ptr<cv::dnn::FastConv> const&, int, float, float, cv::dnn::dnn4_v20240521::ActivationLayer*, bool)::{lambda(cv::Range const&)#2}::operator()(cv::Range const&) const': /work/opencv/modules/dnn/src/layers/cpu_kernels/conv_winograd_f63.cpp:302: undefined reference to `cv::dnn::winofunc_accum_F32(float const*, float const*, float*, int, int, int, int, int, int)' /usr/bin/ld: /work/opencv/modules/dnn/src/layers/cpu_kernels/conv_winograd_f63.cpp:368: undefined reference to `cv::dnn::winofunc_AtXA_8x8_F32(float const*, int, float*, int, float*, int, float, float, float, bool)' collect2: error: ld returned 1 exit status

It is not related to this PR and we'll need to resolve this issue separately, my quick fix attempt has failed.

Just "empty" handling is not enough.

We should not block user to disable some OpenCV intrinsics, e.g. for debug/testing purposes. Even if they are "enabled in compiler".

User can disable OpenCV intrinsics on affected platforms in two ways:

set -DCPU_BASELINE= - disable all intrinsics

set -DCPU_BASELINE_DISABLE=RVV - disable selected categories

Example:

cmake \ -DRISCV_CLANG_BUILD_ROOT=/chains/llvm-main -DRISCV_GCC_INSTALL_ROOT=/chains/riscv-gcc-14.1.0 -DCMAKE_TOOLCHAIN_FILE=/opencv/platforms/linux/riscv64-clang.toolchain.cmake -DBUILD_SHARED_LIBS=OFF -DWITH_OPENCL=OFF \ -DENABLE_RVV=ON \ # choose RVV flags in the toolchain -DCPU_BASELINE= \ # disable all intrinsics -DBUILD_opencv_dnn=OFF \ # know issue -DCMAKE_BUILD_TYPE=Release \ ../opencv

CMake output:

... -- CPU/HW features: -- Baseline: ... -- C++ flags (Release): -march=rv64gcv --gcc-toolchain=/chains/riscv-gcc-14.1.0 -w -fsigned-char -W -Wall -Wreturn-type -Wnon-virtual-dtor -Waddress -Wsequence-point -Wformat -Wformat-security -Wmissing-declarations -Wmissing-prototypes -Wstrict-prototypes -Wundef -Winit-self -Wpointer-arith -Wshadow -Wsign-promo -Wuninitialized -Winconsistent-missing-override -Wno-delete-non-virtual-dtor -Wno-unnamed-type-template-args -Wno-comment -Wno-deprecated-enum-enum-conversion -Wno-deprecated-anon-enum-enum-conversion -fdiagnostics-show-option -pthread -Qunused-arguments -ffunction-sections -fdata-sections -fvisibility=hidden -fvisibility-inlines-hidden -O3 -DNDEBUG -DNDEBUG ...

Generated cv_cpu_config.h:

// OpenCV CPU baseline features #define CV_CPU_BASELINE_FEATURES 0 \ // OpenCV supported CPU dispatched features #define CV_CPU_DISPATCH_FEATURES 0 \

If we don't change CPU_BASELINE (leave it DETECT), then OpenCV intrinsics will be enabled, cv_cpu_config.h:

// OpenCV CPU baseline features #define CV_CPU_COMPILE_RVV 1 #define CV_CPU_BASELINE_COMPILE_RVV 1 #define CV_CPU_BASELINE_FEATURES 0 \ , CV_CPU_RVV \ // OpenCV supported CPU dispatched features #define CV_CPU_DISPATCH_FEATURES 0 \

Lets remove set(CPU_BASELINE "DETECT").
Warning message is enough.

opencv-alalek · 2024-09-06T07:06:22Z

cmake/OpenCVCompilerOptimizations.cmake

-    ocv_update(CPU_FP16_IMPLIES "NEON")
-    ocv_update(CPU_NEON_DOTPROD_IMPLIES "NEON")
-    ocv_update(CPU_NEON_FP16_IMPLIES "NEON")
-    ocv_update(CPU_NEON_BF16_IMPLIES "NEON")


Why do we lost _IMPLIES configuration?

I had concerns that it might affect compilation flags for dispatched or baseline files. I'll try to restore it.

opencv-alalek · 2024-09-06T07:09:22Z

CMakeLists.txt

+# Use same flags for native AArch64 and RISC-V compilation as for cross-compile (Linux)
+if((CV_GCC OR CV_CLANG) AND UNIX AND NOT APPLE AND NOT CMAKE_CROSSCOMPILING AND NOT CMAKE_TOOLCHAIN_FILE)
+  if(CMAKE_SYSTEM_PROCESSOR STREQUAL "aarch64") # Maybe use AARCH64 variable?
+    include(${CMAKE_CURRENT_LIST_DIR}/platforms/linux/flags-aarch64.cmake)


There is already something for platforms: https://github.com/opencv/opencv/tree/4.x/cmake/platforms
We could add similar for processors.

Perhaps we can move this specific block to Linux.cmake if it has all used variables being set at the time of importing (e.g. CMAKE_CROSSCOMPILING). I'll try it.

opencv-alalek · 2024-09-06T07:15:31Z

platforms/linux/flags-aarch64.cmake

+if(ENABLE_BF16)
+  set(OCV_FLAGS "-march=armv8.6-a")
+elseif(ENABLE_FP16 OR ENABLE_DOTPROD)
+  set(OCV_FLAGS "-march=armv8.4-a")


Google uses -march=armv8.2-a+bf16 for dispatched code:

https://github.com/google/XNNPACK/blob/f416ab3d2781c8eb53eaa999239138296146b5e0/CMakeLists.txt#L836

Why do we need 8.4?

I used this table from GCC documentation to establish baselines with assumption that actual hardware also lines up with it and there are no platforms which have dotprod on top of armv8.2-a, plus an assumption that compiler can optimize code better for such "baseline" arch.

arch value Architecture Includes by default ‘armv8-a’ Armv8-A ‘+fp’, ‘+simd’ ‘armv8.1-a’ Armv8.1-A ‘armv8-a’, ‘+crc’, ‘+lse’, ‘+rdma’ ‘armv8.2-a’ Armv8.2-A ‘armv8.1-a’ ‘armv8.3-a’ Armv8.3-A ‘armv8.2-a’, ‘+pauth’ ‘armv8.4-a’ Armv8.4-A ‘armv8.3-a’, ‘+flagm’, ‘+fp16fml’, ‘+dotprod’ ‘armv8.5-a’ Armv8.5-A ‘armv8.4-a’, ‘+sb’, ‘+ssbs’, ‘+predres’ ‘armv8.6-a’ Armv8.6-A ‘armv8.5-a’, ‘+bf16’, ‘+i8mm’

Should I change it back to armv8.2-a+...?

Changed it to use armv8.2-a+... combination with feature flags. It became slightly more complicated, but I believe it's OK. Please let me know if we need to revert it.

Also added to the toolchain ability to disable NEON for AArch64 by explicitly setting ENABLE_NEON to OFF.

opencv-alalek · 2024-09-06T07:20:43Z

CMakeLists.txt

+# Use same flags for native AArch64 and RISC-V compilation as for cross-compile (Linux)
+if((CV_GCC OR CV_CLANG) AND UNIX AND NOT APPLE AND NOT CMAKE_CROSSCOMPILING AND NOT CMAKE_TOOLCHAIN_FILE)
+  if(CMAKE_SYSTEM_PROCESSOR STREQUAL "aarch64") # Maybe use AARCH64 variable?
+    include(${CMAKE_CURRENT_LIST_DIR}/platforms/linux/flags-aarch64.cmake)


platforms/linux

OSX/iOS?
android?
other OS?

We should not depend on "linux" here.

This block's purpose is to use the same flags for native Linux compilation as for cross-compilation with our toolchain files.

It is not applicable to Android, because it uses own toolchain files from NDK and doesn't have native compilation (or does it?).

Also not applicable to OSX/iOS because we rely on CMake/XCode to set platform flags for specific target.

Not so sure about Windows, but it was not handled specifically by OpenCVCompilerOptimizations.cmake (we have only GCC/Clang flags there for AArch64).

Other platforms are not officially supported by us and I think we should recommend users to use there own cmake-toolchain files for these cases.

mshabunin · 2024-09-06T14:02:58Z

Should I move required cmake version raise to 3.7 together with CMAKE_..._FLAGS_INIT usage in toolchain files to a separate PR?

asmorkalov · 2024-09-10T10:50:38Z

I think we can stay with CMake 3.7 as minimal requirement. Ubuntu 18.04 provides 3.10. Older distributions may provide older versions, but it's easy to update.

opencv-alalek

Purpose of this PR is declared as support for various user-defined compiler flags.
But current version contains several restrictions on that.

opencv-alalek · 2024-09-10T13:00:57Z

cmake/OpenCVCompilerOptimizations.cmake

+    # ok
+  elseif(NOT CPU_BASELINE STREQUAL "DETECT")
+    message(WARNING "Platform ${CMAKE_SYSTEM_PROCESSOR} only supports CPU_BASELINE=DETECT|NATIVE, use CMAKE_CXX_FLAGS or cmake toolchain file options to modify compiler options")
+    set(CPU_BASELINE "DETECT")


Just "empty" handling is not enough.

We should not block user to disable some OpenCV intrinsics, e.g. for debug/testing purposes. Even if they are "enabled in compiler".

opencv-alalek · 2024-09-10T13:03:27Z

CMakeLists.txt

@@ -684,6 +680,19 @@ if(NOT IOS AND NOT XROS)
  include(cmake/OpenCVDetectPython.cmake)
 endif()

+# Use same flags for native AArch64 and RISC-V compilation as for cross-compile (Linux)
+if((CV_GCC OR CV_CLANG) AND UNIX AND NOT APPLE AND NOT CMAKE_CROSSCOMPILING AND NOT CMAKE_TOOLCHAIN_FILE)


Lets move out that from the root CMake file.

Moved to cmake/platforms/OpenCV-Linux.cmake

…ve compilation

…nd native compilation

opencv-alalek · 2024-09-12T06:45:40Z

cmake/platforms/OpenCV-Linux.cmake

@@ -1 +1,10 @@
 # empty


Lets remove this comment as file is not "intentionally empty" anymore.

RISC-V/AArch64: disable CPU features detection opencv#25901 This PR is the first step in fixing current issues with NEON/RVV, FP16, BF16 and other CPU features on AArch64 and RISC-V platforms. On AArch64 and RISC-V platforms we usually have the platform set by default in the toolchain when we compile it or in the cmake toolchain file or in CMAKE_CXX_FLAGS by user. Then, there are two ways to set platform options: a) "-mcpu=<some_cpu>" ; b) "-march=<arch description>" (e.g. "rv64gcv"). Furthermore, there are no similar "levels" of optimizations as for x86_64, instead we have features (RVV, FP16,...) which can be enabled or disabled. So, for example, if a user has "rv64gc" set by the toolchain and we want to enable RVV. Then we need to somehow parse their current feature set and append "v" (vector optimizations) to this string. This task is quite hard and the whole procedure is prone to errors. I propose to use "CPU_BASELINE=DETECT" by default on AArch64 and RISC-V platforms. And somehow remove other features or make them read-only/detect-only, so that OpenCV wouldn't add any extra "-march" flags to the default configuration. We would rely only on the flags provided by the compiler and cmake toolchain file. We can have some predefined configurations in our cmake toolchain files. Changes made by this PR: - `CMakeLists.txt`: - use `CMAKE_CROSSCOMPILING` instead of `CMAKE_TOOLCHAIN_FILE` to detect cross-compilation. This might be useful in cases of native compilation with a toolchain file - removed obsolete variables `ENABLE_NEON` and `ENABLE_VFPV3`, the first one have been turned ON by default on AArch64 platform which caused setting `CPU_BASELINE=NEON` - raise minimum cmake version allowed to 3.7 to allow using `CMAKE_CXX_FLAGS_INIT` in toolchain files - added separate files with arch flags for native compilation on AArch64 and RISC-V, these files will be used in our toolchain files and in regular cmake - use `DETECT` as default value for `CPU_BASELINE` also allow `NATIVE`, warn user if other values were used (only for AArch64 and RISC-V) - for each feature listed in `CPU_DISPATCH` check if corresponding `CPU_${opt}_FLAGS_ON` has been provided, warn user if it is empty (only for AArch64 and RISC-V) - use `CPU_BASELINE_DISABLE` variable to actually turn off macros responsible for corresponding features even if they are enabled by compiler - removed Aarch64 feature merge procedure (it didn't support `-mcpu` and built-in `-march`) - reworked AArch64 and two RISC-V cmake toolchain files (does not affect Android/OSX/iOS/Win): - use `CMAKE_CXX_FLAGS_INIT` to set compiler flags - use variables `ENABLE_BF16`, `ENABLE_DOTPROD`, `ENABLE_RVV`, `ENABLE_FP16` to control `-march` - AArch64: removed other compiler and linker flags - `-fdata-sections`, `-fsigned-char`, `-Wl,--no-undefined`, `-Wl,--gc-sections` - already set by OpenCV - `-Wa,--noexecstack`, `-Wl,-z,noexecstack`, `-Wl,-z,relro`, `-Wl,-z,now` - can be enabled by OpenCV via `ENABLE_HARDENING` - `-Wno-psabi` - this option used to disable some warnings on older ARM platforms, shouldn't harm - ARM: removed same common flags as for AArch64, but left `-mthumb` and `--fix-cortex-a8`, `-z nocopyreloc`

opencv-alalek reviewed Jul 18, 2024

View reviewed changes

mshabunin force-pushed the fix-riscv-aarch-baseline branch 2 times, most recently from cf9abe2 to dd797be Compare July 19, 2024 08:46

opencv-alalek reviewed Aug 2, 2024

View reviewed changes

mshabunin force-pushed the fix-riscv-aarch-baseline branch from 9e9783a to d96068e Compare August 2, 2024 18:07

opencv-alalek reviewed Aug 3, 2024

View reviewed changes

mshabunin force-pushed the fix-riscv-aarch-baseline branch from f5b0682 to 025dfc4 Compare August 13, 2024 15:14

mshabunin marked this pull request as ready for review August 29, 2024 11:36

mshabunin mentioned this pull request Sep 2, 2024

RISC-V: fix XuanTie and Andes builds #26100

Merged

asmorkalov added category: build/install platform: arm ARM boards related issues: RPi, NVIDIA TK/TX, etc platform: riscv labels Sep 6, 2024

asmorkalov added this to the 4.11.0 milestone Sep 6, 2024

opencv-alalek reviewed Sep 6, 2024

View reviewed changes

opencv-alalek reviewed Sep 10, 2024

View reviewed changes

mshabunin added 13 commits September 10, 2024 19:40

RISC-V/AArch64: disable CPU features detection

0d88889

build: raise minimum required cmake version

1a05f4c

Allow NATIVE baseline, minor fixes in DNN

d2cbef0

restore dispatch for aarch64, share base flags between cross and nati…

bee9df7

…ve compilation

fixup! restore dispatch for aarch64, share base flags between cross a…

641a238

…nd native compilation

...also check toolchain file being set

2f02a18

use separate variable

ddc60db

minor changes

4817ce0

support empty CPU_BASELINE

12b1c5b

restored implies

c7c677d

use combined flags for aarch64

a49b5ca

fix extra EOL

137cde8

Use function for extra flags

4bfbcb6

mshabunin force-pushed the fix-riscv-aarch-baseline branch from 7073af3 to 4bfbcb6 Compare September 11, 2024 09:38

Fix native Linxu compiler issue

7b17010

opencv-alalek reviewed Sep 12, 2024

View reviewed changes

mshabunin added 2 commits September 12, 2024 12:04

don't force DETECT baseline, support nosimd for AArch64, minor changes

e39ffe6

simplify flags function, prepend flags for native compilation

b4bc239

opencv-alalek approved these changes Sep 12, 2024

View reviewed changes

asmorkalov assigned opencv-alalek Sep 12, 2024

asmorkalov merged commit 4c81e17 into opencv:4.x Sep 12, 2024
28 of 30 checks passed

mshabunin deleted the fix-riscv-aarch-baseline branch September 12, 2024 17:44

asmorkalov mentioned this pull request Sep 20, 2024

5.x merge 4.x #26170

Merged

mshabunin mentioned this pull request Nov 18, 2024

ARMv8 CPU features management is broken for some cases #24588

Closed

4 tasks

Uh oh!

RISC-V/AArch64: disable CPU features detection #25901

RISC-V/AArch64: disable CPU features detection #25901

Uh oh!

Conversation

mshabunin commented Jul 12, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

This comment was marked as spam.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mshabunin Jul 18, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

opencv-alalek Aug 2, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mshabunin Sep 6, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

mshabunin commented Jul 12, 2024 •

edited

Loading

mshabunin Jul 18, 2024 •

edited

Loading

opencv-alalek Aug 2, 2024 •

edited

Loading

mshabunin Sep 6, 2024 •

edited

Loading