From 144d2fff0e9a87050eafd856789683ab39f08eda Mon Sep 17 00:00:00 2001 From: Anthony Barbier Date: Fri, 29 Sep 2017 10:46:08 +0100 Subject: COMPMID-417 Minor documentation fixes and error handling in instruments Fixed some Doxygen issues in the introduction and tests sections Switched MaliCounter to use ARM_COMPUTE_ERROR in order to get more context in case of failure Switched to use ARM_COMPUTE_ERROR instead of ERROR_ON in PMU and MaliCounter so that checks work in release mode too. (As these checks are to detect platform issues rather than programming errors) Change-Id: Ibbefa5a87d93c5c3aa5e190680052e4e99987dfe Reviewed-on: http://mpd-gerrit.cambridge.arm.com/89662 Reviewed-by: Gian Marco Iodice Reviewed-by: Georgios Pinitas Tested-by: Kaizen --- docs/00_introduction.dox | 2 -- docs/02_tests.dox | 22 ++++++++++++++++++++-- 2 files changed, 20 insertions(+), 4 deletions(-) (limited to 'docs') diff --git a/docs/00_introduction.dox b/docs/00_introduction.dox index b097128ac1..2b6ddfb045 100644 --- a/docs/00_introduction.dox +++ b/docs/00_introduction.dox @@ -417,8 +417,6 @@ Example: @b validation_tests: Enable the build of the validation suite. -@note You will need the Boost Test and Program options headers and libraries to build the validation tests. See @ref building_boost for more information. - @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) diff --git a/docs/02_tests.dox b/docs/02_tests.dox index 212f8f0fae..0eb6cee487 100644 --- a/docs/02_tests.dox +++ b/docs/02_tests.dox @@ -298,13 +298,13 @@ the test case with different inputs. Before starting a new test case have a look at the existing ones. They should provide a good overview how test cases are structured. -- The C++ reference needs to be added to `tests/validation_new/CPP/`. The +- The C++ reference needs to be added to `tests/validation/CPP/`. The reference function is typically a template parameterized by the underlying value type of the `SimpleTensor`. This makes it easy to specialise for different data types. - If all backends have a common interface it makes sense to share the setup code. This can be done by adding a fixture in - `tests/validation_new/fixtures/`. Inside of the `setup` method of a fixture + `tests/validation/fixtures/`. Inside of the `setup` method of a fixture the tensors can be created and initialised and the function can be configured and run. The actual test will only have to validate the results. To be shared among multiple backends the fixture class is usually a template that accepts @@ -382,6 +382,23 @@ As an alternative output format JSON is supported and can be selected via `--log-format=json`. To write the output to a file instead of stdout the `--log-file` option can be used. +@subsubsection tests_running_tests_benchmarking_mode Mode +Tests contain different datasets of different sizes, some of which will take several hours to run. +You can select which datasets to use by using the `--mode` option, we recommed you use `--mode=precommit` to start with. + +@subsubsection tests_running_tests_benchmarking_instruments Instruments +You can use the `--instruments` option to select one or more instruments to measure the execution time of the benchmark tests. + +`PMU` will try to read the CPU PMU events from the kernel (They need to be enabled on your platform) + +`MALI` will try to collect Mali hardware performance counters. (You need to have a recent enough Mali driver) + +`WALL_CLOCK` will measure time using `gettimeofday`: this should work on all platforms. + +You can pass a combinations of these instruments: `--instruments=PMU,MALI,WALL_CLOCK` + +@note You need to make sure the instruments have been selected at compile time using the `pmu=1` or `mali=1` scons options. + @subsection tests_running_tests_validation Validation @@ -412,6 +429,7 @@ For a complete list of possible selectors please see: http://www.boost.org/doc/l @subsubsection tests_running_tests_validation_verbosity Verbosity There 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. + */ } // namespace test } // namespace arm_compute -- cgit v1.2.1