21.02
|
The Computer Vision and Machine Learning library is a set of functions optimised for both Arm CPUs and GPUs using SIMD technologies.Several builds of the library are available using various configurations:
Please create an issue on Github.
In order to facilitate the work of the support team please provide the build information of the library you are using. To get the version of the library you are using simply run:
$ strings android-armv7a-cl-asserts/libarm_compute.so | grep arm_compute_version arm_compute_version=v16.12 Build options: {'embed_kernels': '1', 'opencl': '1', 'arch': 'armv7a', 'neon': '0', 'asserts': '1', 'debug': '0', 'os': 'android', 'Werror': '1'} Git hash=f51a545d4ea12a9059fe4e598a092f1fd06dc858
For each release we provide some pre-built binaries of the library here
These binaries have been built using the following toolchains:
This archive contains:
For detailed information about file organization, please refer to Files -> File List section of this documentation.
All releases are numbered vYY.MM Where YY are the last two digits of the year, and MM the month number. If there is more than one release in a month then an extra sequential number is appended at the end:
v17.03 (First release of March 2017) v17.03.1 (Second release of March 2017) v17.04 (First release of April 2017)
v21.02 Public major release
v20.11 Public major release
v20.08 Public major release
v20.05 Public major release
v20.02.1 Maintenance release
v20.02 Public major release
v19.11.1 Public maintenance release
v19.11 Public major release
v19.08.1 Public maintenance release
v19.08 Public major release
v19.05 Public major release
v19.02 Public major release
v18.11 Public major release
v18.08 Public major release
v18.05 Public major release
v18.03 Public maintenance release
v18.02 Public major release
v18.01 Public maintenance release
v17.12 Public major release
v17.10 Public maintenance release
v17.09 Public major release
v17.06 Public major release
v17.05 Public bug fixes release
v17.04 Public bug fixes release
The following functions have been ported to use the new accurate padding:
v17.03.1 First Major public release of the sources
v17.03 Sources preview
v17.02.1 Sources preview
v17.02 Sources preview
v16.12 Binary preview release
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 Neon support (yes|no) default: False gles_compute: Enable OpenGL ES Compute Shader support (yes|no) default: False embed_kernels: Embed OpenCL kernels and OpenGL ES compute shaders 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 tracing: Enable runtime tracing (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: True validate_examples: Build validate examples programs (yes|no) default: True reference_openmp: Build reference validation with openmp (yes|no) default: True validation_tests: Build validation test programs (yes|no) default: True benchmark_tests: Build benchmark test programs (yes|no) default: True test_filter: Pattern to specify the tests' filenames to be compiled default: *.cpp pmu: Enable PMU counters (yes|no) default: False mali: Enable 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:
debug / asserts:
arch: The x86_32 and x86_64 targets can only be used with neon=0 and opencl=1.
os: Choose the operating system you are targeting: Linux, Android or bare metal.
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.
There is also an 'embed_only' option which will generate all the .embed files for the OpenCL kernels and / or OpenGLES compute shaders. This might be useful if using a different build system to compile the library.
In addittion 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.
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).
opencl / neon / gles_compute: Choose which SIMD technology you want to target. (Neon for Arm Cortex-A CPUs or OpenCL / GLES_COMPUTE for Arm Mali GPUs)
embed_kernels: For OpenCL / GLES_COMPUTE only: set embed_kernels=1 if you want the OpenCL / GLES_COMPUTE 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 / GLES_COMPUTE kernel files by calling CLKernelLibrary::init() / GCKernelLibrary::init(). By default the path is set to "./cl_kernels" / "./cs_shaders".
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
extra_cxx_flags: Custom CXX flags which will be appended to the end of the build command.
build_dir: Build the library in a subfolder of the "build" folder. (Allows to build several configurations in parallel).
examples: Build or not the examples
validation_tests: Enable the build of the validation suite.
benchmark_tests: Enable the build of the benchmark tests
pmu: Enable the PMU cycle counter to measure execution time in benchmark tests. (Your device needs to support it)
mali: Enable the collection of Mali hardware counters to measure execution time in benchmark tests. (Your device needs to have a Mali driver that supports it)
openmp Build in the OpenMP scheduler for Neon.
cppthreads Build in the C++11 scheduler for Neon.
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>
.
For Linux, the library was successfully built and tested using the following Linaro GCC toolchain:
To cross-compile the library in debug mode, with Neon only support, for Linux 32bit:
scons Werror=1 -j8 debug=1 neon=1 opencl=0 os=linux arch=armv7a
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
To cross-compile the library in asserts mode, with GLES_COMPUTE only support, for Linux 64bit:
scons Werror=1 -j8 debug=0 asserts=1 neon=0 opencl=0 gles_compute=1 embed_kernels=1 os=linux arch=arm64-v8a
You can also compile the library natively on an Arm device by using build=native:
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=armv7a build=native
For example on a 64bit Debian based system you would have to install g++-arm-linux-gnueabihf
apt-get install g++-arm-linux-gnueabihf
Then run
scons Werror=1 -j8 debug=0 neon=1 opencl=0 os=linux arch=armv7a build=cross_compile
or simply remove the build parameter as build=cross_compile is the default value:
scons Werror=1 -j8 debug=0 neon=1 opencl=0 os=linux arch=armv7a
The examples get automatically built by scons as part of the build process of the library described above. This section just describes how you can build and link your own application against our library.
To cross compile a Neon example for Linux 32bit:
arm-linux-gnueabihf-g++ examples/neon_convolution.cpp utils/Utils.cpp -I. -Iinclude -std=c++14 -mfpu=neon -L. -larm_compute -larm_compute_core -o neon_convolution
To cross compile a Neon example for Linux 64bit:
aarch64-linux-gnu-g++ examples/neon_convolution.cpp utils/Utils.cpp -I. -Iinclude -std=c++14 -L. -larm_compute -larm_compute_core -o neon_convolution
(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_convolution.cpp utils/Utils.cpp -I. -Iinclude -std=c++14 -mfpu=neon -L. -larm_compute -larm_compute_core -o cl_convolution -DARM_COMPUTE_CL
To cross compile an OpenCL example for Linux 64bit:
aarch64-linux-gnu-g++ examples/cl_convolution.cpp utils/Utils.cpp -I. -Iinclude -std=c++14 -L. -larm_compute -larm_compute_core -o cl_convolution -DARM_COMPUTE_CL
To cross compile a GLES example for Linux 32bit:
arm-linux-gnueabihf-g++ examples/gc_absdiff.cpp utils/Utils.cpp -I. -Iinclude/ -L. -larm_compute -larm_compute_core -std=c++14 -mfpu=neon -DARM_COMPUTE_GC -Iinclude/linux/ -o gc_absdiff
To cross compile a GLES example for Linux 64bit:
aarch64-linux-gnu-g++ examples/gc_absdiff.cpp utils/Utils.cpp -I. -Iinclude/ -L. -larm_compute -larm_compute_core -std=c++14 -DARM_COMPUTE_GC -Iinclude/linux/ -o gc_absdiff
(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 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 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
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
(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 compile natively (i.e directly on an Arm device) for Neon for Linux 32bit:
g++ examples/neon_convolution.cpp utils/Utils.cpp -I. -Iinclude -std=c++14 -mfpu=neon -larm_compute -larm_compute_core -o neon_convolution
To compile natively (i.e directly on an Arm device) for Neon for Linux 64bit:
g++ examples/neon_convolution.cpp utils/Utils.cpp -I. -Iinclude -std=c++14 -larm_compute -larm_compute_core -o neon_convolution
(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_convolution.cpp utils/Utils.cpp -I. -Iinclude -std=c++14 -larm_compute -larm_compute_core -o cl_convolution -DARM_COMPUTE_CL
To compile natively (i.e directly on an Arm device) for GLES for Linux 32bit or Linux 64bit:
g++ examples/gc_absdiff.cpp utils/Utils.cpp -I. -Iinclude/ -L. -larm_compute -larm_compute_core -std=c++14 -DARM_COMPUTE_GC -Iinclude/linux/ -o gc_absdiff
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
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
(notice the only difference with the 32 bit command is that we don't need the -mfpu option)
To run the built executable simply run:
LD_LIBRARY_PATH=build ./neon_convolution
or
LD_LIBRARY_PATH=build ./cl_convolution
For example:
LD_LIBRARY_PATH=. ./graph_lenet --help
Below is a list of the common parameters among the graph examples :
In order to build for SVE or SVE2 you need a compiler that supports them. You can find more information in the following these links:
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-
For Android, the library was successfully built and tested using Google's standalone toolchains:
Here is a guide to create your Android standalone toolchains from the NDK. Minimum NDK version required: r18b
$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
export PATH=$PATH:$MY_TOOLCHAINS/aarch64-linux-android-ndk-r18b/bin:$MY_TOOLCHAINS/arm-linux-android-ndk-r18b/bin
To cross-compile the library in debug mode, with Neon only support, for Android 32bit:
CXX=clang++ CC=clang scons Werror=1 -j8 debug=1 neon=1 opencl=0 os=android arch=armv7a
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
To cross-compile the library in asserts mode, with GLES_COMPUTE only support, for Android 64bit:
CXX=clang++ CC=clang scons Werror=1 -j8 debug=0 asserts=1 neon=0 opencl=0 gles_compute=1 embed_kernels=1 os=android arch=arm64-v8a
The examples get automatically built by scons as part of the build process of the library described above. This section just describes how you can build and link your own application against our library.
Once you've got your Android standalone toolchain built and added to your path you can do the following:
To cross compile a Neon example:
#32 bit: arm-linux-androideabi-clang++ examples/neon_convolution.cpp utils/Utils.cpp -I. -Iinclude -std=c++14 -larm_compute-static -larm_compute_core-static -L. -o neon_convolution_arm -static-libstdc++ -pie #64 bit: aarch64-linux-android-clang++ examples/neon_convolution.cpp utils/Utils.cpp -I. -Iinclude -std=c++14 -larm_compute-static -larm_compute_core-static -L. -o neon_convolution_aarch64 -static-libstdc++ -pie
To cross compile an OpenCL example:
#32 bit: arm-linux-androideabi-clang++ examples/cl_convolution.cpp utils/Utils.cpp -I. -Iinclude -std=c++14 -larm_compute-static -larm_compute_core-static -L. -o cl_convolution_arm -static-libstdc++ -pie -DARM_COMPUTE_CL #64 bit: aarch64-linux-android-clang++ examples/cl_convolution.cpp utils/Utils.cpp -I. -Iinclude -std=c++14 -larm_compute-static -larm_compute_core-static -L. -o cl_convolution_aarch64 -static-libstdc++ -pie -DARM_COMPUTE_CL
To cross compile a GLES example:
#32 bit: arm-linux-androideabi-clang++ examples/gc_absdiff.cpp utils/Utils.cpp -I. -Iinclude -std=c++14 -larm_compute-static -larm_compute_core-static -L. -o gc_absdiff_arm -static-libstdc++ -pie -DARM_COMPUTE_GC #64 bit: aarch64-linux-android-clang++ examples/gc_absdiff.cpp utils/Utils.cpp -I. -Iinclude -std=c++14 -larm_compute-static -larm_compute_core-static -L. -o gc_absdiff_aarch64 -static-libstdc++ -pie -DARM_COMPUTE_GC
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 #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
Then you need to do is upload the executable and the shared library to the device using ADB:
adb push neon_convolution_arm /data/local/tmp/ adb push cl_convolution_arm /data/local/tmp/ adb push gc_absdiff_arm /data/local/tmp/ adb shell chmod 777 -R /data/local/tmp/
And finally to run the example:
adb shell /data/local/tmp/neon_convolution_arm adb shell /data/local/tmp/cl_convolution_arm adb shell /data/local/tmp/gc_absdiff_arm
For 64bit:
adb push neon_convolution_aarch64 /data/local/tmp/ adb push cl_convolution_aarch64 /data/local/tmp/ adb push gc_absdiff_aarch64 /data/local/tmp/ adb shell chmod 777 -R /data/local/tmp/
And finally to run the example:
adb shell /data/local/tmp/neon_convolution_aarch64 adb shell /data/local/tmp/cl_convolution_aarch64 adb shell /data/local/tmp/gc_absdiff_aarch64
For example: adb shell /data/local/tmp/graph_lenet –help
In this case the first argument of LeNet (like all the graph examples) is the target (i.e 0 to run on Neon, 1 to run on OpenCL if available, 2 to run on OpenCL using the CLTuner), the second argument is the path to the folder containing the npy files for the weights and finally the third argument is the number of batches to run.
The library was successfully natively built for Apple Silicon under macOS 11.1 using clang v12.0.0.
To natively compile the library with accelerated CPU support:
scons Werror=1 -j8 neon=1 opencl=0 os=macos arch=arm64-v8a build=native
For bare metal, the library was successfully built using linaro's latest (gcc-linaro-6.3.1-2017.05) bare metal toolchains:
Download linaro for armv7a and arm64-v8a.
To cross-compile the library with Neon support for baremetal arm64-v8a:
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
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 here.
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 recommended to follow one of the options outlined below.
The best and easiest option is to use Ubuntu on Windows. 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.
If the Windows subsystem for Linux is not available Cygwin 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 code of the library.) Linaro provides pre-built versions of GCC cross-compilers that can be used from the Cygwin terminal. When building for Android the 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.
Compute Library requires OpenCL 1.1 and above with support of non uniform workgroup sizes, which is officially supported in the Mali OpenCL DDK r8p0 and above as an extension (respective extension flag is -cl-arm-non-uniform-work-group-size).
Enabling 16-bit floating point calculations require cl_khr_fp16 extension to be supported. All Mali GPUs with compute capabilities have native support for half precision floating points.
Use of CLMeanStdDev function requires 64-bit atomics support, thus cl_khr_int64_base_atomics should be supported in order to use.
Integer dot product built-in function extensions (and therefore optimized kernels) are available with Mali OpenCL DDK r22p0 and above for the following GPUs : G71, G76. The relevant extensions are cl_arm_integer_dot_product_int8, cl_arm_integer_dot_product_accumulate_int8 and cl_arm_integer_dot_product_accumulate_int16.
OpenCL kernel level debugging can be simplified with the use of printf, this requires the cl_arm_printf extension to be supported.
SVM allocations are supported for all the underlying allocations in Compute Library. To enable this OpenCL 2.0 and above is a requirement.
The OpenCL tuner, a.k.a. CLTuner, is a module of Arm Compute Library that can improve the performance of the OpenCL kernels tuning the Local-Workgroup-Size (LWS). The optimal LWS for each unique OpenCL kernel configuration is stored in a table. This table can be either imported or exported from/to a file. The OpenCL tuner runs the same OpenCL kernel for a range of local workgroup sizes and keeps the local workgroup size of the fastest run to use in subsequent calls to the kernel. It supports three modes of tuning with different trade-offs between the time taken to tune and the kernel execution time achieved using the best LWS found. In the Exhaustive mode, it searches all the supported values of LWS. This mode takes the longest time to tune and is the most likely to find the optimal LWS. Normal mode searches a subset of LWS values to yield a good approximation of the optimal LWS. It takes less time to tune than Exhaustive mode. Rapid mode takes the shortest time to tune and finds an LWS value that is at least as good or better than the default LWS value. The mode affects only the search for the optimal LWS and has no effect when the LWS value is imported from a file. In order for the performance numbers to be meaningful you must disable the GPU power management and set it to a fixed frequency for the entire duration of the tuning phase.
If you wish to know more about LWS and the important role on improving the GPU cache utilization, we suggest having a look at the presentation "Even Faster CNNs: Exploring the New Class of Winograd Algorithms available at the following link:
Tuning a network from scratch can be long and affect considerably the execution time for the first run of your network. It is recommended for this reason to store the CLTuner's result in a file to amortize this time when you either re-use the same network or the functions with the same configurations. The tuning is performed only once for each OpenCL kernel.
CLTuner looks for the optimal LWS for each unique OpenCL kernel configuration. Since a function (i.e. Convolution Layer, Pooling Layer, Fully Connected Layer ...) can be called multiple times but with different parameters, we associate an "id" (called "config_id") to each kernel to distinguish the unique configurations.
#Example: 2 unique Matrix Multiply configurations
All the graph examples in the Compute Library's folder "examples" and the arm_compute_benchmark accept an argument to enable the OpenCL tuner and an argument to export/import the LWS values to/from a file
#Enable CL tuner ./graph_mobilenet --enable-tuner –-target=CL ./arm_compute_benchmark --enable-tuner #Export/Import to/from a file ./graph_mobilenet --enable-tuner --target=CL --tuner-file=acl_tuner.csv ./arm_compute_benchmark --enable-tuner --tuner-file=acl_tuner.csv
If you are importing the CLTuner'results from a file, the new tuned LWS values will be appended to it.
Either you are benchmarking the graph examples or the test cases in the arm_compute_benchmark remember to:
-# Disable the power management -# Keep the GPU frequency constant -# Run multiple times the network (i.e. 10).
If you are not using the graph API or the benchmark infrastructure you will need to manually pass a CLTuner object to CLScheduler before configuring any function.
After the first run, the CLTuner's results can be exported to a file using the method "save_to_file()".
This file can be also imported using the method "load_from_file("results.csv")".