| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
| |
Refine old -l to test cases that can run
-la for all test cases
-li for test cases with issue
Signed-off-by: Pan Xiuli <xiuli.pan@intel.com>
Reviewed-by: Yang Rong <rong.r.yang@intel.com>
|
| |
|
|
|
|
|
| |
With issues is the 4th arguments.
Signed-off-by: Pan Xiuli <xiuli.pan@intel.com>
Reviewed-by: Yang Rong <rong.r.yang@intel.com>
|
| |
|
|
|
|
|
|
| |
For benchmarks, the units are varied e.g. GB/S, FPS, score and so on.
So we need to make a choice for every benchmark.
Signed-off-by: Meng Mengmeng <mengmeng.meng@intel.com>
Reviewed-by: Ruiling Song <ruiling.song@intel.com>
|
| |
|
|
|
|
|
| |
It's out-of-order execution in multi-tread which value range should be [1 - CPU cores].
Signed-off-by: Meng Mengmeng <mengmeng.meng@intel.com>
Reviewed-by: "Yang, Rong R" <rong.r.yang@intel.com>
|
| |
|
|
|
|
|
|
|
|
|
| |
Change output measurement from time to bandwidth, so we can compare
all benchmark results easily. And change return type of benchmark
from int to double, because int is not precise enough.
v2: Change output measurement from time to bandwidth.
Signed-off-by: Chuanbo Weng <chuanbo.weng@intel.com>
Reviewed-by: Zhigang Gong <zhigang.gong@linux.intel.com>
|
| |
|
|
|
| |
Signed-off-by: Zhu Bingbing<bingbingx.zhu@intel.com>
Reviewed-by: Zhigang Gong <zhigang.gong@linux.intel.com>
|
| |
|
|
|
|
|
|
| |
To make the license statement consistent to each other, adjust
all license versions to v2.1+. Thus beignet should have a pure
LGPL v2.1+ license.
Signed-off-by: Zhigang Gong <zhigang.gong@intel.com>
|
| |
|
|
|
|
|
|
|
| |
v2:
refine the benchmark case and don't mix it with normal
unit test cases.
Signed-off-by: Zhigang Gong <zhigang.gong@intel.com>
Reviewed-by: "Song, Ruiling" <ruiling.song@intel.com>
|
| |
|
|
|
|
|
| |
The first benchmark case is name enqueue_copy_buf.
Signed-off-by: Yi Sun <yi.sun@intel.com>
Reviewed-by: Zhigang Gong <zhigang.gong@linux.intel.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
summary:
---------------------
1. Delete the printing of dynamic statistics line.
2. Add function to catch signals(like CTRL+C,core dumped ...),
if caught, reminder user the signal name.
core dumped example:
...
displacement_map_element() [SUCCESS]
compiler_clod() Interrupt signal (SIGSEGV) received.
summary:
----------
total: 657
run: 297
pass: 271
fail: 26
pass rate: 0.960426
Signed-off-by: Yi Sun <yi.sun@intel.com>
Signed-off-by: Yangwei Shui <yangweix.shui@intel.com>
Reviewed-by: Zhigang Gong <zhigang.gong@linux.intel.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
summary:
-----------------
1. Add struct RStatistics to count passed number(passCount), failed number(failCount), finished run number(finishrun).
2. Print statistics line , if the termial is too narrow, doesn't print it:
......
test_load_program_from_bin() [SUCCESS]
profiling_exec() [SUCCESS]
enqueue_copy_buf() [SUCCESS]
[run/total: 656/656] pass: 629; fail: 25; pass rate: 0.961890
3. If case crashes, count it as failed, add the function to show statistic summary.
4. When all cases finished, list a summary like follows:
summary:
----------
total: 656
run: 656
pass: 629
fail: 25
pass rate: 0.961890
5. If ./utest_run &> log, the log will be a little messy, tring the following command to analyse the log:
sed 's/\r/\n/g' log | egrep "\w*\(\)" | sed -e 's/\s//g'
After analysed:
-----------------
......
builtin_minmag_float2()[SUCCESS]
builtin_minmag_float4()[SUCCESS]
builtin_minmag_float8()[SUCCESS]
builtin_minmag_float16()[SUCCESS]
builtin_nextafter_float()[FAILED]
builtin_nextafter_float2()[FAILED]
builtin_nextafter_float4()[FAILED]
......
6. Fix one issue, print out the crashed case name.
7. Delete the debug line in utests/compiler_basic_arithmetic.cpp, which
output the kernel name.
8. Define function statistics() in struct UTest, which called by "utest_run -a/-c/-n".
We just call this function to run each case, and print the statistics line.
Reviewed-by: "Song, Ruiling" <ruiling.song@intel.com>
Reviewed-by: Zhigang Gong <zhigang.gong@linux.intel.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For some test cases which include more than one kernel, the current
implementation always build the program for a new sub test case.
That wastes a lot of time. This patch introduce a new macro
MAKE_UTEST_FROM_FUNCTION_KEEP_PROGRAM which has an extra parameter
to specify whether to keep the previous program and avoid the extra
build. The normal usage is:
MAKE_UTEST_FROM_FUNCTION_KEEP_PROGRAM(fn1, true);
MAKE_UTEST_FROM_FUNCTION_KEEP_PROGRAM(fn2, true);
MAKE_UTEST_FROM_FUNCTION_KEEP_PROGRAM(fn3, true);
MAKE_UTEST_FROM_FUNCTION_KEEP_PROGRAM(fn4, true);
MAKE_UTEST_FROM_FUNCTION_KEEP_PROGRAM(fn5, false);
The scenario is that the above fn1-5 are included in the same kernel
file and we define the sub cases in the same cpp file. We already
have some examples of this usage in the compiler_abs.cpp, compiler_abs_diff.cpp
compiler_basic_arithmetic.cpp, compiler_vector_load_store.cpp, etc.
This patch reduces 2/3 of the utests execution time.
v2: should always destroy the program when run one specific test case.
Signed-off-by: Zhigang Gong <zhigang.gong@intel.com>
Reviewed-by: "Song, Ruiling" <ruiling.song@intel.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add some arguments:
-c <casename>: run sub-case named 'casename'
-l : list all the available case name
-a : run all test cases
-n : run all test cases without known issue
-h : display this usage
Add a alternate macro named MAKE_UTEST_FROM_FUNCTION_WITH_ISSUE to register a new test case, which has some known issue to be fixed till now.
While utest_run running, only cases which registered by MAKE_UTEST_FROM_FUNCTION will be involved by defalut.
If you want to run all the test cases including those with known issue, you should use argument '-a'.
Besides, you can use option '-c' to run any test case.
Signed-off-by: Yi Sun <yi.sun@intel.com>
Reviewed-by: Zhigang Gong <zhigang.gong@linux.intel.com>
|
| |
|
|
|
| |
Signed-off-by: Lu Guanqun <guanqun.lu@intel.com>
Reviewed-by: Zhigang Gong <zhigang.gong@linux.intel.com>
|
| | |
|
| |
|
