blob: bf8838c0889a723060b12afb9895754bd49311fe [file] [log] [blame]
Anthony Barbier6ff3b192017-09-04 18:44:23 +01001/**
Anthony Barbier79c61782017-06-23 11:48:24 +01002@page tests Validation and benchmarks tests
Anthony Barbier6ff3b192017-09-04 18:44:23 +01003
4@tableofcontents
5
6@section building_test_dependencies Building dependencies
7
8The tests currently make use of Boost (Test and Program options) for validation
9and Google Benchmark for performance runs. Below are instructions about how to
10build these 3rd party libraries.
11
Anthony Barbier79c61782017-06-23 11:48:24 +010012@note By default the build of the validation and benchmark tests is disabled, to enable it use `validation_tests=1` and `benchmark_tests=1`
13
Anthony Barbier6ff3b192017-09-04 18:44:23 +010014@subsection building_boost Building Boost
15
16First follow the instructions from the Boost library on how to setup the Boost
17build system
18(http://www.boost.org/doc/libs/1_64_0/more/getting_started/index.html).
19Afterwards the required libraries can be build with:
20
21 ./b2 --with-program_options --with-test link=static \
22 define=BOOST_TEST_ALTERNATIVE_INIT_API
23
24Additionally, depending on your environment, it might be necessary to specify
25the ```toolset=``` option to choose the right compiler. Moreover,
26```address-model=32``` can be used to force building for 32bit and
27```target-os=android``` must be specified to build for Android.
28
29After executing the build command the libraries
30```libboost_program_options.a``` and ```libboost_unit_test_framework.a``` can
31be found in ```./stage/lib```.
32
33@subsection building_google_benchmark Building Google Benchmark
34
35Instructions on how to build Google Benchmark using CMake can be found in their
36repository: https://github.com/google/benchmark. For example, building for
37Android 32bit can be achieved via
38
39 cmake -DCMAKE_BUILD_TYPE=Release \
40 -DCMAKE_CXX_COMPILER=arm-linux-androideabi-clang++ \
41 -DBENCHMARK_ENABLE_LTO=false -DBENCHMARK_ENABLE_TESTING=false ..
42
43The library required by the compute library is ```libbenchmark.a```.
44
45@section tests_running_tests Running tests
46@subsection tests_running_tests_benchmarking Benchmarking
47@subsubsection tests_running_tests_benchmarking_filter Filter tests
48All tests can be run by invoking
49
50 ./arm_compute_benchmark -- ./data
51
52where `./data` contains the assets needed by the tests.
53
54If only a subset of the tests has to be executed the `--benchmark_filter` option takes a regular expression to select matching tests.
55
56 ./arm_compute_benchmark --benchmark_filter=neon_bitwise_and ./data
57
58All available tests can be displayed with the `--benchmark_list_tests` switch.
59
60 ./arm_compute_benchmark --benchmark_list_tests ./data
61
62@subsubsection tests_running_tests_benchmarking_runtime Runtime
63By default every test is run multiple *iterations* until a minimum time is reached. The minimum time (in seconds) can be controlled with the `--benchmark_min_time` flag. However, each test might have a hard coded value for the number of iterations or minimum execution time. In that case the command line argument is ignored for those specific tests.
64Additionally it is possible to specify multiple *repetitions* (`--benchmark_repetitions`) which will run each test multiple times (including the iterations). The average and standard deviation for all repetitions is automatically computed and reported.
65
66@subsubsection tests_running_tests_benchmarking_verbosity Verbosity
67The verbosity of the test output can be controlled via the `--v` flag. Though it should hardly ever be necessary.
68
69@subsection tests_running_tests_validation Validation
70@subsubsection tests_running_tests_validation_filter Filter tests
71All tests can be run by invoking
72
73 ./arm_compute_validation -- ./data
74
75where `./data` contains the assets needed by the tests.
76
77As running all tests can take a lot of time the suite is split into "precommit" and "nightly" tests. The precommit tests will be fast to execute but still cover the most important features. In contrast the nightly tests offer more extensive coverage but take longer. The different subsets can be selected from the command line as follows:
78
79 ./arm_compute_validation -t @precommit -- ./data
80 ./arm_compute_validation -t @nightly -- ./data
81
82Additionally it is possible to select specific suites or tests:
83
84 ./arm_compute_validation -t CL -- ./data
85 ./arm_compute_validation -t NEON/BitwiseAnd/RunSmall/_0 -- ./data
86
87All available tests can be displayed with the `--list_content` switch.
88
89 ./arm_compute_validation --list_content -- ./data
90
91For a complete list of possible selectors please see: http://www.boost.org/doc/libs/1_64_0/libs/test/doc/html/boost_test/runtime_config/test_unit_filtering.html
92
93@subsubsection tests_running_tests_validation_verbosity Verbosity
94There are two separate flags to control the verbosity of the test output. `--report_level` controls the verbosity of the summary produced after all tests have been executed. `--log_level` controls the verbosity of the information generated during the execution of tests. All available settings can be found in the Boost documentation for [--report_level](http://www.boost.org/doc/libs/1_64_0/libs/test/doc/html/boost_test/utf_reference/rt_param_reference/report_level.html) and [--log_level](http://www.boost.org/doc/libs/1_64_0/libs/test/doc/html/boost_test/utf_reference/rt_param_reference/log_level.html), respectively.
95*/