diff options
Diffstat (limited to 'docs/user_guide/how_to_build_and_run_examples.dox')
| -rw-r--r-- | docs/user_guide/how_to_build_and_run_examples.dox | 508 |
1 files changed, 268 insertions, 240 deletions
diff --git a/docs/user_guide/how_to_build_and_run_examples.dox b/docs/user_guide/how_to_build_and_run_examples.dox index 1766199eb4..0b8a23b368 100644 --- a/docs/user_guide/how_to_build_and_run_examples.dox +++ b/docs/user_guide/how_to_build_and_run_examples.dox @@ -1,5 +1,5 @@ /// -/// Copyright (c) 2017-2021 Arm Limited. +/// Copyright (c) 2017-2024 Arm Limited. /// /// SPDX-License-Identifier: MIT /// @@ -30,203 +30,7 @@ namespace arm_compute @section S1_1_build_options Build options scons 2.3 or above is required to build the library. -To see the build options available simply run ```scons -h```: - - debug: Debug (yes|no) - default: False - - asserts: Enable asserts (this flag is forced to 1 for debug=1) (yes|no) - default: False - - logging: Logging (this flag is forced to 1 for debug=1) (yes|no) - default: False - - arch: Target Architecture (armv7a|arm64-v8a|arm64-v8.2-a|arm64-v8.2-a-sve|arm64-v8.2-a-sve2|x86_32|x86_64|armv8a|armv8.2-a|armv8.2-a-sve|armv8.6-a|armv8.6-a-sve|armv8.6-a-sve2|armv8r64|x86) - default: armv7a - - estate: Execution State (auto|32|64) - default: auto - - os: Target OS (linux|android|macos|tizen|bare_metal) - default: linux - - build: Build type (native|cross_compile|embed_only) - default: cross_compile - - examples: Build example programs (yes|no) - default: True - - gemm_tuner: Build gemm_tuner programs (yes|no) - default: True - - Werror: Enable/disable the -Werror compilation flag (yes|no) - default: True - - standalone: Builds the tests as standalone executables, links statically with libgcc, libstdc++ and libarm_compute (yes|no) - default: False - - opencl: Enable OpenCL support (yes|no) - default: True - - neon: Enable Arm® Neon™ support (yes|no) - default: False - - embed_kernels: Embed OpenCL kernels in library binary (yes|no) - default: True - - compress_kernels: Compress embedded OpenCL kernels in library binary. Note embed_kernels should be enabled as well (yes|no) - default: False - - set_soname: Set the library's soname and shlibversion (requires SCons 2.4 or above) (yes|no) - default: False - - openmp: Enable OpenMP backend (yes|no) - default: False - - cppthreads: Enable C++11 threads backend (yes|no) - default: True - - build_dir: Specify sub-folder for the build ( /path/to/build_dir ) - default: . - - install_dir: Specify sub-folder for the install ( /path/to/install_dir ) - default: - - exceptions: Enable/disable C++ exception support (yes|no) - default: True - - linker_script: Use an external linker script ( /path/to/linker_script ) - default: - - custom_options: Custom options that can be used to turn on/off features - (all|none|comma-separated list of names) - allowed names: disable_mmla_fp - default: none - - data_type_support: Enable a list of data types to support - (all|none|comma-separated list of names) - allowed names: qasymm8 qasymm8_signed qsymm16 fp16 fp32 - default: all - - toolchain_prefix: Override the toolchain prefix - default: - - compiler_prefix: Override the compiler prefix - default: - - extra_cxx_flags: Extra CXX flags to be appended to the build command - default: - - extra_link_flags: Extra LD flags to be appended to the build command - default: - - compiler_cache: Command to prefix to the C and C++ compiler (e.g ccache) - default: - - specs_file: Specs file to use - default: rdimon.specs - - benchmark_examples: Build benchmark examples programs (yes|no) - default: False - - validate_examples: Build validate examples programs (yes|no) - default: False - - reference_openmp: Build reference validation with openmp (yes|no) - default: True - - validation_tests: Build validation test programs (yes|no) - default: False - - benchmark_tests: Build benchmark test programs (yes|no) - default: False - - test_filter: Pattern to specify the tests' filenames to be compiled - default: *.cpp - - pmu: Enable PMU counters (yes|no) - default: False - - mali: Enable Arm® Mali™ hardware counters (yes|no) - default: False - - external_tests_dir: Add examples, benchmarks and tests to the tests suite from an external path ( /path/to/external_tests_dir ) - default: - -@b debug / @b asserts: - - With debug=1 asserts are enabled, and the library is built with symbols and no optimisations enabled. - - With debug=0 and asserts=1: Optimisations are enabled and symbols are removed, however all the asserts are still present (This is about 20% slower than the release build) - - With debug=0 and asserts=0: All optimisations are enable and no validation is performed, if the application misuses the library it is likely to result in a crash. (Only use this mode once you are sure your application is working as expected). - -@b arch: The x86_32 and x86_64 targets can only be used with neon=0 and opencl=1. - -@b os: Choose the operating system you are targeting: Linux, Android or bare metal. -@note bare metal can only be used for Arm® Neon™ (not OpenCL), only static libraries get built and Neon™'s multi-threading support is disabled. - -@b build: you can either build directly on your device (native) or cross compile from your desktop machine (cross-compile). In both cases make sure the compiler is available in your path. - -@note If you want to natively compile for 32bit on a 64bit Arm device running a 64bit OS then you will have to use cross-compile too. - -There is also an 'embed_only' option which will generate all the .embed files for the OpenCL kernels. This might be useful if using a different build system to compile the library. - -In addition the option 'compress_kernels' will compress the embedded OpenCL kernel files using zlib and inject them in the library. This is useful for reducing the binary size. Note, this option is only available for Android when 'embed_kernels' is enabled. - -@b Werror: If you are compiling using the same toolchains as the ones used in this guide then there shouldn't be any warning and therefore you should be able to keep Werror=1. If with a different compiler version the library fails to build because of warnings interpreted as errors then, if you are sure the warnings are not important, you might want to try to build with Werror=0 (But please do report the issue on Github). - -@b opencl / @b neon: Choose which SIMD technology you want to target. (Neon™ for Arm® Cortex®-A CPUs or OpenCL for Arm® Mali™ GPUs) - -@b embed_kernels: For OpenCL only: set embed_kernels=1 if you want the OpenCL kernels to be built in the library's binaries instead of being read from separate ".cl" / ".cs" files. If embed_kernels is set to 0 then the application can set the path to the folder containing the OpenCL kernel files by calling CLKernelLibrary::init(). By default the path is set to "./cl_kernels". - -@b set_soname: Do you want to build the versioned version of the library ? - -If enabled the library will contain a SONAME and SHLIBVERSION and some symlinks will automatically be created between the objects. -Example: - libarm_compute_core.so -> libarm_compute_core.so.1.0.0 - libarm_compute_core.so.1 -> libarm_compute_core.so.1.0.0 - libarm_compute_core.so.1.0.0 - -@note This options is disabled by default as it requires SCons version 2.4 or above. - -@b extra_cxx_flags: Custom CXX flags which will be appended to the end of the build command. - -@b build_dir: Build the library in a subfolder of the "build" folder. (Allows to build several configurations in parallel). - -@b examples: Build or not the examples - -@b validation_tests: Enable the build of the validation suite. - -@b benchmark_tests: Enable the build of the benchmark tests - -@b pmu: Enable the PMU cycle counter to measure execution time in benchmark tests. (Your device needs to support it) - -@b mali: Enable the collection of Arm® Mali™ hardware counters to measure execution time in benchmark tests. (Your device needs to have a Arm® Mali™ driver that supports it) - -@b openmp Build in the OpenMP scheduler for Neon™. - -@note Only works when building with g++ not clang++ - -@b cppthreads Build in the C++11 scheduler for Neon™. - -@sa Scheduler::set - -@b external_tests_dir Add examples, benchmarks and tests to the tests suite from an external path ( /path/to/external_tests_dir ) - -In order to use this option, the external tests directory must have the following structure: - - EXTERNAL_TESTS_DIR: - └── tests - ├── benchmark - │ ├── CL - │ ├── datasets - │ ├── fixtures - │ └── Neon - └── validation - ├── CL - ├── datasets - ├── fixtures - └── Neon - -Then, build the library with `external_tests_dir=<PATH_TO_EXTERNAL_TESTS_DIR>`. +To see the build options available simply run ```scons -h``` @section S1_2_linux Building for Linux @@ -243,11 +47,11 @@ To cross-compile the library in debug mode, with Arm® Neon™ only support, for To cross-compile the library in asserts mode, with OpenCL only support, for Linux 64bit: - scons Werror=1 -j8 debug=0 asserts=1 neon=0 opencl=1 embed_kernels=1 os=linux arch=arm64-v8a + scons Werror=1 -j8 debug=0 asserts=1 neon=0 opencl=1 embed_kernels=1 os=linux arch=armv8a You can also compile the library natively on an Arm device by using <b>build=native</b>: - scons Werror=1 -j8 debug=0 neon=1 opencl=0 os=linux arch=arm64-v8a build=native + scons Werror=1 -j8 debug=0 neon=1 opencl=0 os=linux arch=armv8a build=native scons Werror=1 -j8 debug=0 neon=1 opencl=0 os=linux arch=armv7a build=native @note g++ for Arm is mono-arch, therefore if you want to compile for Linux 32bit on a Linux 64bit platform you will have to use a cross compiler. @@ -272,21 +76,21 @@ The examples get automatically built by scons as part of the build process of th To cross compile a Arm® Neon™ example for Linux 32bit: - arm-linux-gnueabihf-g++ examples/neon_cnn.cpp utils/Utils.cpp -I. -Iinclude -std=c++14 -mfpu=neon -L. -larm_compute -larm_compute_core -o neon_cnn + arm-linux-gnueabihf-g++ examples/neon_cnn.cpp utils/Utils.cpp -I. -Iinclude -std=c++14 -mfpu=neon -L. -larm_compute -o neon_cnn To cross compile a Arm® Neon™ example for Linux 64bit: - aarch64-linux-gnu-g++ examples/neon_cnn.cpp utils/Utils.cpp -I. -Iinclude -std=c++14 -L. -larm_compute -larm_compute_core -o neon_cnn + aarch64-linux-gnu-g++ examples/neon_cnn.cpp utils/Utils.cpp -I. -Iinclude -std=c++14 -L. -larm_compute -o neon_cnn (notice the only difference with the 32 bit command is that we don't need the -mfpu option and the compiler's name is different) To cross compile an OpenCL example for Linux 32bit: - arm-linux-gnueabihf-g++ examples/cl_sgemm.cpp utils/Utils.cpp -I. -Iinclude -std=c++14 -mfpu=neon -L. -larm_compute -larm_compute_core -o cl_sgemm -DARM_COMPUTE_CL + arm-linux-gnueabihf-g++ examples/cl_sgemm.cpp utils/Utils.cpp -I. -Iinclude -std=c++14 -mfpu=neon -L. -larm_compute -o cl_sgemm -DARM_COMPUTE_CL To cross compile an OpenCL example for Linux 64bit: - aarch64-linux-gnu-g++ examples/cl_sgemm.cpp utils/Utils.cpp -I. -Iinclude -std=c++14 -L. -larm_compute -larm_compute_core -o cl_sgemm -DARM_COMPUTE_CL + aarch64-linux-gnu-g++ examples/cl_sgemm.cpp utils/Utils.cpp -I. -Iinclude -std=c++14 -L. -larm_compute -o cl_sgemm -DARM_COMPUTE_CL (notice the only difference with the 32 bit command is that we don't need the -mfpu option and the compiler's name is different) @@ -294,45 +98,45 @@ To cross compile the examples with the Graph API, such as graph_lenet.cpp, you n i.e. to cross compile the "graph_lenet" example for Linux 32bit: - arm-linux-gnueabihf-g++ examples/graph_lenet.cpp utils/Utils.cpp utils/GraphUtils.cpp utils/CommonGraphOptions.cpp -I. -Iinclude -std=c++14 -mfpu=neon -L. -larm_compute_graph -larm_compute -larm_compute_core -Wl,--allow-shlib-undefined -o graph_lenet + arm-linux-gnueabihf-g++ examples/graph_lenet.cpp utils/Utils.cpp utils/GraphUtils.cpp utils/CommonGraphOptions.cpp -I. -Iinclude -std=c++14 -mfpu=neon -L. -larm_compute_graph -larm_compute -Wl,--allow-shlib-undefined -o graph_lenet i.e. to cross compile the "graph_lenet" example for Linux 64bit: - aarch64-linux-gnu-g++ examples/graph_lenet.cpp utils/Utils.cpp utils/GraphUtils.cpp utils/CommonGraphOptions.cpp -I. -Iinclude -std=c++14 -L. -larm_compute_graph -larm_compute -larm_compute_core -Wl,--allow-shlib-undefined -o graph_lenet + aarch64-linux-gnu-g++ examples/graph_lenet.cpp utils/Utils.cpp utils/GraphUtils.cpp utils/CommonGraphOptions.cpp -I. -Iinclude -std=c++14 -L. -larm_compute_graph -larm_compute -Wl,--allow-shlib-undefined -o graph_lenet (notice the only difference with the 32 bit command is that we don't need the -mfpu option and the compiler's name is different) -@note If compiling using static libraries, this order must be followed when linking: arm_compute_graph_static, arm_compute, arm_compute_core +@note If compiling using static libraries, this order must be followed when linking: arm_compute_graph_static, arm_compute To compile natively (i.e directly on an Arm device) for Arm® Neon™ for Linux 32bit: - g++ examples/neon_cnn.cpp utils/Utils.cpp -I. -Iinclude -std=c++14 -mfpu=neon -larm_compute -larm_compute_core -o neon_cnn + g++ examples/neon_cnn.cpp utils/Utils.cpp -I. -Iinclude -std=c++14 -mfpu=neon -larm_compute -o neon_cnn To compile natively (i.e directly on an Arm device) for Arm® Neon™ for Linux 64bit: - g++ examples/neon_cnn.cpp utils/Utils.cpp -I. -Iinclude -std=c++14 -larm_compute -larm_compute_core -o neon_cnn + g++ examples/neon_cnn.cpp utils/Utils.cpp -I. -Iinclude -std=c++14 -larm_compute -o neon_cnn (notice the only difference with the 32 bit command is that we don't need the -mfpu option) To compile natively (i.e directly on an Arm device) for OpenCL for Linux 32bit or Linux 64bit: - g++ examples/cl_sgemm.cpp utils/Utils.cpp -I. -Iinclude -std=c++14 -larm_compute -larm_compute_core -o cl_sgemm -DARM_COMPUTE_CL + g++ examples/cl_sgemm.cpp utils/Utils.cpp -I. -Iinclude -std=c++14 -larm_compute -o cl_sgemm -DARM_COMPUTE_CL To compile natively the examples with the Graph API, such as graph_lenet.cpp, you need to link the examples against arm_compute_graph.so too. i.e. to natively compile the "graph_lenet" example for Linux 32bit: - g++ examples/graph_lenet.cpp utils/Utils.cpp utils/GraphUtils.cpp utils/CommonGraphOptions.cpp -I. -Iinclude -std=c++14 -mfpu=neon -L. -larm_compute_graph -larm_compute -larm_compute_core -Wl,--allow-shlib-undefined -o graph_lenet + g++ examples/graph_lenet.cpp utils/Utils.cpp utils/GraphUtils.cpp utils/CommonGraphOptions.cpp -I. -Iinclude -std=c++14 -mfpu=neon -L. -larm_compute_graph -larm_compute -Wl,--allow-shlib-undefined -o graph_lenet i.e. to natively compile the "graph_lenet" example for Linux 64bit: - g++ examples/graph_lenet.cpp utils/Utils.cpp utils/GraphUtils.cpp utils/CommonGraphOptions.cpp -I. -Iinclude -std=c++14 -L. -larm_compute_graph -larm_compute -larm_compute_core -Wl,--allow-shlib-undefined -o graph_lenet + g++ examples/graph_lenet.cpp utils/Utils.cpp utils/GraphUtils.cpp utils/CommonGraphOptions.cpp -I. -Iinclude -std=c++14 -L. -larm_compute_graph -larm_compute -Wl,--allow-shlib-undefined -o graph_lenet (notice the only difference with the 32 bit command is that we don't need the -mfpu option) -@note If compiling using static libraries, this order must be followed when linking: arm_compute_graph_static, arm_compute, arm_compute_core +@note If compiling using static libraries, this order must be followed when linking: arm_compute_graph_static, arm_compute -@note These two commands assume libarm_compute.so is available in your library path, if not add the path to it using -L (e.g. -Llib/linux-arm64-v8a-neon-cl-asserts/) +@note These two commands assume libarm_compute.so is available in your library path, if not add the path to it using -L (e.g. -Llib/linux-armv8a-neon-cl-asserts/) @note You might need to export the path to OpenCL library as well in your LD_LIBRARY_PATH if Compute Library was built with OpenCL enabled. To run the built executable simply run: @@ -362,27 +166,79 @@ In order to build for SVE or SVE2 you need a compiler that supports them. You ca An example build command with SVE is: - scons arch=arm64-v8.2-a-sve os=linux build_dir=arm64 -j55 standalone=0 opencl=0 openmp=0 validation_tests=1 neon=1 cppthreads=1 toolchain_prefix=aarch64-none-linux-gnu- + scons arch=armv8.2-a-sve os=linux build_dir=arm64 -j55 standalone=0 opencl=0 openmp=0 validation_tests=1 neon=1 cppthreads=1 toolchain_prefix=aarch64-none-linux-gnu- + +@subsection S1_2_4_sme Build for SME2 + +In order to build for SME2 you need to use a compiler that supports SVE2 and enable SVE2 in the build as well. + +@note You the need to indicate the toolchains using the scons "toolchain_prefix" parameter. + +An example build command with SME2 is: + + scons arch=armv8.6-a-sve2-sme2 os=linux build_dir=arm64 -j55 standalone=0 opencl=0 openmp=0 validation_tests=1 neon=1 cppthreads=1 toolchain_prefix=aarch64-none-linux-gnu- + +@subsection S1_2_5_clang_build_linux Building with LLVM+Clang Natively on Linux + +The library can be built with LLVM+Clang by specifying CC and CXX environment variables appropriately as below. The **minimum** supported clang version is 11, as LLVM 11 introduces SVE/SVE2 VLA intrinsics: https://developer.arm.com/Tools%20and%20Software/LLVM%20Toolchain#Supported-Devices. + + CC=clang CXX=clang++ <build command> + +Or, if the environment has multiple clang versions: + + CC=clang-16 CXX=clang++-16 + +Examples for different build tools look like below. + +(experimental) CMake: + + mkdir build + cd build + CC=clang CXX=clang++ cmake .. -DCMAKE_BUILD_TYPE=Release -DARM_COMPUTE_OPENMP=1 -DARM_COMPUTE_WERROR=0 -DARM_COMPUTE_BUILD_EXAMPLES=1 -DARM_COMPUTE_BUILD_TESTING=1 -DCMAKE_INSTALL_LIBDIR=. + CC=clang CXX=clang++ cmake --build . -j32 + +(experimental) Bazel: + + CC=clang CXX=clang++ bazel build //... + +Scons: + + CC=clang CXX=clang++ scons -j32 Werror=1 debug=0 neon=1 openmp=1 cppthreads=1 os=linux arch=armv8a multi_isa=1 build=native validation_tests=1 + +Configurations supported are limited to the configurations supported by our CMake, Bazel and Multi ISA Scons builds. For more details on CMake and Bazel builds, please see @ref S1_8_experimental_builds @section S1_3_android Building for Android For Android, the library was successfully built and tested using Google's standalone toolchains: - - clang++ from NDK r18b for armv7a - - clang++ from NDK r20b for arm64-v8a - - clang++ from NDK r20b for arm64-v8.2-a with FP16 support + - clang++ from NDK r20b for armv8a + - clang++ from NDK r20b for armv8.2-a with FP16 support -For NDK r18 or older, here is a guide to <a href="https://developer.android.com/ndk/guides/standalone_toolchain.html">create your Android standalone toolchains from the NDK</a>: +(From 23.02, NDK >= r20b is highly recommended) For NDK r18 or older, here is a guide to <a href="https://developer.android.com/ndk/guides/standalone_toolchain.html">create your Android standalone toolchains from the NDK</a>: - Download the NDK r18b from here: https://developer.android.com/ndk/downloads/index.html to directory $NDK - Make sure you have Python 2.7 installed on your machine. - Generate the 32 and/or 64 toolchains by running the following commands to your toolchain directory $MY_TOOLCHAINS: $NDK/build/tools/make_standalone_toolchain.py --arch arm64 --install-dir $MY_TOOLCHAINS/aarch64-linux-android-ndk-r18b --stl libc++ --api 21 + $NDK/build/tools/make_standalone_toolchain.py --arch arm --install-dir $MY_TOOLCHAINS/arm-linux-android-ndk-r18b --stl libc++ --api 21 For NDK r19 or newer, you can directly <a href="https://developer.android.com/ndk/downloads">Download</a> the NDK package for your development platform, without the need to launch the make_standalone_toolchain.py script. You can find all the prebuilt binaries inside $NDK/toolchains/llvm/prebuilt/$OS_ARCH/bin/. -@attention the building script will look for a binary named "aarch64-linux-android-clang++", while the prebuilt binaries will have their API version as a suffix to their filename (e.g. "aarch64-linux-android21-clang++"). You should copy/rename the binary removing this suffix, or - alternatively - create an alias for it. +@parblock +@attention The building script will look for a binary named "aarch64-linux-android-clang++", while the prebuilt binaries will have their API version as a suffix to their filename (e.g. "aarch64-linux-android21-clang++"). You can instruct scons to use the correct version by using a combination of the toolchain_prefix and the "CC" "CXX" environment variables. +@attention For this particular example, you can specify: + + CC=clang CXX=clang++ scons toolchain_prefix=aarch64-linux-android21- + +@attention or: + + CC=aarch64-linux-android21-clang CXX=aarch64-linux-android21-clang++ scons toolchain_prefix="" + +@endparblock + +@parblock @attention We used to use gnustl but as of NDK r17 it is deprecated so we switched to libc++ +@endparblock @note Make sure to add the toolchains to your PATH: @@ -396,7 +252,7 @@ To cross-compile the library in debug mode, with Arm® Neon™ only support, for To cross-compile the library in asserts mode, with OpenCL only support, for Android 64bit: - CXX=clang++ CC=clang scons Werror=1 -j8 debug=0 asserts=1 neon=0 opencl=1 embed_kernels=1 os=android arch=arm64-v8a + CXX=clang++ CC=clang scons Werror=1 -j8 debug=0 asserts=1 neon=0 opencl=1 embed_kernels=1 os=android arch=armv8a @subsection S1_3_2_examples How to manually build the examples ? @@ -409,23 +265,23 @@ Once you've got your Android standalone toolchain built and added to your path y To cross compile a Arm® Neon™ example: #32 bit: - arm-linux-androideabi-clang++ examples/neon_cnn.cpp utils/Utils.cpp -I. -Iinclude -std=c++14 -larm_compute-static -larm_compute_core-static -L. -o neon_cnn_arm -static-libstdc++ -pie + arm-linux-androideabi-clang++ examples/neon_cnn.cpp utils/Utils.cpp -I. -Iinclude -std=c++14 -larm_compute-static -L. -o neon_cnn_arm -static-libstdc++ -pie #64 bit: - aarch64-linux-android-clang++ examples/neon_cnn.cpp utils/Utils.cpp -I. -Iinclude -std=c++14 -larm_compute-static -larm_compute_core-static -L. -o neon_cnn_aarch64 -static-libstdc++ -pie + aarch64-linux-android-clang++ examples/neon_cnn.cpp utils/Utils.cpp -I. -Iinclude -std=c++14 -larm_compute-static -L. -o neon_cnn_aarch64 -static-libstdc++ -pie To cross compile an OpenCL example: #32 bit: - arm-linux-androideabi-clang++ examples/cl_sgemm.cpp utils/Utils.cpp -I. -Iinclude -std=c++14 -larm_compute-static -larm_compute_core-static -L. -o cl_sgemm_arm -static-libstdc++ -pie -DARM_COMPUTE_CL + arm-linux-androideabi-clang++ examples/cl_sgemm.cpp utils/Utils.cpp -I. -Iinclude -std=c++14 -larm_compute-static -L. -o cl_sgemm_arm -static-libstdc++ -pie -DARM_COMPUTE_CL #64 bit: - aarch64-linux-android-clang++ examples/cl_sgemm.cpp utils/Utils.cpp -I. -Iinclude -std=c++14 -larm_compute-static -larm_compute_core-static -L. -o cl_sgemm_aarch64 -static-libstdc++ -pie -DARM_COMPUTE_CL + aarch64-linux-android-clang++ examples/cl_sgemm.cpp utils/Utils.cpp -I. -Iinclude -std=c++14 -larm_compute-static -L. -o cl_sgemm_aarch64 -static-libstdc++ -pie -DARM_COMPUTE_CL To cross compile the examples with the Graph API, such as graph_lenet.cpp, you need to link the library arm_compute_graph also. #32 bit: - arm-linux-androideabi-clang++ examples/graph_lenet.cpp utils/Utils.cpp utils/GraphUtils.cpp utils/CommonGraphOptions.cpp -I. -Iinclude -std=c++14 -Wl,--whole-archive -larm_compute_graph-static -Wl,--no-whole-archive -larm_compute-static -larm_compute_core-static -L. -o graph_lenet_arm -static-libstdc++ -pie -DARM_COMPUTE_CL + arm-linux-androideabi-clang++ examples/graph_lenet.cpp utils/Utils.cpp utils/GraphUtils.cpp utils/CommonGraphOptions.cpp -I. -Iinclude -std=c++14 -Wl,--whole-archive -larm_compute_graph-static -Wl,--no-whole-archive -larm_compute-static -L. -o graph_lenet_arm -static-libstdc++ -pie -DARM_COMPUTE_CL #64 bit: - aarch64-linux-android-clang++ examples/graph_lenet.cpp utils/Utils.cpp utils/GraphUtils.cpp utils/CommonGraphOptions.cpp -I. -Iinclude -std=c++14 -Wl,--whole-archive -larm_compute_graph-static -Wl,--no-whole-archive -larm_compute-static -larm_compute_core-static -L. -o graph_lenet_aarch64 -static-libstdc++ -pie -DARM_COMPUTE_CL + aarch64-linux-android-clang++ examples/graph_lenet.cpp utils/Utils.cpp utils/GraphUtils.cpp utils/CommonGraphOptions.cpp -I. -Iinclude -std=c++14 -Wl,--whole-archive -larm_compute_graph-static -Wl,--no-whole-archive -larm_compute-static -L. -o graph_lenet_aarch64 -static-libstdc++ -pie -DARM_COMPUTE_CL @note Due to some issues in older versions of the Arm® Mali™ OpenCL DDK (<= r13p0), we recommend to link arm_compute statically on Android. @note When linked statically the arm_compute_graph library currently needs the --whole-archive linker flag in order to work properly @@ -469,7 +325,7 @@ The library was successfully natively built for Apple Silicon under macOS 11.1 u To natively compile the library with accelerated CPU support: - scons Werror=1 -j8 neon=1 opencl=0 os=macos arch=arm64-v8a build=native + scons Werror=1 -j8 neon=1 opencl=0 os=macos arch=armv8a build=native @note Initial support disables feature discovery through HWCAPS and thread scheduling affinity controls @@ -477,40 +333,40 @@ To natively compile the library with accelerated CPU support: For bare metal, the library was successfully built using linaro's latest (gcc-linaro-6.3.1-2017.05) bare metal toolchains: - arm-eabi for armv7a - - aarch64-elf for arm64-v8a + - aarch64-elf for armv8a -Download linaro for <a href="https://releases.linaro.org/components/toolchain/binaries/6.3-2017.05/arm-eabi/">armv7a</a> and <a href="https://releases.linaro.org/components/toolchain/binaries/6.3-2017.05/aarch64-elf/">arm64-v8a</a>. +Download linaro for <a href="https://releases.linaro.org/components/toolchain/binaries/6.3-2017.05/arm-eabi/">armv7a</a> and <a href="https://releases.linaro.org/components/toolchain/binaries/6.3-2017.05/aarch64-elf/">armv8a</a>. @note Make sure to add the toolchains to your PATH: export PATH=$PATH:$MY_TOOLCHAINS/gcc-linaro-6.3.1-2017.05-x86_64_aarch64-elf/bin:$MY_TOOLCHAINS/gcc-linaro-6.3.1-2017.05-x86_64_arm-eabi/bin @subsection S1_5_1_library How to build the library ? -To cross-compile the library with Arm® Neon™ support for baremetal arm64-v8a: +To cross-compile the library with Arm® Neon™ support for baremetal armv8a: - scons Werror=1 -j8 debug=0 neon=1 opencl=0 os=bare_metal arch=arm64-v8a build=cross_compile cppthreads=0 openmp=0 standalone=1 + scons Werror=1 -j8 debug=0 neon=1 opencl=0 os=bare_metal arch=armv8a build=cross_compile cppthreads=0 openmp=0 standalone=1 @subsection S1_5_2_examples How to manually build the examples ? Examples are disabled when building for bare metal. If you want to build the examples you need to provide a custom bootcode depending on the target architecture and link against the compute library. More information about bare metal bootcode can be found <a href="http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dai0527a/index.html">here</a>. -@section S1_6_windows_host Building on a Windows host system +@section S1_6_windows_host Building on a Windows® host system (cross-compile) -Using `scons` directly from the Windows command line is known to cause +Using `scons` directly from the Windows® command line is known to cause problems. The reason seems to be that if `scons` is setup for cross-compilation -it gets confused about Windows style paths (using backslashes). Thus it is +it gets confused about Windows® style paths (using backslashes). Thus it is recommended to follow one of the options outlined below. -@subsection S1_6_1_ubuntu_on_windows Bash on Ubuntu on Windows +@subsection S1_6_1_ubuntu_on_windows Bash on Ubuntu on Windows® (cross-compile) The best and easiest option is to use -<a href="https://msdn.microsoft.com/en-gb/commandline/wsl/about">Ubuntu on Windows</a>. +<a href="https://msdn.microsoft.com/en-gb/commandline/wsl/about">Ubuntu on Windows®</a>. This feature is still marked as *beta* and thus might not be available. However, if it is building the library is as simple as opening a *Bash on -Ubuntu on Windows* shell and following the general guidelines given above. +Ubuntu on Windows®* shell and following the general guidelines given above. -@subsection S1_6_2_cygwin Cygwin +@subsection S1_6_2_cygwin Cygwin (cross-compile) -If the Windows subsystem for Linux is not available <a href="https://www.cygwin.com/">Cygwin</a> +If the Windows® subsystem for Linux is not available <a href="https://www.cygwin.com/">Cygwin</a> can be used to install and run `scons`, the minimum Cygwin version must be 3.0.7 or later. In addition to the default packages installed by Cygwin `scons` has to be selected in the installer. (`git` might also be useful but is not strictly required if you already have got the source @@ -521,6 +377,38 @@ compiler is included in the Android standalone toolchain. After everything has been set up in the Cygwin terminal the general guide on building the library can be followed. +@subsection S1_6_3_WoA Windows® on Arm™ (native build) + + Native builds on Windows® are experimental and some features from the library interacting with the OS are missing. + +It's possible to build Compute Library natively on a Windows® system running on Arm™. + +Windows® on Arm™ (WoA) systems provide compatibility emulating x86 binaries on aarch64. Unfortunately Visual Studio 2022 does not work on aarch64 systems because it's an x86_64bit application and these binaries cannot be exectuted on WoA yet. + +Because we cannot use Visual Studio to build Compute Library we have to set up a native standalone toolchain to compile C++ code for arm64 on Windows®. + +Native arm64 toolchain installation for WoA: +- LLVM+Clang-12 which can be downloaded from: https://github.com/llvm/llvm-project/releases/download/llvmorg-12.0.0/LLVM-12.0.0-woa64.exe +- Arm64 VC Runtime which can be downloaded from https://aka.ms/vs/17/release/vc_redist.arm64.exe + +- While full VS22 cannot be installed on WoA, we can install some components + -# Desktop development with C++ and all Arm64 components for Visual Studio, refer to: https://developer.arm.com/documentation/102528/0100/Install-Visual-Studio + -# VS22 build tools: https://visualstudio.microsoft.com/downloads/#build-tools-for-visual-studio-2022 + +There are some additional tools we need to install to build Compute Library: + +- git https://git-scm.com/download/win +- python 3 https://www.python.org/downloads/windows/ +- scons can be installed with pip install scons + +In order to use clang to build Windows® binaries natively we have to initialize the environment variables from VS22 correctly so that the compiler could find the arm64 C++ libraries. This can be done by pressing the key windows + r and running the command: + + cmd /k "C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\VC\Auxiliary\Build\vcvarsx86_arm64.bat" + +To build Compute Library type: + + scons opencl=0 neon=1 os=windows examples=0 validation_tests=1 benchmark_examples=0 build=native arch=armv8a Werror=0 exceptions=1 standalone=1 + @section S1_7_cl_requirements OpenCL DDK Requirements @subsection S1_7_1_cl_hard_requirements Hard Requirements @@ -537,5 +425,145 @@ OpenCL kernel level debugging can be simplified with the use of printf, this req SVM allocations are supported for all the underlying allocations in Compute Library. To enable this OpenCL 2.0 and above is a requirement. +@section S1_8_experimental_builds Experimental Bazel and CMake builds + +In addition to the scons build the repository includes experimental Bazel and CMake builds. +These builds currently support a limited range of options. Both are similar to the scons multi_isa build. It compiles all libraries with Neon (TM) support, as well as SVE and SVE2 libraries. The build is CPU only, not including OpenCL support. Only Linux environment is targeted for now. Both were successfully built with gcc / g++ version 10.2. + +@subsection S1_8_1_bazel_build Bazel build + +@subsubsection S1_8_1_1_file_structure File structure + +File structure for all files included in the Bazel build: + + . + ├── .bazelrc + ├── BUILD + ├── WORKSPACE + ├── arm_compute + │ └── BUILD + ├── examples + │ └── BUILD + ├── include + │ └── BUILD + ├── scripts + │ ├── print_version_file.py + │ └── BUILD + ├── src + │ └── BUILD + ├── support + │ └── BUILD + ├── tests + │ ├── BUILD + │ └── framework + │ └── BUILD + └── utils + └── BUILD + +@subsubsection S1_8_1_2_build_options Build options + +Available build options: + + - debug: Enable ['-O0','-g','-gdwarf-2'] compilation flags + - Werror: Enable -Werror compilation flag + - logging: Enable logging + - cppthreads: Enable C++11 threads backend + - openmp: Enable OpenMP backend + +@subsubsection S1_8_1_3_example_builds Example builds + +Build everything (libraries, examples, tests): + + bazel build //... + +Build libraries: + + bazel build //:all + +Build arm_compute only: + + bazel build //:arm_compute + +Build examples: + + bazel build //examples:all + +Build resnet50 example: + + bazel build //examples:graph_resnet50 + +Build validation and benchmarking: + + bazel build //tests:all + +@subsection S1_8_2_cmake_build CMake build + +@subsubsection S1_8_2_1_file_structure File structure + +File structure for all files included in the CMake build: + + . + ├── CMakeLists.txt + ├── cmake + │ ├── Options.cmake + │ ├── Version.cmake + │ └── toolchains + │ └── aarch64_linux_toolchain.cmake + ├── examples + │ └── CMakeLists.txt + ├── src + │ └── CMakeLists.txt + └── tests + ├── CMakeLists.txt + ├── benchmark + │ └── CMakeLists.txt + └── validation + └── CMakeLists.txt + +@subsubsection S1_8_2_2_build_options Build options + +Available build options: + + - CMAKE_BUILD_TYPE: "Release" (default) enables ['-O3', '-DNDEBUG'] compilation flags, "Debug" enables ['-O0','-g','-gdwarf-2', '-DARM_COMPUTE_ASSERTS_ENABLED'] + - ARM_COMPUTE_WERROR: Enable -Werror compilation flag + - ARM_COMPUTE_EXCEPTIONS: If disabled ARM_COMPUTE_EXCEPTIONS_DISABLED is enabled + - ARM_COMPUTE_LOGGING: Enable logging + - ARM_COMPUTE_BUILD_EXAMPLES: Build examples + - ARM_COMPUTE_BUILD_TESTING: Build tests + - ARM_COMPUTE_CPPTHREADS: Enable C++11 threads backend + - ARM_COMPUTE_OPENMP: Enable OpenMP backend + +@subsubsection S1_8_2_3_example_builds Example builds + +To build libraries, examples and tests: + + mkdir build + cd build + cmake .. -DCMAKE_BUILD_TYPE=Release -DARM_COMPUTE_OPENMP=1 -DARM_COMPUTE_WERROR=0 -DARM_COMPUTE_BUILD_EXAMPLES=1 -DARM_COMPUTE_BUILD_TESTING=1 -DCMAKE_INSTALL_LIBDIR=. + cmake --build . -j32 + +@section S1_9_fixed_format Building with support for fixed format kernels + +@subsection S1_9_1_intro_to_fixed_format_kernels What are fixed format kernels? + +The GEMM kernels used for convolutions and fully-connected layers in Compute Library employ memory layouts optimized for each kernel implementation. This then requires the supplied weights to be re-ordered into a buffer ready for consumption by the GEMM kernel. Where Compute Library is being called from a framework or library which implements operator caching, the re-ordering of the inputted weights into an intermediate buffer may no longer be desirable. When using a cached operator, the caller may wish to re-write the weights tensor, and re-run the operator using the updated weights. With the default GEMM kernels in Compute Library, the GEMM will be executed with the old weights, leading to incorrect results. + +To address this, Compute Library provides a set of GEMM kernels which use a common blocked memory format. These kernels consume the input weights directly from the weights buffer and do not execute an intermediate pre-transpose step. With this approach, it is the responsibility of the user (in this case the calling framework) to ensure that the weights are re-ordered into the required memory format. @ref NEGEMM::has_opt_impl is a static function that queries whether there exists fixed-format kernel, and if so will return in the expected weights format. The supported weight formats are enumerated in @ref arm_compute::WeightFormat. + +@subsection S1_9_2_building_fixed_format Building with fixed format kernels + +Fixed format kernels are only available for the CPU backend. To build Compute Library with fixed format kernels set fixed_format_kernels=1: + + scons Werror=1 debug=0 neon=1 opencl=0 embed_kernels=0 os=linux multi_isa=1 build=native cppthreads=1 openmp=0 fixed_format_kernels=1 + +@section S1_10_doxygen Building the Doxygen Documentation + +This documentation has been generated using the following shell command: + + $ ./scripts/generate_documentation.sh + +This requires Doxygen to be installed and available on your system. + */ + } // namespace arm_compute |