virtualenv/FFmpeg
1
0
Fork 0
mirror of https://github.com/FFmpeg/FFmpeg.git synced 2024-12-28 20:53:54 +02:00
Code Issues Releases Activity
202a35ecdb
FFmpeg/tests/checkasm/checkasm.c

1052 lines
29 KiB
C
Raw Normal View History

Checkasm: assembly testing and benchmarking tool It provides the following features: * verify correctness by comparing output to the C version. * detect failure to save and restore clobbered callee-saved registers. * detect 32-bit parameters being used as if they were 64-bit in x86-64 (the upper halves are not guaranteed to be zero - but in practice they very often are, which makes those bugs hard to spot otherwise). * easy benchmarking. Compile by running 'make checkasm'. Execute by running 'tests/checkasm/checkasm'. Optional arguments are '--bench' to run benchmarks for all functions, '--bench=<pattern>' to run benchmarks for all functions that starts with <pattern>, and '<integer>' to seed the PRNG for reproducible results. Contains unit tests for most h264pred functions to get started, more tests can be added afterwards using those as a reference. Loosely based on code from x264. Currently only supports x86 and x86-64, but additional architectures shouldn't be too much of an obstacle to add. Note that functions with floating point parameters or floating point return values are not supported. Some compiler-specific features or preprocessor hacks would likely be required to add support for that. Signed-off-by: Janne Grunau <janne-libav@jannau.net>
2015-07-11 20:32:11 +02:00
/*
* Assembly testing and benchmarking tool
* Copyright (c) 2015 Henrik Gramner
* Copyright (c) 2008 Loren Merritt
*
Merge commit '8bc67ec2c0d2b5444d51a1bed1d50f0e10d92717' * commit '8bc67ec2c0d2b5444d51a1bed1d50f0e10d92717': Checkasm: assembly testing and benchmarking tool Merged-by: Michael Niedermayer <michael@niedermayer.cc>
2015-07-12 21:00:50 +02:00
* This file is part of FFmpeg.
Checkasm: assembly testing and benchmarking tool It provides the following features: * verify correctness by comparing output to the C version. * detect failure to save and restore clobbered callee-saved registers. * detect 32-bit parameters being used as if they were 64-bit in x86-64 (the upper halves are not guaranteed to be zero - but in practice they very often are, which makes those bugs hard to spot otherwise). * easy benchmarking. Compile by running 'make checkasm'. Execute by running 'tests/checkasm/checkasm'. Optional arguments are '--bench' to run benchmarks for all functions, '--bench=<pattern>' to run benchmarks for all functions that starts with <pattern>, and '<integer>' to seed the PRNG for reproducible results. Contains unit tests for most h264pred functions to get started, more tests can be added afterwards using those as a reference. Loosely based on code from x264. Currently only supports x86 and x86-64, but additional architectures shouldn't be too much of an obstacle to add. Note that functions with floating point parameters or floating point return values are not supported. Some compiler-specific features or preprocessor hacks would likely be required to add support for that. Signed-off-by: Janne Grunau <janne-libav@jannau.net>
2015-07-11 20:32:11 +02:00
*
Merge commit '8bc67ec2c0d2b5444d51a1bed1d50f0e10d92717' * commit '8bc67ec2c0d2b5444d51a1bed1d50f0e10d92717': Checkasm: assembly testing and benchmarking tool Merged-by: Michael Niedermayer <michael@niedermayer.cc>
2015-07-12 21:00:50 +02:00
* FFmpeg is free software; you can redistribute it and/or modify
Checkasm: assembly testing and benchmarking tool It provides the following features: * verify correctness by comparing output to the C version. * detect failure to save and restore clobbered callee-saved registers. * detect 32-bit parameters being used as if they were 64-bit in x86-64 (the upper halves are not guaranteed to be zero - but in practice they very often are, which makes those bugs hard to spot otherwise). * easy benchmarking. Compile by running 'make checkasm'. Execute by running 'tests/checkasm/checkasm'. Optional arguments are '--bench' to run benchmarks for all functions, '--bench=<pattern>' to run benchmarks for all functions that starts with <pattern>, and '<integer>' to seed the PRNG for reproducible results. Contains unit tests for most h264pred functions to get started, more tests can be added afterwards using those as a reference. Loosely based on code from x264. Currently only supports x86 and x86-64, but additional architectures shouldn't be too much of an obstacle to add. Note that functions with floating point parameters or floating point return values are not supported. Some compiler-specific features or preprocessor hacks would likely be required to add support for that. Signed-off-by: Janne Grunau <janne-libav@jannau.net>
2015-07-11 20:32:11 +02:00
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
*
Merge commit '8bc67ec2c0d2b5444d51a1bed1d50f0e10d92717' * commit '8bc67ec2c0d2b5444d51a1bed1d50f0e10d92717': Checkasm: assembly testing and benchmarking tool Merged-by: Michael Niedermayer <michael@niedermayer.cc>
2015-07-12 21:00:50 +02:00
* FFmpeg is distributed in the hope that it will be useful,
Checkasm: assembly testing and benchmarking tool It provides the following features: * verify correctness by comparing output to the C version. * detect failure to save and restore clobbered callee-saved registers. * detect 32-bit parameters being used as if they were 64-bit in x86-64 (the upper halves are not guaranteed to be zero - but in practice they very often are, which makes those bugs hard to spot otherwise). * easy benchmarking. Compile by running 'make checkasm'. Execute by running 'tests/checkasm/checkasm'. Optional arguments are '--bench' to run benchmarks for all functions, '--bench=<pattern>' to run benchmarks for all functions that starts with <pattern>, and '<integer>' to seed the PRNG for reproducible results. Contains unit tests for most h264pred functions to get started, more tests can be added afterwards using those as a reference. Loosely based on code from x264. Currently only supports x86 and x86-64, but additional architectures shouldn't be too much of an obstacle to add. Note that functions with floating point parameters or floating point return values are not supported. Some compiler-specific features or preprocessor hacks would likely be required to add support for that. Signed-off-by: Janne Grunau <janne-libav@jannau.net>
2015-07-11 20:32:11 +02:00
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License along
Merge commit '8bc67ec2c0d2b5444d51a1bed1d50f0e10d92717' * commit '8bc67ec2c0d2b5444d51a1bed1d50f0e10d92717': Checkasm: assembly testing and benchmarking tool Merged-by: Michael Niedermayer <michael@niedermayer.cc>
2015-07-12 21:00:50 +02:00
* with FFmpeg; if not, write to the Free Software Foundation, Inc.,
Checkasm: assembly testing and benchmarking tool It provides the following features: * verify correctness by comparing output to the C version. * detect failure to save and restore clobbered callee-saved registers. * detect 32-bit parameters being used as if they were 64-bit in x86-64 (the upper halves are not guaranteed to be zero - but in practice they very often are, which makes those bugs hard to spot otherwise). * easy benchmarking. Compile by running 'make checkasm'. Execute by running 'tests/checkasm/checkasm'. Optional arguments are '--bench' to run benchmarks for all functions, '--bench=<pattern>' to run benchmarks for all functions that starts with <pattern>, and '<integer>' to seed the PRNG for reproducible results. Contains unit tests for most h264pred functions to get started, more tests can be added afterwards using those as a reference. Loosely based on code from x264. Currently only supports x86 and x86-64, but additional architectures shouldn't be too much of an obstacle to add. Note that functions with floating point parameters or floating point return values are not supported. Some compiler-specific features or preprocessor hacks would likely be required to add support for that. Signed-off-by: Janne Grunau <janne-libav@jannau.net>
2015-07-11 20:32:11 +02:00
* 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
*/
checkasm: use perf API on Linux ARM* On ARM platforms, accessing the PMU registers requires special user access permissions. Since there is no other way to get accurate timers, the current implementation of timers in FFmpeg rely on these registers. Unfortunately, enabling user access to these registers on Linux is not trivial, and generally involve compiling a random and unreliable github kernel module, or patching somehow your kernel. Such module is very unlikely to reach the upstream anytime soon. Quoting Robin Murphin from ARM: > Say you do give userspace direct access to the PMU; now run two or more > programs at once that believe they can use the counters for their own > "minimal-overhead" profiling. Have fun interpreting those results... > > And that's not even getting into the implications of scheduling across > different CPUs, CPUidle, etc. where the PMU state is completely beyond > userspace's control. In general, the plan to provide userspace with > something which might happen to just about work in a few corner cases, > but is meaningless, misleading or downright broken in all others, is to > never do so. As a result, the alternative is to use the Performance Monitoring Linux API which makes use of these registers internally (assuming the PMU of your ARM board is supported in the kernel, which is definitely not a given...). While the Linux API is obviously cross platform, it does have a significant overhead which needs to be taken into account. As a result, that mode is only weakly enabled on ARM platforms exclusively. Note on the non flexibility of the implementation: the timers (native FFmpeg vs Linux API) are selected at compilation time to prevent the need of function calls, which would result in a negative impact on the cycle counters.
2017-09-01 15:11:18 +02:00
#include "config.h"
configure: Use a separate config_components.h header for $ALL_COMPONENTS This avoids unnecessary rebuilds of most source files if only the list of enabled components has changed, but not the other properties of the build, set in config.h. Signed-off-by: Martin Storsjö <martin@martin.st>
2022-02-23 14:56:49 +02:00
#include "config_components.h"
checkasm: use perf API on Linux ARM* On ARM platforms, accessing the PMU registers requires special user access permissions. Since there is no other way to get accurate timers, the current implementation of timers in FFmpeg rely on these registers. Unfortunately, enabling user access to these registers on Linux is not trivial, and generally involve compiling a random and unreliable github kernel module, or patching somehow your kernel. Such module is very unlikely to reach the upstream anytime soon. Quoting Robin Murphin from ARM: > Say you do give userspace direct access to the PMU; now run two or more > programs at once that believe they can use the counters for their own > "minimal-overhead" profiling. Have fun interpreting those results... > > And that's not even getting into the implications of scheduling across > different CPUs, CPUidle, etc. where the PMU state is completely beyond > userspace's control. In general, the plan to provide userspace with > something which might happen to just about work in a few corner cases, > but is meaningless, misleading or downright broken in all others, is to > never do so. As a result, the alternative is to use the Performance Monitoring Linux API which makes use of these registers internally (assuming the PMU of your ARM board is supported in the kernel, which is definitely not a given...). While the Linux API is obviously cross platform, it does have a significant overhead which needs to be taken into account. As a result, that mode is only weakly enabled on ARM platforms exclusively. Note on the non flexibility of the implementation: the timers (native FFmpeg vs Linux API) are selected at compilation time to prevent the need of function calls, which would result in a negative impact on the cycle counters.
2017-09-01 15:11:18 +02:00
checkasm: add helper to report a fatal signal
2023-11-16 17:45:02 +02:00
#ifndef _GNU_SOURCE
# define _GNU_SOURCE // for syscall (performance monitoring API), strsignal()
checkasm: use perf API on Linux ARM* On ARM platforms, accessing the PMU registers requires special user access permissions. Since there is no other way to get accurate timers, the current implementation of timers in FFmpeg rely on these registers. Unfortunately, enabling user access to these registers on Linux is not trivial, and generally involve compiling a random and unreliable github kernel module, or patching somehow your kernel. Such module is very unlikely to reach the upstream anytime soon. Quoting Robin Murphin from ARM: > Say you do give userspace direct access to the PMU; now run two or more > programs at once that believe they can use the counters for their own > "minimal-overhead" profiling. Have fun interpreting those results... > > And that's not even getting into the implications of scheduling across > different CPUs, CPUidle, etc. where the PMU state is completely beyond > userspace's control. In general, the plan to provide userspace with > something which might happen to just about work in a few corner cases, > but is meaningless, misleading or downright broken in all others, is to > never do so. As a result, the alternative is to use the Performance Monitoring Linux API which makes use of these registers internally (assuming the PMU of your ARM board is supported in the kernel, which is definitely not a given...). While the Linux API is obviously cross platform, it does have a significant overhead which needs to be taken into account. As a result, that mode is only weakly enabled on ARM platforms exclusively. Note on the non flexibility of the implementation: the timers (native FFmpeg vs Linux API) are selected at compilation time to prevent the need of function calls, which would result in a negative impact on the cycle counters.
2017-09-01 15:11:18 +02:00
#endif
checkasm/riscv: report an error upon SIGILL Terminating the whole checkasm process is not very helpful. This will report if an illegal instruction occurs while executing a tested function. This is a common occurrence whilst developping RISC-V assembler, due to the compatibility between vector configuration and instruction done at run-time.
2023-07-12 21:48:53 +02:00
#include <signal.h>
Checkasm: assembly testing and benchmarking tool It provides the following features: * verify correctness by comparing output to the C version. * detect failure to save and restore clobbered callee-saved registers. * detect 32-bit parameters being used as if they were 64-bit in x86-64 (the upper halves are not guaranteed to be zero - but in practice they very often are, which makes those bugs hard to spot otherwise). * easy benchmarking. Compile by running 'make checkasm'. Execute by running 'tests/checkasm/checkasm'. Optional arguments are '--bench' to run benchmarks for all functions, '--bench=<pattern>' to run benchmarks for all functions that starts with <pattern>, and '<integer>' to seed the PRNG for reproducible results. Contains unit tests for most h264pred functions to get started, more tests can be added afterwards using those as a reference. Loosely based on code from x264. Currently only supports x86 and x86-64, but additional architectures shouldn't be too much of an obstacle to add. Note that functions with floating point parameters or floating point return values are not supported. Some compiler-specific features or preprocessor hacks would likely be required to add support for that. Signed-off-by: Janne Grunau <janne-libav@jannau.net>
2015-07-11 20:32:11 +02:00
#include <stdarg.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include "checkasm.h"
#include "libavutil/common.h"
#include "libavutil/cpu.h"
checkasm: add float comparison util functions
2015-12-07 17:14:46 +02:00
#include "libavutil/intfloat.h"
Checkasm: assembly testing and benchmarking tool It provides the following features: * verify correctness by comparing output to the C version. * detect failure to save and restore clobbered callee-saved registers. * detect 32-bit parameters being used as if they were 64-bit in x86-64 (the upper halves are not guaranteed to be zero - but in practice they very often are, which makes those bugs hard to spot otherwise). * easy benchmarking. Compile by running 'make checkasm'. Execute by running 'tests/checkasm/checkasm'. Optional arguments are '--bench' to run benchmarks for all functions, '--bench=<pattern>' to run benchmarks for all functions that starts with <pattern>, and '<integer>' to seed the PRNG for reproducible results. Contains unit tests for most h264pred functions to get started, more tests can be added afterwards using those as a reference. Loosely based on code from x264. Currently only supports x86 and x86-64, but additional architectures shouldn't be too much of an obstacle to add. Note that functions with floating point parameters or floating point return values are not supported. Some compiler-specific features or preprocessor hacks would likely be required to add support for that. Signed-off-by: Janne Grunau <janne-libav@jannau.net>
2015-07-11 20:32:11 +02:00
#include "libavutil/random_seed.h"
checkasm: Include io.h for isatty, if available configure does check for isatty, and checkasm properly checks HAVE_ISATTY, but on some platforms (e.g. WinRT), io.h needs to be included for isatty to be available. Signed-off-by: Martin Storsjö <martin@martin.st>
2015-07-29 22:08:09 +02:00
#if HAVE_IO_H
#include <io.h>
#endif
checkasm: Generalize crash handling This replaces the riscv specific handling from 7212466e735aa187d82f51dadbce957fe3da77f0 (which essentially is reverted), with a different implementation of the same (plus a bit more), based on the corresponding feature in dav1d's checkasm, supporting both Unix and Windows. See in particular the dav1d commits 0b6ee30eab2400e4f85b735ad29a68a842c34e21, 0421f787ea592fd2cc74c887f20b8dc31393788b, 8501a4b20135f93a4c3b426468e2240e872949c5 and d23e87f7aee26ddcf5f7a2e185112031477599a7, authored by Henrik Gramner. The overall approach compared to the existing implementation for riscv is the same; set up a signal handler, store the state with sigsetjmp, jump out of the crashing function with siglongjmp. The main difference is in what happens when the signal handler is invoked. In the previous implementation, it would resume from right before calling the crashing function, and then skip that call based on the setjmp return value. In the imported implementation from dav1d, we return to right before the check_func() call, which will skip testing the current function (as the pointer is the same as it was before). Other differences are: - Support for other signal handling mechanisms (Windows AddVectoredExceptionHandler) - Using RtlCaptureContext/RtlRestoreContext instead of setjmp/longjmp on Windows with SEH - Only catching signals once per function - if more than one signal is delivered before signal handling is reenabled, any signal is handled as it would without our handler - Not using an arch specific signal handler written in assembly Signed-off-by: Martin Storsjö <martin@martin.st>
2023-12-14 14:57:36 +02:00
#if defined(_WIN32) && !defined(SIGBUS)
/* non-standard, use the same value as mingw-w64 */
#define SIGBUS 10
#endif
checkasm: Check HAVE_GETSTDHANDLE here as well This was missed in 63418e374fcf26. Signed-off-by: Martin Storsjö <martin@martin.st>
2020-01-24 00:02:35 +02:00
#if HAVE_SETCONSOLETEXTATTRIBUTE && HAVE_GETSTDHANDLE
Checkasm: assembly testing and benchmarking tool It provides the following features: * verify correctness by comparing output to the C version. * detect failure to save and restore clobbered callee-saved registers. * detect 32-bit parameters being used as if they were 64-bit in x86-64 (the upper halves are not guaranteed to be zero - but in practice they very often are, which makes those bugs hard to spot otherwise). * easy benchmarking. Compile by running 'make checkasm'. Execute by running 'tests/checkasm/checkasm'. Optional arguments are '--bench' to run benchmarks for all functions, '--bench=<pattern>' to run benchmarks for all functions that starts with <pattern>, and '<integer>' to seed the PRNG for reproducible results. Contains unit tests for most h264pred functions to get started, more tests can be added afterwards using those as a reference. Loosely based on code from x264. Currently only supports x86 and x86-64, but additional architectures shouldn't be too much of an obstacle to add. Note that functions with floating point parameters or floating point return values are not supported. Some compiler-specific features or preprocessor hacks would likely be required to add support for that. Signed-off-by: Janne Grunau <janne-libav@jannau.net>
2015-07-11 20:32:11 +02:00
#include <windows.h>
#define COLOR_RED FOREGROUND_RED
#define COLOR_GREEN FOREGROUND_GREEN
#define COLOR_YELLOW (FOREGROUND_RED|FOREGROUND_GREEN)
#else
#define COLOR_RED 1
#define COLOR_GREEN 2
#define COLOR_YELLOW 3
#endif
#if HAVE_UNISTD_H
#include <unistd.h>
#endif
#if !HAVE_ISATTY
#define isatty(fd) 1
#endif
checkasm: Check register clobbering on arm Use two separate functions, depending on whether VFP/NEON is available. This is set to require armv5te - it uses blx, which is only available since armv5t, but we don't have a separate configure item for that. (It also uses ldrd, which requires armv5te, but this could be avoided if necessary.) Signed-off-by: Martin Storsjö <martin@martin.st>
2015-12-30 23:46:06 +02:00
#if ARCH_ARM && HAVE_ARMV5TE_EXTERNAL
#include "libavutil/arm/cpu.h"
void (*checkasm_checked_call)(void *func, int dummy, ...) = checkasm_checked_call_novfp;
#endif
Checkasm: assembly testing and benchmarking tool It provides the following features: * verify correctness by comparing output to the C version. * detect failure to save and restore clobbered callee-saved registers. * detect 32-bit parameters being used as if they were 64-bit in x86-64 (the upper halves are not guaranteed to be zero - but in practice they very often are, which makes those bugs hard to spot otherwise). * easy benchmarking. Compile by running 'make checkasm'. Execute by running 'tests/checkasm/checkasm'. Optional arguments are '--bench' to run benchmarks for all functions, '--bench=<pattern>' to run benchmarks for all functions that starts with <pattern>, and '<integer>' to seed the PRNG for reproducible results. Contains unit tests for most h264pred functions to get started, more tests can be added afterwards using those as a reference. Loosely based on code from x264. Currently only supports x86 and x86-64, but additional architectures shouldn't be too much of an obstacle to add. Note that functions with floating point parameters or floating point return values are not supported. Some compiler-specific features or preprocessor hacks would likely be required to add support for that. Signed-off-by: Janne Grunau <janne-libav@jannau.net>
2015-07-11 20:32:11 +02:00
/* List of tests to invoke */
checkasm: Modify report format Makes it a bit more clear where each test belongs. Suggested by Anton Khirnov. Signed-off-by: Anton Khirnov <anton@khirnov.net>
2015-07-24 23:46:20 +02:00
static const struct {
const char *name;
void (*func)(void);
} tests[] = {
checkasm: Fix compilation with --disable-avcodec
2015-10-01 19:25:33 +02:00
#if CONFIG_AVCODEC
checkasm: add AAC PS tests This includes various fixes and improvements from James Almer. Signed-off-by: James Almer <jamrial@gmail.com>
2017-06-02 10:06:08 +02:00
#if CONFIG_AAC_DECODER
{ "aacpsdsp", checkasm_check_aacpsdsp },
checkasm: add sbrdsp tests
2017-06-09 11:34:12 +02:00
{ "sbrdsp", checkasm_check_sbrdsp },
checkasm: add AAC PS tests This includes various fixes and improvements from James Almer. Signed-off-by: James Almer <jamrial@gmail.com>
2017-06-02 10:06:08 +02:00
#endif
checkasm: test for abs_pow34 Signed-off-by: Rémi Denis-Courmont <remi@remlab.net>
2023-11-28 08:08:12 +02:00
#if CONFIG_AAC_ENCODER
{ "aacencdsp", checkasm_check_aacencdsp },
#endif
checkasm/ac3dsp: add float_to_fixed24 test Signed-off-by: Rémi Denis-Courmont <remi@remlab.net>
2023-11-22 08:57:29 +02:00
#if CONFIG_AC3DSP
{ "ac3dsp", checkasm_check_ac3dsp },
#endif
checkasm: add alacdsp tests Signed-off-by: James Almer <jamrial@gmail.com>
2015-10-07 01:25:49 +02:00
#if CONFIG_ALAC_DECODER
{ "alacdsp", checkasm_check_alacdsp },
#endif
Merge commit 'e9ef6171396dc4106526aaa86b620c61ca3d1017' * commit 'e9ef6171396dc4106526aaa86b620c61ca3d1017': checkasm: add tests for audiodsp Merged-by: Clément Bœsch <u@pkh.me>
2017-03-20 20:10:56 +02:00
#if CONFIG_AUDIODSP
{ "audiodsp", checkasm_check_audiodsp },
#endif
Merge commit '2eb97af66af90ca3978229da151f0b8b3a5d9370' * commit '2eb97af66af90ca3978229da151f0b8b3a5d9370': checkasm: add a test for blockdsp Merged-by: Clément Bœsch <u@pkh.me>
2017-03-20 20:04:12 +02:00
#if CONFIG_BLOCKDSP
{ "blockdsp", checkasm_check_blockdsp },
#endif
checkasm: Fix compilation with --disable-avcodec
2015-10-01 19:25:33 +02:00
#if CONFIG_BSWAPDSP
{ "bswapdsp", checkasm_check_bswapdsp },
#endif
avcodec/dca: add new decoder based on libdcadec
2016-01-16 10:54:38 +02:00
#if CONFIG_DCA_DECODER
Merge commit '568a4323fbde03665b2b23a98068d02b39121812' * commit '568a4323fbde03665b2b23a98068d02b39121812': checkasm: add synth_filter test Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
2016-01-02 13:45:34 +02:00
{ "synth_filter", checkasm_check_synth_filter },
avcodec/dca: add new decoder based on libdcadec
2016-01-16 10:54:38 +02:00
#endif
checkasm: add an exrdsp test Signed-off-by: James Almer <jamrial@gmail.com>
2017-09-17 23:48:02 +02:00
#if CONFIG_EXR_DECODER
{ "exrdsp", checkasm_check_exrdsp },
#endif
avcodec/flacdsp: Split encoder-only parts into a ctx of its own Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
2022-08-01 03:07:46 +02:00
#if CONFIG_FLAC_DECODER
checkasm: Fix compilation with --disable-avcodec
2015-10-01 19:25:33 +02:00
{ "flacdsp", checkasm_check_flacdsp },
#endif
Merge commit '489e6add4478b0f5717dbf644234c6f3a3baf02c' * commit '489e6add4478b0f5717dbf644234c6f3a3baf02c': checkasm: add fmtconvert tests Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
2016-01-02 13:50:13 +02:00
#if CONFIG_FMTCONVERT
{ "fmtconvert", checkasm_check_fmtconvert },
#endif
checkasm: add a g722dsp test Signed-off-by: James Almer <jamrial@gmail.com>
2017-07-05 21:34:00 +02:00
#if CONFIG_G722DSP
{ "g722dsp", checkasm_check_g722dsp },
#endif
checkasm: add h264chroma tests Checks all variants of put_h264_chroma and avg_h264_chroma.
2023-05-18 16:18:16 +02:00
#if CONFIG_H264CHROMA
{ "h264chroma", checkasm_check_h264chroma },
#endif
Merge commit '105998fb5ca3c343f5c8cb39ce3197f87a5e4d36' * commit '105998fb5ca3c343f5c8cb39ce3197f87a5e4d36': checkasm: Add tests for h264 idct Merged-by: Matthieu Bouron <matthieu.bouron@stupeflix.com>
2016-07-13 17:16:14 +02:00
#if CONFIG_H264DSP
{ "h264dsp", checkasm_check_h264dsp },
#endif
checkasm: Fix compilation with --disable-avcodec
2015-10-01 19:25:33 +02:00
#if CONFIG_H264PRED
{ "h264pred", checkasm_check_h264pred },
#endif
#if CONFIG_H264QPEL
{ "h264qpel", checkasm_check_h264qpel },
#endif
Merge commit '9064777dbb335ab4809ae09e3fdcc0245f925cdc' * commit '9064777dbb335ab4809ae09e3fdcc0245f925cdc': checkasm: add HEVC test for testing IDCT DC Merged-by: Clément Bœsch <cboesch@gopro.com>
2017-02-02 12:39:30 +02:00
#if CONFIG_HEVC_DECODER
Merge commit 'ed48a9d8143d2575a4458589cebde69ec326afd8' * commit 'ed48a9d8143d2575a4458589cebde69ec326afd8': checkasm: Add a test for HEVC add_residual Merged-by: Clément Bœsch <u@pkh.me>
2017-03-24 13:37:09 +02:00
{ "hevc_add_res", checkasm_check_hevc_add_res },
checkasm: add hevc_deblock chroma test Signed-off-by: J. Dekker <jdek@itanimul.li>
2023-03-21 19:44:03 +02:00
{ "hevc_deblock", checkasm_check_hevc_deblock },
Merge commit '9064777dbb335ab4809ae09e3fdcc0245f925cdc' * commit '9064777dbb335ab4809ae09e3fdcc0245f925cdc': checkasm: add HEVC test for testing IDCT DC Merged-by: Clément Bœsch <cboesch@gopro.com>
2017-02-02 12:39:30 +02:00
{ "hevc_idct", checkasm_check_hevc_idct },
checkasm: collapse hevc pel tests Also add to `make fate-checkasm' target. Signed-off-by: J. Dekker <jdek@itanimul.li>
2021-08-05 10:26:48 +02:00
{ "hevc_pel", checkasm_check_hevc_pel },
checkasm/hevc_sao : add hevc_sao for checkasm Signed-off-by: James Almer <jamrial@gmail.com>
2018-03-07 06:42:30 +02:00
{ "hevc_sao", checkasm_check_hevc_sao },
Merge commit '9064777dbb335ab4809ae09e3fdcc0245f925cdc' * commit '9064777dbb335ab4809ae09e3fdcc0245f925cdc': checkasm: add HEVC test for testing IDCT DC Merged-by: Clément Bœsch <cboesch@gopro.com>
2017-02-02 12:39:30 +02:00
#endif
checkasm : add test for huffyuvdsp add_int16
2017-11-21 10:09:42 +02:00
#if CONFIG_HUFFYUV_DECODER
{ "huffyuvdsp", checkasm_check_huffyuvdsp },
#endif
checkasm: Add idctdsp add/put-pixels-clamped tests Signed-off-by: Ben Avison <bavison@riscosopen.org> Signed-off-by: Martin Storsjö <martin@martin.st>
2022-03-31 19:23:44 +02:00
#if CONFIG_IDCTDSP
{ "idctdsp", checkasm_check_idctdsp },
#endif
checkasm: Fix compilation with --disable-avcodec
2015-10-01 19:25:33 +02:00
#if CONFIG_JPEG2000_DECODER
{ "jpeg2000dsp", checkasm_check_jpeg2000dsp },
#endif
checkasm: add lossless audio DSP
2023-11-12 21:45:24 +02:00
#if CONFIG_LLAUDDSP
{ "llauddsp", checkasm_check_llauddsp },
#endif
Merge commit '22c3ab18646924ce24dc6017a9e882ff69689e40' * commit '22c3ab18646924ce24dc6017a9e882ff69689e40': checkasm: Add test for huffyuvdsp add_bytes huffyuvdsp is renamed to llviddsp to be consistent with our codebase. Note: af607b7e07 wasn't actually required for this test since this commit is not actually testing huffyuvdsp. Merged-by: Clément Bœsch <u@pkh.me>
2017-03-22 17:29:44 +02:00
#if CONFIG_HUFFYUVDSP
{ "llviddsp", checkasm_check_llviddsp },
#endif
checkasm : add test for losslessvideoencdsp for diff bytes and sub_left_pred
2018-01-14 15:23:42 +02:00
#if CONFIG_LLVIDENCDSP
{ "llviddspenc", checkasm_check_llviddspenc },
#endif
x86/lpc: implement a new Welch windowing function Old one was written with the assumption only even inputs would be given. This very messy replacement supports even and odd inputs, and supports AVX2 for extra speed. The buffers given are usually quite big (4k samples), so the speedup is worth it. The new SSE version is still faster than the old inline asm version by 33%. Also checkasm is provided to make sure this monstrosity works. This fixes some FATE tests.
2022-09-19 23:48:53 +02:00
#if CONFIG_LPC
{ "lpc", checkasm_check_lpc },
#endif
lavc/aarch64: motion estimation functions in neon - ff_pix_abs16_neon - ff_pix_abs16_xy2_neon In direct micro benchmarks of these ff functions verses their C implementations, these functions performed as follows on AWS Graviton 3. ff_pix_abs16_neon: pix_abs_0_0_c: 141.1 pix_abs_0_0_neon: 19.6 ff_pix_abs16_xy2_neon: pix_abs_0_3_c: 269.1 pix_abs_0_3_neon: 39.3 Tested with: ./tests/checkasm/checkasm --test=motion --bench --disable-linux-perf Signed-off-by: Jonathan Swinney <jswinney@amazon.com> Signed-off-by: Martin Storsjö <martin@martin.st>
2022-06-26 22:58:09 +02:00
#if CONFIG_ME_CMP
{ "motion", checkasm_check_motion },
#endif
checkasm: add opusdsp tests
2019-08-15 12:42:19 +02:00
#if CONFIG_OPUS_DECODER
{ "opusdsp", checkasm_check_opusdsp },
#endif
Add pixblockdsp checkasm tests
2015-11-01 13:31:22 +02:00
#if CONFIG_PIXBLOCKDSP
{ "pixblockdsp", checkasm_check_pixblockdsp },
#endif
checkasm/svqenc: add ssd_int8_vs_int16 test Signed-off-by: Rémi Denis-Courmont <remi@remlab.net>
2023-12-29 07:09:21 +02:00
#if CONFIG_SVQ1_ENCODER
{ "svq1enc", checkasm_check_svq1enc },
#endif
checkasm/takdsp: add decorrelate_ls test Signed-off-by: Rémi Denis-Courmont <remi@remlab.net>
2023-12-18 16:39:13 +02:00
#if CONFIG_TAK_DECODER
{ "takdsp", checkasm_check_takdsp },
#endif
checkasm : add utvideodsp test
2017-11-21 09:31:12 +02:00
#if CONFIG_UTVIDEO_DECODER
{ "utvideodsp", checkasm_check_utvideodsp },
#endif
checkasm: add test for v210dec
2019-03-04 20:50:35 +02:00
#if CONFIG_V210_DECODER
{ "v210dec", checkasm_check_v210dec },
#endif
checkasm: Fix compilation with --disable-avcodec
2015-10-01 19:25:33 +02:00
#if CONFIG_V210_ENCODER
{ "v210enc", checkasm_check_v210enc },
#endif
checkasm: Add vc1dsp in-loop deblocking filter tests Note that the benchmarking results for these functions are highly dependent upon the input data. Therefore, each function is benchmarked twice, corresponding to the best and worst case complexity of the reference C implementation. The performance of a real stream decode will fall somewhere between these two extremes. Signed-off-by: Ben Avison <bavison@riscosopen.org> Signed-off-by: Martin Storsjö <martin@martin.st>
2022-03-31 19:23:42 +02:00
#if CONFIG_VC1DSP
{ "vc1dsp", checkasm_check_vc1dsp },
#endif
Merge commit 'f8d17d53957056c053a46f9320fa7ae6fe1479a5' * commit 'f8d17d53957056c053a46f9320fa7ae6fe1479a5': checkasm: Add tests for vp8dsp Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
2016-11-14 16:27:48 +02:00
#if CONFIG_VP8DSP
{ "vp8dsp", checkasm_check_vp8dsp },
#endif
checkasm: Fix compilation with --disable-avcodec
2015-10-01 19:25:33 +02:00
#if CONFIG_VP9_DECODER
{ "vp9dsp", checkasm_check_vp9dsp },
#endif
checkasm: add videodsp emulated_edge_mc test.
2016-01-17 23:22:26 +02:00
#if CONFIG_VIDEODSP
{ "videodsp", checkasm_check_videodsp },
#endif
tests/checkasm: add a test for VorbisDSPContext Signed-off-by: James Almer <jamrial@gmail.com>
2022-09-19 18:56:34 +02:00
#if CONFIG_VORBIS_DECODER
{ "vorbisdsp", checkasm_check_vorbisdsp },
#endif
checkasm: fix dependencies for vf_blend tests They will now compile if avcodec is disabled Reviewed-by: Paul B Mahol <onemda@gmail.com> Signed-off-by: James Almer <jamrial@gmail.com>
2016-02-19 01:23:49 +02:00
#endif
#if CONFIG_AVFILTER
checkasm: add an af_afir test Reviewed-by: Paul B Mahol <onemda@gmail.com> Signed-off-by: James Almer <jamrial@gmail.com>
2019-01-03 01:54:34 +02:00
#if CONFIG_AFIR_FILTER
{ "af_afir", checkasm_check_afir },
#endif
checkasm: fix dependencies for vf_blend tests They will now compile if avcodec is disabled Reviewed-by: Paul B Mahol <onemda@gmail.com> Signed-off-by: James Almer <jamrial@gmail.com>
2016-02-19 01:23:49 +02:00
#if CONFIG_BLEND_FILTER
{ "vf_blend", checkasm_check_blend },
#endif
checkasm: add test for bwdif
2023-02-20 21:55:08 +02:00
#if CONFIG_BWDIF_FILTER
{ "vf_bwdif", checkasm_check_vf_bwdif },
#endif
vf_colorspace: x86-64 SIMD (SSE2) optimizations.
2016-04-06 20:09:08 +02:00
#if CONFIG_COLORSPACE_FILTER
{ "vf_colorspace", checkasm_check_colorspace },
#endif
checkasm/vf_eq: add test for vf_eq Signed-off-by: Ting Fu <ting.fu@intel.com> Signed-off-by: Ruiling Song <ruiling.song@intel.com>
2019-09-18 09:05:33 +02:00
#if CONFIG_EQ_FILTER
{ "vf_eq", checkasm_check_vf_eq },
#endif
checkasm/vf_gblur: add test for horiz_slice simd Signed-off-by: Ruiling Song <ruiling.song@intel.com>
2019-06-04 10:34:08 +02:00
#if CONFIG_GBLUR_FILTER
{ "vf_gblur", checkasm_check_vf_gblur },
#endif
checkasm/vf_hflip : add test for vf_hflip byte and short simd
2017-12-11 12:26:44 +02:00
#if CONFIG_HFLIP_FILTER
{ "vf_hflip", checkasm_check_vf_hflip },
#endif
checkasm: add vf_nlmeans test for ssd_integral_image
2018-05-06 10:57:23 +02:00
#if CONFIG_NLMEANS_FILTER
{ "vf_nlmeans", checkasm_check_nlmeans },
#endif
checkasm/vf_threshold : add checkasm test for threshold8
2017-12-03 17:56:25 +02:00
#if CONFIG_THRESHOLD_FILTER
{ "vf_threshold", checkasm_check_vf_threshold },
#endif
libavfilter/x86/vf_convolution: add sobel filter optimization and unit test with intel AVX512 VNNI This commit enabled assembly code with intel AVX512 VNNI and added unit test for sobel filter sobel_c: 4537 sobel_avx512icl 2136 Signed-off-by: bwang30 <bin.wang@intel.com> Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>
2022-11-04 10:29:25 +02:00
#if CONFIG_SOBEL_FILTER
{ "vf_sobel", checkasm_check_vf_sobel },
#endif
checkasm: add fixed_dsp tests Tested-by: Michael Niedermayer <michael@niedermayer.cc> Signed-off-by: James Almer <jamrial@gmail.com>
2017-04-11 22:12:21 +02:00
#endif
checkasm/swscale : add test for rgb shuffle_bytes func
2018-03-24 21:19:00 +02:00
#if CONFIG_SWSCALE
swscale/x86/output.asm: add x86-optimized planer gbr yuv2anyX functions changes since v2: * fixed label changes since v1: * remove vex intruction on sse4 path * some load/pack marcos use less intructions * fixed some typos yuv2gbrp_full_X_4_512_c: 12757.6 yuv2gbrp_full_X_4_512_sse2: 8946.6 yuv2gbrp_full_X_4_512_sse4: 5138.6 yuv2gbrp_full_X_4_512_avx2: 3889.6 yuv2gbrap_full_X_4_512_c: 15368.6 yuv2gbrap_full_X_4_512_sse2: 11916.1 yuv2gbrap_full_X_4_512_sse4: 6294.6 yuv2gbrap_full_X_4_512_avx2: 3477.1 yuv2gbrp9be_full_X_4_512_c: 14381.6 yuv2gbrp9be_full_X_4_512_sse2: 9139.1 yuv2gbrp9be_full_X_4_512_sse4: 5150.1 yuv2gbrp9be_full_X_4_512_avx2: 2834.6 yuv2gbrp9le_full_X_4_512_c: 12990.1 yuv2gbrp9le_full_X_4_512_sse2: 9118.1 yuv2gbrp9le_full_X_4_512_sse4: 5132.1 yuv2gbrp9le_full_X_4_512_avx2: 2833.1 yuv2gbrp10be_full_X_4_512_c: 14401.6 yuv2gbrp10be_full_X_4_512_sse2: 9133.1 yuv2gbrp10be_full_X_4_512_sse4: 5126.1 yuv2gbrp10be_full_X_4_512_avx2: 2837.6 yuv2gbrp10le_full_X_4_512_c: 12718.1 yuv2gbrp10le_full_X_4_512_sse2: 9106.1 yuv2gbrp10le_full_X_4_512_sse4: 5120.1 yuv2gbrp10le_full_X_4_512_avx2: 2826.1 yuv2gbrap10be_full_X_4_512_c: 18535.6 yuv2gbrap10be_full_X_4_512_sse2: 33617.6 yuv2gbrap10be_full_X_4_512_sse4: 6264.1 yuv2gbrap10be_full_X_4_512_avx2: 3422.1 yuv2gbrap10le_full_X_4_512_c: 16724.1 yuv2gbrap10le_full_X_4_512_sse2: 11787.1 yuv2gbrap10le_full_X_4_512_sse4: 6282.1 yuv2gbrap10le_full_X_4_512_avx2: 3441.6 yuv2gbrp12be_full_X_4_512_c: 13723.6 yuv2gbrp12be_full_X_4_512_sse2: 9128.1 yuv2gbrp12be_full_X_4_512_sse4: 7997.6 yuv2gbrp12be_full_X_4_512_avx2: 2844.1 yuv2gbrp12le_full_X_4_512_c: 12257.1 yuv2gbrp12le_full_X_4_512_sse2: 9107.6 yuv2gbrp12le_full_X_4_512_sse4: 5142.6 yuv2gbrp12le_full_X_4_512_avx2: 2837.6 yuv2gbrap12be_full_X_4_512_c: 18511.1 yuv2gbrap12be_full_X_4_512_sse2: 12156.6 yuv2gbrap12be_full_X_4_512_sse4: 6251.1 yuv2gbrap12be_full_X_4_512_avx2: 3444.6 yuv2gbrap12le_full_X_4_512_c: 16687.1 yuv2gbrap12le_full_X_4_512_sse2: 11785.1 yuv2gbrap12le_full_X_4_512_sse4: 6243.6 yuv2gbrap12le_full_X_4_512_avx2: 3446.1 yuv2gbrp14be_full_X_4_512_c: 13690.6 yuv2gbrp14be_full_X_4_512_sse2: 9120.6 yuv2gbrp14be_full_X_4_512_sse4: 5138.1 yuv2gbrp14be_full_X_4_512_avx2: 2843.1 yuv2gbrp14le_full_X_4_512_c: 14995.6 yuv2gbrp14le_full_X_4_512_sse2: 9119.1 yuv2gbrp14le_full_X_4_512_sse4: 5126.1 yuv2gbrp14le_full_X_4_512_avx2: 2843.1 yuv2gbrp16be_full_X_4_512_c: 12367.1 yuv2gbrp16be_full_X_4_512_sse2: 8233.6 yuv2gbrp16be_full_X_4_512_sse4: 4820.1 yuv2gbrp16be_full_X_4_512_avx2: 2666.6 yuv2gbrp16le_full_X_4_512_c: 10904.1 yuv2gbrp16le_full_X_4_512_sse2: 8214.1 yuv2gbrp16le_full_X_4_512_sse4: 4824.1 yuv2gbrp16le_full_X_4_512_avx2: 2629.1 yuv2gbrap16be_full_X_4_512_c: 26569.6 yuv2gbrap16be_full_X_4_512_sse2: 10884.1 yuv2gbrap16be_full_X_4_512_sse4: 5488.1 yuv2gbrap16be_full_X_4_512_avx2: 3272.1 yuv2gbrap16le_full_X_4_512_c: 14010.1 yuv2gbrap16le_full_X_4_512_sse2: 10562.1 yuv2gbrap16le_full_X_4_512_sse4: 5463.6 yuv2gbrap16le_full_X_4_512_avx2: 3255.1 yuv2gbrpf32be_full_X_4_512_c: 14524.1 yuv2gbrpf32be_full_X_4_512_sse2: 8552.6 yuv2gbrpf32be_full_X_4_512_sse4: 4636.1 yuv2gbrpf32be_full_X_4_512_avx2: 2474.6 yuv2gbrpf32le_full_X_4_512_c: 13060.6 yuv2gbrpf32le_full_X_4_512_sse2: 9682.6 yuv2gbrpf32le_full_X_4_512_sse4: 4298.1 yuv2gbrpf32le_full_X_4_512_avx2: 2453.1 yuv2gbrapf32be_full_X_4_512_c: 18629.6 yuv2gbrapf32be_full_X_4_512_sse2: 11363.1 yuv2gbrapf32be_full_X_4_512_sse4: 15201.6 yuv2gbrapf32be_full_X_4_512_avx2: 3727.1 yuv2gbrapf32le_full_X_4_512_c: 16677.6 yuv2gbrapf32le_full_X_4_512_sse2: 10221.6 yuv2gbrapf32le_full_X_4_512_sse4: 5693.6 yuv2gbrapf32le_full_X_4_512_avx2: 3656.6 Reviewed-by: Paul B Mahol <onemda@gmail.com> Signed-off-by: James Almer <jamrial@gmail.com>
2021-11-24 23:15:20 +02:00
{ "sw_gbrp", checkasm_check_sw_gbrp },
checkasm/swscale : add test for rgb shuffle_bytes func
2018-03-24 21:19:00 +02:00
{ "sw_rgb", checkasm_check_sw_rgb },
checkasm: add hscale test This tests the hscale 8bpp to 14/18bpp functions with different filter sizes. Signed-off-by: Josh de Kock <josh@itanimul.li>
2020-05-13 17:02:53 +02:00
{ "sw_scale", checkasm_check_sw_scale },
checkasm/swscale : add test for rgb shuffle_bytes func
2018-03-24 21:19:00 +02:00
#endif
checkasm: add fixed_dsp tests Tested-by: Michael Niedermayer <michael@niedermayer.cc> Signed-off-by: James Almer <jamrial@gmail.com>
2017-04-11 22:12:21 +02:00
#if CONFIG_AVUTIL
{ "fixed_dsp", checkasm_check_fixed_dsp },
checkasm: add float_dsp tests Ported from libavutil/tests/float_dsp.c Signed-off-by: James Almer <jamrial@gmail.com>
2017-04-11 22:16:56 +02:00
{ "float_dsp", checkasm_check_float_dsp },
checkasm: add av_tx FFT SIMD testing code This sadly required making changes to the code itself, due to the same context needing to be reused for both versions. The lookup table had to be duplicated for both versions.
2021-04-10 03:53:38 +02:00
{ "av_tx", checkasm_check_av_tx },
Checkasm: assembly testing and benchmarking tool It provides the following features: * verify correctness by comparing output to the C version. * detect failure to save and restore clobbered callee-saved registers. * detect 32-bit parameters being used as if they were 64-bit in x86-64 (the upper halves are not guaranteed to be zero - but in practice they very often are, which makes those bugs hard to spot otherwise). * easy benchmarking. Compile by running 'make checkasm'. Execute by running 'tests/checkasm/checkasm'. Optional arguments are '--bench' to run benchmarks for all functions, '--bench=<pattern>' to run benchmarks for all functions that starts with <pattern>, and '<integer>' to seed the PRNG for reproducible results. Contains unit tests for most h264pred functions to get started, more tests can be added afterwards using those as a reference. Loosely based on code from x264. Currently only supports x86 and x86-64, but additional architectures shouldn't be too much of an obstacle to add. Note that functions with floating point parameters or floating point return values are not supported. Some compiler-specific features or preprocessor hacks would likely be required to add support for that. Signed-off-by: Janne Grunau <janne-libav@jannau.net>
2015-07-11 20:32:11 +02:00
#endif
checkasm: Modify report format Makes it a bit more clear where each test belongs. Suggested by Anton Khirnov. Signed-off-by: Anton Khirnov <anton@khirnov.net>
2015-07-24 23:46:20 +02:00
{ NULL }
Checkasm: assembly testing and benchmarking tool It provides the following features: * verify correctness by comparing output to the C version. * detect failure to save and restore clobbered callee-saved registers. * detect 32-bit parameters being used as if they were 64-bit in x86-64 (the upper halves are not guaranteed to be zero - but in practice they very often are, which makes those bugs hard to spot otherwise). * easy benchmarking. Compile by running 'make checkasm'. Execute by running 'tests/checkasm/checkasm'. Optional arguments are '--bench' to run benchmarks for all functions, '--bench=<pattern>' to run benchmarks for all functions that starts with <pattern>, and '<integer>' to seed the PRNG for reproducible results. Contains unit tests for most h264pred functions to get started, more tests can be added afterwards using those as a reference. Loosely based on code from x264. Currently only supports x86 and x86-64, but additional architectures shouldn't be too much of an obstacle to add. Note that functions with floating point parameters or floating point return values are not supported. Some compiler-specific features or preprocessor hacks would likely be required to add support for that. Signed-off-by: Janne Grunau <janne-libav@jannau.net>
2015-07-11 20:32:11 +02:00
};
/* List of cpu flags to check */
static const struct {
const char *name;
const char *suffix;
int flag;
} cpus[] = {
checkasm: test all architectures with optimisations
2015-07-12 16:41:42 +02:00
#if ARCH_AARCH64
{ "ARMV8", "armv8", AV_CPU_FLAG_ARMV8 },
{ "NEON", "neon", AV_CPU_FLAG_NEON },
aarch64: Add cpu flags for the dotprod and i8mm extensions Set these available if they are available unconditionally for the compiler. Signed-off-by: Martin Storsjö <martin@martin.st>
2023-05-25 14:29:02 +02:00
{ "DOTPROD", "dotprod", AV_CPU_FLAG_DOTPROD },
{ "I8MM", "i8mm", AV_CPU_FLAG_I8MM },
checkasm: test all architectures with optimisations
2015-07-12 16:41:42 +02:00
#elif ARCH_ARM
{ "ARMV5TE", "armv5te", AV_CPU_FLAG_ARMV5TE },
{ "ARMV6", "armv6", AV_CPU_FLAG_ARMV6 },
{ "ARMV6T2", "armv6t2", AV_CPU_FLAG_ARMV6T2 },
{ "VFP", "vfp", AV_CPU_FLAG_VFP },
arm: add a cpu flag for the VFPv2 vector mode The vector mode was deprecated in ARMv7-A/VFPv3 and various cpu implementations do not support it in hardware. Vector mode code will depending the OS either be emulated in software or result in an illegal instruction on cpus which does not support it. This was not really problem in practice since NEON implementations of the same functions are preferred. It will however become a problem for checkasm which tests every cpu flag separately. Since this is a cpu feature newer cpu do not support anymore the behaviour of this flag differs from the other flags. It can be only activated by runtime cpu feature selection.
2015-12-09 23:28:36 +02:00
{ "VFP_VM", "vfp_vm", AV_CPU_FLAG_VFP_VM },
checkasm: test all architectures with optimisations
2015-07-12 16:41:42 +02:00
{ "VFPV3", "vfp3", AV_CPU_FLAG_VFPV3 },
{ "NEON", "neon", AV_CPU_FLAG_NEON },
#elif ARCH_PPC
{ "ALTIVEC", "altivec", AV_CPU_FLAG_ALTIVEC },
{ "VSX", "vsx", AV_CPU_FLAG_VSX },
{ "POWER8", "power8", AV_CPU_FLAG_POWER8 },
lavu/cpu: detect RISC-V base extensions This introduces compile-time and run-time CPU detection on RISC-V. In practice, I doubt that FFmpeg will ever see a RISC-V CPU without all of I, F and D extensions, and if it does, it probably won't have run-time detection. So the flags are essentially always set. But as things stand, checkasm wants them that way. Compare the ARMV8 flag on AArch64. We are nowhere near running short on CPU flag bits.
2022-09-26 16:52:21 +02:00
#elif ARCH_RISCV
{ "RVI", "rvi", AV_CPU_FLAG_RVI },
{ "RVF", "rvf", AV_CPU_FLAG_RVF },
{ "RVD", "rvd", AV_CPU_FLAG_RVD },
lavu: add/use flag for RISC-V Zba extension The code was blindly assuming that Zbb or V implied Zba. While the earlier is practically always true, the later broke some QEMU setups, as V was introduced earlier than Zba.
2023-07-16 14:08:08 +02:00
{ "RVBaddr", "rvb_a", AV_CPU_FLAG_RVB_ADDR },
checkasm: test Zbb before V Without this, Zbb functions get shadowed by V functions on devices supporting both extensions, and never tested.
2023-07-16 13:46:00 +02:00
{ "RVBbasic", "rvb_b", AV_CPU_FLAG_RVB_BASIC },
lavu/cpu: CPU flags for the RISC-V Vector extension RVV defines a total of 12 different extensions, including: - 5 different instruction subsets: - Zve32x: 8-, 16- and 32-bit integers, - Zve32f: Zve32x plus single precision floats, - Zve64x: Zve32x plus 64-bit integers, - Zve64f: Zve32f plus Zve64x, - Zve64d: Zve64f plus double precision floats. - 6 different vector lengths: - Zvl32b (embedded only), - Zvl64b (embedded only), - Zvl128b, - Zvl256b, - Zvl512b, - Zvl1024b, - and the V extension proper: equivalent to Zve64f and Zvl128b. In total, there are 6 different possible sets of supported instructions (including the empty set), but for convenience we allocate one bit for each type sets: up-to-32-bit ints (RVV_I32), floats (RVV_F32), 64-bit ints (RVV_I64) and doubles (RVV_F64). Whence the vector size is needed, it can be retrieved by reading the unprivileged read-only vlenb CSR. This should probably be a separate helper macro if needed at a later point.
2022-09-26 16:52:25 +02:00
{ "RVVi32", "rvv_i32", AV_CPU_FLAG_RVV_I32 },
{ "RVVf32", "rvv_f32", AV_CPU_FLAG_RVV_F32 },
{ "RVVi64", "rvv_i64", AV_CPU_FLAG_RVV_I64 },
{ "RVVf64", "rvv_f64", AV_CPU_FLAG_RVV_F64 },
libavutil: Detect MMI and MSA flags for MIPS Add MMI & MSA runtime detection for MIPS. Basically there are two code pathes. For systems that natively support CPUCFG instruction or kernel emulated that instruction, we'll sense this feature from HWCAP and report the flags according to values grab from CPUCFG. For systems that have no CPUCFG (or not export it in HWCAP), we'll parse /proc/cpuinfo instead. Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com> Reviewed-by: Shiyou Yin <yinshiyou-hf@loongson.cn> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
2020-07-18 17:35:39 +02:00
#elif ARCH_MIPS
{ "MMI", "mmi", AV_CPU_FLAG_MMI },
{ "MSA", "msa", AV_CPU_FLAG_MSA },
checkasm: test all architectures with optimisations
2015-07-12 16:41:42 +02:00
#elif ARCH_X86
avutil/cpu: add AVX512 Icelake flag Signed-off-by: Wu Jianhua <jianhua.wu@intel.com> Reviewed-by: Henrik Gramner <henrik@gramner.com> Signed-off-by: James Almer <jamrial@gmail.com>
2022-02-23 10:57:30 +02:00
{ "MMX", "mmx", AV_CPU_FLAG_MMX|AV_CPU_FLAG_CMOV },
{ "MMXEXT", "mmxext", AV_CPU_FLAG_MMXEXT },
{ "3DNOW", "3dnow", AV_CPU_FLAG_3DNOW },
{ "3DNOWEXT", "3dnowext", AV_CPU_FLAG_3DNOWEXT },
{ "SSE", "sse", AV_CPU_FLAG_SSE },
{ "SSE2", "sse2", AV_CPU_FLAG_SSE2|AV_CPU_FLAG_SSE2SLOW },
{ "SSE3", "sse3", AV_CPU_FLAG_SSE3|AV_CPU_FLAG_SSE3SLOW },
{ "SSSE3", "ssse3", AV_CPU_FLAG_SSSE3|AV_CPU_FLAG_ATOM },
{ "SSE4.1", "sse4", AV_CPU_FLAG_SSE4 },
{ "SSE4.2", "sse42", AV_CPU_FLAG_SSE42 },
{ "AES-NI", "aesni", AV_CPU_FLAG_AESNI },
{ "AVX", "avx", AV_CPU_FLAG_AVX },
{ "XOP", "xop", AV_CPU_FLAG_XOP },
{ "FMA3", "fma3", AV_CPU_FLAG_FMA3 },
{ "FMA4", "fma4", AV_CPU_FLAG_FMA4 },
{ "AVX2", "avx2", AV_CPU_FLAG_AVX2 },
{ "AVX-512", "avx512", AV_CPU_FLAG_AVX512 },
{ "AVX-512ICL", "avx512icl", AV_CPU_FLAG_AVX512ICL },
avutil: [loongarch] Add support for loongarch SIMD. LSX and LASX is loongarch SIMD extention. They are enabled by default if compiler support it, and can be disabled with '--disable-lsx' '--disable-lasx'. Change-Id: Ie2608ea61dbd9b7fffadbf0ec2348bad6c124476 Reviewed-by: Shiyou Yin <yinshiyou-hf@loongson.cn> Reviewed-by: guxiwei <guxiwei-hf@loongson.cn> Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
2021-12-15 05:51:04 +02:00
#elif ARCH_LOONGARCH
{ "LSX", "lsx", AV_CPU_FLAG_LSX },
{ "LASX", "lasx", AV_CPU_FLAG_LASX },
Checkasm: assembly testing and benchmarking tool It provides the following features: * verify correctness by comparing output to the C version. * detect failure to save and restore clobbered callee-saved registers. * detect 32-bit parameters being used as if they were 64-bit in x86-64 (the upper halves are not guaranteed to be zero - but in practice they very often are, which makes those bugs hard to spot otherwise). * easy benchmarking. Compile by running 'make checkasm'. Execute by running 'tests/checkasm/checkasm'. Optional arguments are '--bench' to run benchmarks for all functions, '--bench=<pattern>' to run benchmarks for all functions that starts with <pattern>, and '<integer>' to seed the PRNG for reproducible results. Contains unit tests for most h264pred functions to get started, more tests can be added afterwards using those as a reference. Loosely based on code from x264. Currently only supports x86 and x86-64, but additional architectures shouldn't be too much of an obstacle to add. Note that functions with floating point parameters or floating point return values are not supported. Some compiler-specific features or preprocessor hacks would likely be required to add support for that. Signed-off-by: Janne Grunau <janne-libav@jannau.net>
2015-07-11 20:32:11 +02:00
#endif
{ NULL }
};
typedef struct CheckasmFuncVersion {
struct CheckasmFuncVersion *next;
checkasm: Explicitly declare function prototypes Now we no longer have to rely on function pointers intentionally declared without specified argument types. This makes it easier to support functions with floating point parameters or return values as well as functions returning 64-bit values on 32-bit architectures. It also avoids having to explicitly cast strides to ptrdiff_t for example.
2015-08-16 13:00:21 +02:00
void *func;
Checkasm: assembly testing and benchmarking tool It provides the following features: * verify correctness by comparing output to the C version. * detect failure to save and restore clobbered callee-saved registers. * detect 32-bit parameters being used as if they were 64-bit in x86-64 (the upper halves are not guaranteed to be zero - but in practice they very often are, which makes those bugs hard to spot otherwise). * easy benchmarking. Compile by running 'make checkasm'. Execute by running 'tests/checkasm/checkasm'. Optional arguments are '--bench' to run benchmarks for all functions, '--bench=<pattern>' to run benchmarks for all functions that starts with <pattern>, and '<integer>' to seed the PRNG for reproducible results. Contains unit tests for most h264pred functions to get started, more tests can be added afterwards using those as a reference. Loosely based on code from x264. Currently only supports x86 and x86-64, but additional architectures shouldn't be too much of an obstacle to add. Note that functions with floating point parameters or floating point return values are not supported. Some compiler-specific features or preprocessor hacks would likely be required to add support for that. Signed-off-by: Janne Grunau <janne-libav@jannau.net>
2015-07-11 20:32:11 +02:00
int ok;
int cpu;
checkasm: use perf API on Linux ARM* On ARM platforms, accessing the PMU registers requires special user access permissions. Since there is no other way to get accurate timers, the current implementation of timers in FFmpeg rely on these registers. Unfortunately, enabling user access to these registers on Linux is not trivial, and generally involve compiling a random and unreliable github kernel module, or patching somehow your kernel. Such module is very unlikely to reach the upstream anytime soon. Quoting Robin Murphin from ARM: > Say you do give userspace direct access to the PMU; now run two or more > programs at once that believe they can use the counters for their own > "minimal-overhead" profiling. Have fun interpreting those results... > > And that's not even getting into the implications of scheduling across > different CPUs, CPUidle, etc. where the PMU state is completely beyond > userspace's control. In general, the plan to provide userspace with > something which might happen to just about work in a few corner cases, > but is meaningless, misleading or downright broken in all others, is to > never do so. As a result, the alternative is to use the Performance Monitoring Linux API which makes use of these registers internally (assuming the PMU of your ARM board is supported in the kernel, which is definitely not a given...). While the Linux API is obviously cross platform, it does have a significant overhead which needs to be taken into account. As a result, that mode is only weakly enabled on ARM platforms exclusively. Note on the non flexibility of the implementation: the timers (native FFmpeg vs Linux API) are selected at compilation time to prevent the need of function calls, which would result in a negative impact on the cycle counters.
2017-09-01 15:11:18 +02:00
CheckasmPerf perf;
Checkasm: assembly testing and benchmarking tool It provides the following features: * verify correctness by comparing output to the C version. * detect failure to save and restore clobbered callee-saved registers. * detect 32-bit parameters being used as if they were 64-bit in x86-64 (the upper halves are not guaranteed to be zero - but in practice they very often are, which makes those bugs hard to spot otherwise). * easy benchmarking. Compile by running 'make checkasm'. Execute by running 'tests/checkasm/checkasm'. Optional arguments are '--bench' to run benchmarks for all functions, '--bench=<pattern>' to run benchmarks for all functions that starts with <pattern>, and '<integer>' to seed the PRNG for reproducible results. Contains unit tests for most h264pred functions to get started, more tests can be added afterwards using those as a reference. Loosely based on code from x264. Currently only supports x86 and x86-64, but additional architectures shouldn't be too much of an obstacle to add. Note that functions with floating point parameters or floating point return values are not supported. Some compiler-specific features or preprocessor hacks would likely be required to add support for that. Signed-off-by: Janne Grunau <janne-libav@jannau.net>
2015-07-11 20:32:11 +02:00
} CheckasmFuncVersion;
/* Binary search tree node */
typedef struct CheckasmFunc {
struct CheckasmFunc *child[2];
CheckasmFuncVersion versions;
checkasm: Use a self-balancing tree Tested functions are internally kept in a binary search tree for efficient lookups. The downside of the current implementation is that the tree quickly becomes unbalanced which causes an unneccessary amount of comparisons between nodes. Improve this by changing the tree into a self-balancing left-leaning red-black tree with a worst case lookup/insertion time complexity of O(log n). Significantly reduces the recursion depth and makes the tests run around 10% faster overall. The relative performance improvement compared to the existing non-balanced tree will also most likely increase as more tests are added.
2015-09-25 18:56:00 +02:00
uint8_t color; /* 0 = red, 1 = black */
Checkasm: assembly testing and benchmarking tool It provides the following features: * verify correctness by comparing output to the C version. * detect failure to save and restore clobbered callee-saved registers. * detect 32-bit parameters being used as if they were 64-bit in x86-64 (the upper halves are not guaranteed to be zero - but in practice they very often are, which makes those bugs hard to spot otherwise). * easy benchmarking. Compile by running 'make checkasm'. Execute by running 'tests/checkasm/checkasm'. Optional arguments are '--bench' to run benchmarks for all functions, '--bench=<pattern>' to run benchmarks for all functions that starts with <pattern>, and '<integer>' to seed the PRNG for reproducible results. Contains unit tests for most h264pred functions to get started, more tests can be added afterwards using those as a reference. Loosely based on code from x264. Currently only supports x86 and x86-64, but additional architectures shouldn't be too much of an obstacle to add. Note that functions with floating point parameters or floating point return values are not supported. Some compiler-specific features or preprocessor hacks would likely be required to add support for that. Signed-off-by: Janne Grunau <janne-libav@jannau.net>
2015-07-11 20:32:11 +02:00
char name[1];
} CheckasmFunc;
/* Internal state */
static struct {
CheckasmFunc *funcs;
CheckasmFunc *current_func;
CheckasmFuncVersion *current_func_ver;
checkasm: Modify report format Makes it a bit more clear where each test belongs. Suggested by Anton Khirnov. Signed-off-by: Anton Khirnov <anton@khirnov.net>
2015-07-24 23:46:20 +02:00
const char *current_test_name;
Checkasm: assembly testing and benchmarking tool It provides the following features: * verify correctness by comparing output to the C version. * detect failure to save and restore clobbered callee-saved registers. * detect 32-bit parameters being used as if they were 64-bit in x86-64 (the upper halves are not guaranteed to be zero - but in practice they very often are, which makes those bugs hard to spot otherwise). * easy benchmarking. Compile by running 'make checkasm'. Execute by running 'tests/checkasm/checkasm'. Optional arguments are '--bench' to run benchmarks for all functions, '--bench=<pattern>' to run benchmarks for all functions that starts with <pattern>, and '<integer>' to seed the PRNG for reproducible results. Contains unit tests for most h264pred functions to get started, more tests can be added afterwards using those as a reference. Loosely based on code from x264. Currently only supports x86 and x86-64, but additional architectures shouldn't be too much of an obstacle to add. Note that functions with floating point parameters or floating point return values are not supported. Some compiler-specific features or preprocessor hacks would likely be required to add support for that. Signed-off-by: Janne Grunau <janne-libav@jannau.net>
2015-07-11 20:32:11 +02:00
const char *bench_pattern;
int bench_pattern_len;
int num_checked;
int num_failed;
checkasm: use perf API on Linux ARM* On ARM platforms, accessing the PMU registers requires special user access permissions. Since there is no other way to get accurate timers, the current implementation of timers in FFmpeg rely on these registers. Unfortunately, enabling user access to these registers on Linux is not trivial, and generally involve compiling a random and unreliable github kernel module, or patching somehow your kernel. Such module is very unlikely to reach the upstream anytime soon. Quoting Robin Murphin from ARM: > Say you do give userspace direct access to the PMU; now run two or more > programs at once that believe they can use the counters for their own > "minimal-overhead" profiling. Have fun interpreting those results... > > And that's not even getting into the implications of scheduling across > different CPUs, CPUidle, etc. where the PMU state is completely beyond > userspace's control. In general, the plan to provide userspace with > something which might happen to just about work in a few corner cases, > but is meaningless, misleading or downright broken in all others, is to > never do so. As a result, the alternative is to use the Performance Monitoring Linux API which makes use of these registers internally (assuming the PMU of your ARM board is supported in the kernel, which is definitely not a given...). While the Linux API is obviously cross platform, it does have a significant overhead which needs to be taken into account. As a result, that mode is only weakly enabled on ARM platforms exclusively. Note on the non flexibility of the implementation: the timers (native FFmpeg vs Linux API) are selected at compilation time to prevent the need of function calls, which would result in a negative impact on the cycle counters.
2017-09-01 15:11:18 +02:00
/* perf */
Checkasm: assembly testing and benchmarking tool It provides the following features: * verify correctness by comparing output to the C version. * detect failure to save and restore clobbered callee-saved registers. * detect 32-bit parameters being used as if they were 64-bit in x86-64 (the upper halves are not guaranteed to be zero - but in practice they very often are, which makes those bugs hard to spot otherwise). * easy benchmarking. Compile by running 'make checkasm'. Execute by running 'tests/checkasm/checkasm'. Optional arguments are '--bench' to run benchmarks for all functions, '--bench=<pattern>' to run benchmarks for all functions that starts with <pattern>, and '<integer>' to seed the PRNG for reproducible results. Contains unit tests for most h264pred functions to get started, more tests can be added afterwards using those as a reference. Loosely based on code from x264. Currently only supports x86 and x86-64, but additional architectures shouldn't be too much of an obstacle to add. Note that functions with floating point parameters or floating point return values are not supported. Some compiler-specific features or preprocessor hacks would likely be required to add support for that. Signed-off-by: Janne Grunau <janne-libav@jannau.net>
2015-07-11 20:32:11 +02:00
int nop_time;
checkasm: use perf API on Linux ARM* On ARM platforms, accessing the PMU registers requires special user access permissions. Since there is no other way to get accurate timers, the current implementation of timers in FFmpeg rely on these registers. Unfortunately, enabling user access to these registers on Linux is not trivial, and generally involve compiling a random and unreliable github kernel module, or patching somehow your kernel. Such module is very unlikely to reach the upstream anytime soon. Quoting Robin Murphin from ARM: > Say you do give userspace direct access to the PMU; now run two or more > programs at once that believe they can use the counters for their own > "minimal-overhead" profiling. Have fun interpreting those results... > > And that's not even getting into the implications of scheduling across > different CPUs, CPUidle, etc. where the PMU state is completely beyond > userspace's control. In general, the plan to provide userspace with > something which might happen to just about work in a few corner cases, > but is meaningless, misleading or downright broken in all others, is to > never do so. As a result, the alternative is to use the Performance Monitoring Linux API which makes use of these registers internally (assuming the PMU of your ARM board is supported in the kernel, which is definitely not a given...). While the Linux API is obviously cross platform, it does have a significant overhead which needs to be taken into account. As a result, that mode is only weakly enabled on ARM platforms exclusively. Note on the non flexibility of the implementation: the timers (native FFmpeg vs Linux API) are selected at compilation time to prevent the need of function calls, which would result in a negative impact on the cycle counters.
2017-09-01 15:11:18 +02:00
int sysfd;
Checkasm: assembly testing and benchmarking tool It provides the following features: * verify correctness by comparing output to the C version. * detect failure to save and restore clobbered callee-saved registers. * detect 32-bit parameters being used as if they were 64-bit in x86-64 (the upper halves are not guaranteed to be zero - but in practice they very often are, which makes those bugs hard to spot otherwise). * easy benchmarking. Compile by running 'make checkasm'. Execute by running 'tests/checkasm/checkasm'. Optional arguments are '--bench' to run benchmarks for all functions, '--bench=<pattern>' to run benchmarks for all functions that starts with <pattern>, and '<integer>' to seed the PRNG for reproducible results. Contains unit tests for most h264pred functions to get started, more tests can be added afterwards using those as a reference. Loosely based on code from x264. Currently only supports x86 and x86-64, but additional architectures shouldn't be too much of an obstacle to add. Note that functions with floating point parameters or floating point return values are not supported. Some compiler-specific features or preprocessor hacks would likely be required to add support for that. Signed-off-by: Janne Grunau <janne-libav@jannau.net>
2015-07-11 20:32:11 +02:00
int cpu_flag;
const char *cpu_flag_name;
checkasm: Add --test parameter to check only specific components Inspired by a patch from Martin Storsjö <martin@martin.st>.
2016-11-04 00:40:26 +02:00
const char *test_name;
checkasm: add function to check and diff memory This was ported from dav1d (c950e7101bdf5f7117bfca816984a21e550509f0). Signed-off-by: Josh de Kock <josh@itanimul.li>
2019-06-20 22:38:06 +02:00
int verbose;
checkasm: Generalize crash handling This replaces the riscv specific handling from 7212466e735aa187d82f51dadbce957fe3da77f0 (which essentially is reverted), with a different implementation of the same (plus a bit more), based on the corresponding feature in dav1d's checkasm, supporting both Unix and Windows. See in particular the dav1d commits 0b6ee30eab2400e4f85b735ad29a68a842c34e21, 0421f787ea592fd2cc74c887f20b8dc31393788b, 8501a4b20135f93a4c3b426468e2240e872949c5 and d23e87f7aee26ddcf5f7a2e185112031477599a7, authored by Henrik Gramner. The overall approach compared to the existing implementation for riscv is the same; set up a signal handler, store the state with sigsetjmp, jump out of the crashing function with siglongjmp. The main difference is in what happens when the signal handler is invoked. In the previous implementation, it would resume from right before calling the crashing function, and then skip that call based on the setjmp return value. In the imported implementation from dav1d, we return to right before the check_func() call, which will skip testing the current function (as the pointer is the same as it was before). Other differences are: - Support for other signal handling mechanisms (Windows AddVectoredExceptionHandler) - Using RtlCaptureContext/RtlRestoreContext instead of setjmp/longjmp on Windows with SEH - Only catching signals once per function - if more than one signal is delivered before signal handling is reenabled, any signal is handled as it would without our handler - Not using an arch specific signal handler written in assembly Signed-off-by: Martin Storsjö <martin@martin.st>
2023-12-14 14:57:36 +02:00
volatile sig_atomic_t catch_signals;
Checkasm: assembly testing and benchmarking tool It provides the following features: * verify correctness by comparing output to the C version. * detect failure to save and restore clobbered callee-saved registers. * detect 32-bit parameters being used as if they were 64-bit in x86-64 (the upper halves are not guaranteed to be zero - but in practice they very often are, which makes those bugs hard to spot otherwise). * easy benchmarking. Compile by running 'make checkasm'. Execute by running 'tests/checkasm/checkasm'. Optional arguments are '--bench' to run benchmarks for all functions, '--bench=<pattern>' to run benchmarks for all functions that starts with <pattern>, and '<integer>' to seed the PRNG for reproducible results. Contains unit tests for most h264pred functions to get started, more tests can be added afterwards using those as a reference. Loosely based on code from x264. Currently only supports x86 and x86-64, but additional architectures shouldn't be too much of an obstacle to add. Note that functions with floating point parameters or floating point return values are not supported. Some compiler-specific features or preprocessor hacks would likely be required to add support for that. Signed-off-by: Janne Grunau <janne-libav@jannau.net>
2015-07-11 20:32:11 +02:00
} state;
/* PRNG state */
AVLFG checkasm_lfg;
checkasm: add float comparison util functions
2015-12-07 17:14:46 +02:00
/* float compare support code */
static int is_negative(union av_intfloat32 u)
{
return u.i >> 31;
}
int float_near_ulp(float a, float b, unsigned max_ulp)
{
union av_intfloat32 x, y;
x.f = a;
y.f = b;
if (is_negative(x) != is_negative(y)) {
// handle -0.0 == +0.0
return a == b;
}
checkasm: Cast unsigned to signed Avoid a warning for passing an unsigned value to abs(), some compilers might optimize away abs().
2016-07-19 05:26:33 +02:00
if (llabs((int64_t)x.i - y.i) <= max_ulp)
checkasm: add float comparison util functions
2015-12-07 17:14:46 +02:00
return 1;
return 0;
}
int float_near_ulp_array(const float *a, const float *b, unsigned max_ulp,
unsigned len)
{
unsigned i;
for (i = 0; i < len; i++) {
if (!float_near_ulp(a[i], b[i], max_ulp))
return 0;
}
return 1;
}
int float_near_abs_eps(float a, float b, float eps)
{
float abs_diff = fabsf(a - b);
tests/checkasm/checkasm: Provide verbose failure information on float_near_abs_eps() failures This will make understanding failures and adjusting EPS easier Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
2018-04-13 02:34:01 +02:00
if (abs_diff < eps)
return 1;
fprintf(stderr, "test failed comparing %g with %g (abs diff=%g with EPS=%g)\n", a, b, abs_diff, eps);
checkasm: add float comparison util functions
2015-12-07 17:14:46 +02:00
tests/checkasm/checkasm: Provide verbose failure information on float_near_abs_eps() failures This will make understanding failures and adjusting EPS easier Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
2018-04-13 02:34:01 +02:00
return 0;
checkasm: add float comparison util functions
2015-12-07 17:14:46 +02:00
}
int float_near_abs_eps_array(const float *a, const float *b, float eps,
unsigned len)
{
unsigned i;
for (i = 0; i < len; i++) {
if (!float_near_abs_eps(a[i], b[i], eps))
return 0;
}
return 1;
}
int float_near_abs_eps_ulp(float a, float b, float eps, unsigned max_ulp)
{
return float_near_ulp(a, b, max_ulp) || float_near_abs_eps(a, b, eps);
}
int float_near_abs_eps_array_ulp(const float *a, const float *b, float eps,
unsigned max_ulp, unsigned len)
{
unsigned i;
for (i = 0; i < len; i++) {
if (!float_near_abs_eps_ulp(a[i], b[i], eps, max_ulp))
return 0;
}
return 1;
}
checkasm: add float_dsp tests Ported from libavutil/tests/float_dsp.c Signed-off-by: James Almer <jamrial@gmail.com>
2017-04-11 22:16:56 +02:00
int double_near_abs_eps(double a, double b, double eps)
{
double abs_diff = fabs(a - b);
return abs_diff < eps;
}
int double_near_abs_eps_array(const double *a, const double *b, double eps,
unsigned len)
{
unsigned i;
for (i = 0; i < len; i++) {
if (!double_near_abs_eps(a[i], b[i], eps))
return 0;
}
return 1;
}
Checkasm: assembly testing and benchmarking tool It provides the following features: * verify correctness by comparing output to the C version. * detect failure to save and restore clobbered callee-saved registers. * detect 32-bit parameters being used as if they were 64-bit in x86-64 (the upper halves are not guaranteed to be zero - but in practice they very often are, which makes those bugs hard to spot otherwise). * easy benchmarking. Compile by running 'make checkasm'. Execute by running 'tests/checkasm/checkasm'. Optional arguments are '--bench' to run benchmarks for all functions, '--bench=<pattern>' to run benchmarks for all functions that starts with <pattern>, and '<integer>' to seed the PRNG for reproducible results. Contains unit tests for most h264pred functions to get started, more tests can be added afterwards using those as a reference. Loosely based on code from x264. Currently only supports x86 and x86-64, but additional architectures shouldn't be too much of an obstacle to add. Note that functions with floating point parameters or floating point return values are not supported. Some compiler-specific features or preprocessor hacks would likely be required to add support for that. Signed-off-by: Janne Grunau <janne-libav@jannau.net>
2015-07-11 20:32:11 +02:00
/* Print colored text to stderr if the terminal supports it */
static void color_printf(int color, const char *fmt, ...)
{
static int use_color = -1;
va_list arg;
checkasm: Check HAVE_GETSTDHANDLE here as well This was missed in 63418e374fcf26. Signed-off-by: Martin Storsjö <martin@martin.st>
2020-01-24 00:02:35 +02:00
#if HAVE_SETCONSOLETEXTATTRIBUTE && HAVE_GETSTDHANDLE
Checkasm: assembly testing and benchmarking tool It provides the following features: * verify correctness by comparing output to the C version. * detect failure to save and restore clobbered callee-saved registers. * detect 32-bit parameters being used as if they were 64-bit in x86-64 (the upper halves are not guaranteed to be zero - but in practice they very often are, which makes those bugs hard to spot otherwise). * easy benchmarking. Compile by running 'make checkasm'. Execute by running 'tests/checkasm/checkasm'. Optional arguments are '--bench' to run benchmarks for all functions, '--bench=<pattern>' to run benchmarks for all functions that starts with <pattern>, and '<integer>' to seed the PRNG for reproducible results. Contains unit tests for most h264pred functions to get started, more tests can be added afterwards using those as a reference. Loosely based on code from x264. Currently only supports x86 and x86-64, but additional architectures shouldn't be too much of an obstacle to add. Note that functions with floating point parameters or floating point return values are not supported. Some compiler-specific features or preprocessor hacks would likely be required to add support for that. Signed-off-by: Janne Grunau <janne-libav@jannau.net>
2015-07-11 20:32:11 +02:00
static HANDLE con;
static WORD org_attributes;
if (use_color < 0) {
CONSOLE_SCREEN_BUFFER_INFO con_info;
con = GetStdHandle(STD_ERROR_HANDLE);
if (con && con != INVALID_HANDLE_VALUE && GetConsoleScreenBufferInfo(con, &con_info)) {
org_attributes = con_info.wAttributes;
use_color = 1;
} else
use_color = 0;
}
if (use_color)
SetConsoleTextAttribute(con, (org_attributes & 0xfff0) | (color & 0x0f));
#else
if (use_color < 0) {
const char *term = getenv("TERM");
use_color = term && strcmp(term, "dumb") && isatty(2);
}
if (use_color)
fprintf(stderr, "\x1b[%d;3%dm", (color & 0x08) >> 3, color & 0x07);
#endif
va_start(arg, fmt);
vfprintf(stderr, fmt, arg);
va_end(arg);
if (use_color) {
checkasm: Check HAVE_GETSTDHANDLE here as well This was missed in 63418e374fcf26. Signed-off-by: Martin Storsjö <martin@martin.st>
2020-01-24 00:02:35 +02:00
#if HAVE_SETCONSOLETEXTATTRIBUTE && HAVE_GETSTDHANDLE
Checkasm: assembly testing and benchmarking tool It provides the following features: * verify correctness by comparing output to the C version. * detect failure to save and restore clobbered callee-saved registers. * detect 32-bit parameters being used as if they were 64-bit in x86-64 (the upper halves are not guaranteed to be zero - but in practice they very often are, which makes those bugs hard to spot otherwise). * easy benchmarking. Compile by running 'make checkasm'. Execute by running 'tests/checkasm/checkasm'. Optional arguments are '--bench' to run benchmarks for all functions, '--bench=<pattern>' to run benchmarks for all functions that starts with <pattern>, and '<integer>' to seed the PRNG for reproducible results. Contains unit tests for most h264pred functions to get started, more tests can be added afterwards using those as a reference. Loosely based on code from x264. Currently only supports x86 and x86-64, but additional architectures shouldn't be too much of an obstacle to add. Note that functions with floating point parameters or floating point return values are not supported. Some compiler-specific features or preprocessor hacks would likely be required to add support for that. Signed-off-by: Janne Grunau <janne-libav@jannau.net>
2015-07-11 20:32:11 +02:00
SetConsoleTextAttribute(con, org_attributes);
#else
fprintf(stderr, "\x1b[0m");
#endif
}
}
/* Deallocate a tree */
static void destroy_func_tree(CheckasmFunc *f)
{
if (f) {
CheckasmFuncVersion *v = f->versions.next;
while (v) {
CheckasmFuncVersion *next = v->next;
free(v);
v = next;
}
destroy_func_tree(f->child[0]);
destroy_func_tree(f->child[1]);
free(f);
}
}
/* Allocate a zero-initialized block, clean up and exit on failure */
static void *checkasm_malloc(size_t size)
{
void *ptr = calloc(1, size);
if (!ptr) {
fprintf(stderr, "checkasm: malloc failed\n");
destroy_func_tree(state.funcs);
exit(1);
}
return ptr;
}
/* Get the suffix of the specified cpu flag */
static const char *cpu_suffix(int cpu)
{
int i = FF_ARRAY_ELEMS(cpus);
while (--i >= 0)
if (cpu & cpus[i].flag)
return cpus[i].suffix;
return "c";
}
static int cmp_nop(const void *a, const void *b)
{
return *(const uint16_t*)a - *(const uint16_t*)b;
}
/* Measure the overhead of the timing code (in decicycles) */
static int measure_nop_time(void)
{
uint16_t nops[10000];
int i, nop_sum = 0;
checkasm: use perf API on Linux ARM* On ARM platforms, accessing the PMU registers requires special user access permissions. Since there is no other way to get accurate timers, the current implementation of timers in FFmpeg rely on these registers. Unfortunately, enabling user access to these registers on Linux is not trivial, and generally involve compiling a random and unreliable github kernel module, or patching somehow your kernel. Such module is very unlikely to reach the upstream anytime soon. Quoting Robin Murphin from ARM: > Say you do give userspace direct access to the PMU; now run two or more > programs at once that believe they can use the counters for their own > "minimal-overhead" profiling. Have fun interpreting those results... > > And that's not even getting into the implications of scheduling across > different CPUs, CPUidle, etc. where the PMU state is completely beyond > userspace's control. In general, the plan to provide userspace with > something which might happen to just about work in a few corner cases, > but is meaningless, misleading or downright broken in all others, is to > never do so. As a result, the alternative is to use the Performance Monitoring Linux API which makes use of these registers internally (assuming the PMU of your ARM board is supported in the kernel, which is definitely not a given...). While the Linux API is obviously cross platform, it does have a significant overhead which needs to be taken into account. As a result, that mode is only weakly enabled on ARM platforms exclusively. Note on the non flexibility of the implementation: the timers (native FFmpeg vs Linux API) are selected at compilation time to prevent the need of function calls, which would result in a negative impact on the cycle counters.
2017-09-01 15:11:18 +02:00
av_unused const int sysfd = state.sysfd;
Checkasm: assembly testing and benchmarking tool It provides the following features: * verify correctness by comparing output to the C version. * detect failure to save and restore clobbered callee-saved registers. * detect 32-bit parameters being used as if they were 64-bit in x86-64 (the upper halves are not guaranteed to be zero - but in practice they very often are, which makes those bugs hard to spot otherwise). * easy benchmarking. Compile by running 'make checkasm'. Execute by running 'tests/checkasm/checkasm'. Optional arguments are '--bench' to run benchmarks for all functions, '--bench=<pattern>' to run benchmarks for all functions that starts with <pattern>, and '<integer>' to seed the PRNG for reproducible results. Contains unit tests for most h264pred functions to get started, more tests can be added afterwards using those as a reference. Loosely based on code from x264. Currently only supports x86 and x86-64, but additional architectures shouldn't be too much of an obstacle to add. Note that functions with floating point parameters or floating point return values are not supported. Some compiler-specific features or preprocessor hacks would likely be required to add support for that. Signed-off-by: Janne Grunau <janne-libav@jannau.net>
2015-07-11 20:32:11 +02:00
checkasm: use perf API on Linux ARM* On ARM platforms, accessing the PMU registers requires special user access permissions. Since there is no other way to get accurate timers, the current implementation of timers in FFmpeg rely on these registers. Unfortunately, enabling user access to these registers on Linux is not trivial, and generally involve compiling a random and unreliable github kernel module, or patching somehow your kernel. Such module is very unlikely to reach the upstream anytime soon. Quoting Robin Murphin from ARM: > Say you do give userspace direct access to the PMU; now run two or more > programs at once that believe they can use the counters for their own > "minimal-overhead" profiling. Have fun interpreting those results... > > And that's not even getting into the implications of scheduling across > different CPUs, CPUidle, etc. where the PMU state is completely beyond > userspace's control. In general, the plan to provide userspace with > something which might happen to just about work in a few corner cases, > but is meaningless, misleading or downright broken in all others, is to > never do so. As a result, the alternative is to use the Performance Monitoring Linux API which makes use of these registers internally (assuming the PMU of your ARM board is supported in the kernel, which is definitely not a given...). While the Linux API is obviously cross platform, it does have a significant overhead which needs to be taken into account. As a result, that mode is only weakly enabled on ARM platforms exclusively. Note on the non flexibility of the implementation: the timers (native FFmpeg vs Linux API) are selected at compilation time to prevent the need of function calls, which would result in a negative impact on the cycle counters.
2017-09-01 15:11:18 +02:00
uint64_t t = 0;
Checkasm: assembly testing and benchmarking tool It provides the following features: * verify correctness by comparing output to the C version. * detect failure to save and restore clobbered callee-saved registers. * detect 32-bit parameters being used as if they were 64-bit in x86-64 (the upper halves are not guaranteed to be zero - but in practice they very often are, which makes those bugs hard to spot otherwise). * easy benchmarking. Compile by running 'make checkasm'. Execute by running 'tests/checkasm/checkasm'. Optional arguments are '--bench' to run benchmarks for all functions, '--bench=<pattern>' to run benchmarks for all functions that starts with <pattern>, and '<integer>' to seed the PRNG for reproducible results. Contains unit tests for most h264pred functions to get started, more tests can be added afterwards using those as a reference. Loosely based on code from x264. Currently only supports x86 and x86-64, but additional architectures shouldn't be too much of an obstacle to add. Note that functions with floating point parameters or floating point return values are not supported. Some compiler-specific features or preprocessor hacks would likely be required to add support for that. Signed-off-by: Janne Grunau <janne-libav@jannau.net>
2015-07-11 20:32:11 +02:00
for (i = 0; i < 10000; i++) {
checkasm: use perf API on Linux ARM* On ARM platforms, accessing the PMU registers requires special user access permissions. Since there is no other way to get accurate timers, the current implementation of timers in FFmpeg rely on these registers. Unfortunately, enabling user access to these registers on Linux is not trivial, and generally involve compiling a random and unreliable github kernel module, or patching somehow your kernel. Such module is very unlikely to reach the upstream anytime soon. Quoting Robin Murphin from ARM: > Say you do give userspace direct access to the PMU; now run two or more > programs at once that believe they can use the counters for their own > "minimal-overhead" profiling. Have fun interpreting those results... > > And that's not even getting into the implications of scheduling across > different CPUs, CPUidle, etc. where the PMU state is completely beyond > userspace's control. In general, the plan to provide userspace with > something which might happen to just about work in a few corner cases, > but is meaningless, misleading or downright broken in all others, is to > never do so. As a result, the alternative is to use the Performance Monitoring Linux API which makes use of these registers internally (assuming the PMU of your ARM board is supported in the kernel, which is definitely not a given...). While the Linux API is obviously cross platform, it does have a significant overhead which needs to be taken into account. As a result, that mode is only weakly enabled on ARM platforms exclusively. Note on the non flexibility of the implementation: the timers (native FFmpeg vs Linux API) are selected at compilation time to prevent the need of function calls, which would result in a negative impact on the cycle counters.
2017-09-01 15:11:18 +02:00
PERF_START(t);
PERF_STOP(t);
nops[i] = t;
Checkasm: assembly testing and benchmarking tool It provides the following features: * verify correctness by comparing output to the C version. * detect failure to save and restore clobbered callee-saved registers. * detect 32-bit parameters being used as if they were 64-bit in x86-64 (the upper halves are not guaranteed to be zero - but in practice they very often are, which makes those bugs hard to spot otherwise). * easy benchmarking. Compile by running 'make checkasm'. Execute by running 'tests/checkasm/checkasm'. Optional arguments are '--bench' to run benchmarks for all functions, '--bench=<pattern>' to run benchmarks for all functions that starts with <pattern>, and '<integer>' to seed the PRNG for reproducible results. Contains unit tests for most h264pred functions to get started, more tests can be added afterwards using those as a reference. Loosely based on code from x264. Currently only supports x86 and x86-64, but additional architectures shouldn't be too much of an obstacle to add. Note that functions with floating point parameters or floating point return values are not supported. Some compiler-specific features or preprocessor hacks would likely be required to add support for that. Signed-off-by: Janne Grunau <janne-libav@jannau.net>
2015-07-11 20:32:11 +02:00
}
qsort(nops, 10000, sizeof(uint16_t), cmp_nop);
for (i = 2500; i < 7500; i++)
nop_sum += nops[i];
return nop_sum / 500;
}
/* Print benchmark results */
static void print_benchs(CheckasmFunc *f)
{
if (f) {
print_benchs(f->child[0]);
/* Only print functions with at least one assembly version */
if (f->versions.cpu || f->versions.next) {
CheckasmFuncVersion *v = &f->versions;
do {
checkasm: use perf API on Linux ARM* On ARM platforms, accessing the PMU registers requires special user access permissions. Since there is no other way to get accurate timers, the current implementation of timers in FFmpeg rely on these registers. Unfortunately, enabling user access to these registers on Linux is not trivial, and generally involve compiling a random and unreliable github kernel module, or patching somehow your kernel. Such module is very unlikely to reach the upstream anytime soon. Quoting Robin Murphin from ARM: > Say you do give userspace direct access to the PMU; now run two or more > programs at once that believe they can use the counters for their own > "minimal-overhead" profiling. Have fun interpreting those results... > > And that's not even getting into the implications of scheduling across > different CPUs, CPUidle, etc. where the PMU state is completely beyond > userspace's control. In general, the plan to provide userspace with > something which might happen to just about work in a few corner cases, > but is meaningless, misleading or downright broken in all others, is to > never do so. As a result, the alternative is to use the Performance Monitoring Linux API which makes use of these registers internally (assuming the PMU of your ARM board is supported in the kernel, which is definitely not a given...). While the Linux API is obviously cross platform, it does have a significant overhead which needs to be taken into account. As a result, that mode is only weakly enabled on ARM platforms exclusively. Note on the non flexibility of the implementation: the timers (native FFmpeg vs Linux API) are selected at compilation time to prevent the need of function calls, which would result in a negative impact on the cycle counters.
2017-09-01 15:11:18 +02:00
CheckasmPerf *p = &v->perf;
if (p->iterations) {
int decicycles = (10*p->cycles/p->iterations - state.nop_time) / 4;
Checkasm: assembly testing and benchmarking tool It provides the following features: * verify correctness by comparing output to the C version. * detect failure to save and restore clobbered callee-saved registers. * detect 32-bit parameters being used as if they were 64-bit in x86-64 (the upper halves are not guaranteed to be zero - but in practice they very often are, which makes those bugs hard to spot otherwise). * easy benchmarking. Compile by running 'make checkasm'. Execute by running 'tests/checkasm/checkasm'. Optional arguments are '--bench' to run benchmarks for all functions, '--bench=<pattern>' to run benchmarks for all functions that starts with <pattern>, and '<integer>' to seed the PRNG for reproducible results. Contains unit tests for most h264pred functions to get started, more tests can be added afterwards using those as a reference. Loosely based on code from x264. Currently only supports x86 and x86-64, but additional architectures shouldn't be too much of an obstacle to add. Note that functions with floating point parameters or floating point return values are not supported. Some compiler-specific features or preprocessor hacks would likely be required to add support for that. Signed-off-by: Janne Grunau <janne-libav@jannau.net>
2015-07-11 20:32:11 +02:00
printf("%s_%s: %d.%d\n", f->name, cpu_suffix(v->cpu), decicycles/10, decicycles%10);
}
} while ((v = v->next));
}
print_benchs(f->child[1]);
}
}
/* ASCIIbetical sort except preserving natural order for numbers */
static int cmp_func_names(const char *a, const char *b)
{
checkasm: Fix the function name sorting algorithm The previous implementation was behaving incorrectly in some corner cases.
2015-09-26 20:15:35 +02:00
const char *start = a;
Checkasm: assembly testing and benchmarking tool It provides the following features: * verify correctness by comparing output to the C version. * detect failure to save and restore clobbered callee-saved registers. * detect 32-bit parameters being used as if they were 64-bit in x86-64 (the upper halves are not guaranteed to be zero - but in practice they very often are, which makes those bugs hard to spot otherwise). * easy benchmarking. Compile by running 'make checkasm'. Execute by running 'tests/checkasm/checkasm'. Optional arguments are '--bench' to run benchmarks for all functions, '--bench=<pattern>' to run benchmarks for all functions that starts with <pattern>, and '<integer>' to seed the PRNG for reproducible results. Contains unit tests for most h264pred functions to get started, more tests can be added afterwards using those as a reference. Loosely based on code from x264. Currently only supports x86 and x86-64, but additional architectures shouldn't be too much of an obstacle to add. Note that functions with floating point parameters or floating point return values are not supported. Some compiler-specific features or preprocessor hacks would likely be required to add support for that. Signed-off-by: Janne Grunau <janne-libav@jannau.net>
2015-07-11 20:32:11 +02:00
int ascii_diff, digit_diff;
checkasm: Fix the function name sorting algorithm The previous implementation was behaving incorrectly in some corner cases.
2015-09-26 20:15:35 +02:00
for (; !(ascii_diff = *(const unsigned char*)a - *(const unsigned char*)b) && *a; a++, b++);
Checkasm: assembly testing and benchmarking tool It provides the following features: * verify correctness by comparing output to the C version. * detect failure to save and restore clobbered callee-saved registers. * detect 32-bit parameters being used as if they were 64-bit in x86-64 (the upper halves are not guaranteed to be zero - but in practice they very often are, which makes those bugs hard to spot otherwise). * easy benchmarking. Compile by running 'make checkasm'. Execute by running 'tests/checkasm/checkasm'. Optional arguments are '--bench' to run benchmarks for all functions, '--bench=<pattern>' to run benchmarks for all functions that starts with <pattern>, and '<integer>' to seed the PRNG for reproducible results. Contains unit tests for most h264pred functions to get started, more tests can be added afterwards using those as a reference. Loosely based on code from x264. Currently only supports x86 and x86-64, but additional architectures shouldn't be too much of an obstacle to add. Note that functions with floating point parameters or floating point return values are not supported. Some compiler-specific features or preprocessor hacks would likely be required to add support for that. Signed-off-by: Janne Grunau <janne-libav@jannau.net>
2015-07-11 20:32:11 +02:00
for (; av_isdigit(*a) && av_isdigit(*b); a++, b++);
checkasm: Fix the function name sorting algorithm The previous implementation was behaving incorrectly in some corner cases.
2015-09-26 20:15:35 +02:00
if (a > start && av_isdigit(a[-1]) && (digit_diff = av_isdigit(*a) - av_isdigit(*b)))
return digit_diff;
return ascii_diff;
Checkasm: assembly testing and benchmarking tool It provides the following features: * verify correctness by comparing output to the C version. * detect failure to save and restore clobbered callee-saved registers. * detect 32-bit parameters being used as if they were 64-bit in x86-64 (the upper halves are not guaranteed to be zero - but in practice they very often are, which makes those bugs hard to spot otherwise). * easy benchmarking. Compile by running 'make checkasm'. Execute by running 'tests/checkasm/checkasm'. Optional arguments are '--bench' to run benchmarks for all functions, '--bench=<pattern>' to run benchmarks for all functions that starts with <pattern>, and '<integer>' to seed the PRNG for reproducible results. Contains unit tests for most h264pred functions to get started, more tests can be added afterwards using those as a reference. Loosely based on code from x264. Currently only supports x86 and x86-64, but additional architectures shouldn't be too much of an obstacle to add. Note that functions with floating point parameters or floating point return values are not supported. Some compiler-specific features or preprocessor hacks would likely be required to add support for that. Signed-off-by: Janne Grunau <janne-libav@jannau.net>
2015-07-11 20:32:11 +02:00
}
checkasm: Use a self-balancing tree Tested functions are internally kept in a binary search tree for efficient lookups. The downside of the current implementation is that the tree quickly becomes unbalanced which causes an unneccessary amount of comparisons between nodes. Improve this by changing the tree into a self-balancing left-leaning red-black tree with a worst case lookup/insertion time complexity of O(log n). Significantly reduces the recursion depth and makes the tests run around 10% faster overall. The relative performance improvement compared to the existing non-balanced tree will also most likely increase as more tests are added.
2015-09-25 18:56:00 +02:00
/* Perform a tree rotation in the specified direction and return the new root */
static CheckasmFunc *rotate_tree(CheckasmFunc *f, int dir)
{
CheckasmFunc *r = f->child[dir^1];
f->child[dir^1] = r->child[dir];
r->child[dir] = f;
r->color = f->color;
f->color = 0;
return r;
}
#define is_red(f) ((f) && !(f)->color)
/* Balance a left-leaning red-black tree at the specified node */
static void balance_tree(CheckasmFunc **root)
{
CheckasmFunc *f = *root;
if (is_red(f->child[0]) && is_red(f->child[1])) {
f->color ^= 1;
f->child[0]->color = f->child[1]->color = 1;
}
if (!is_red(f->child[0]) && is_red(f->child[1]))
*root = rotate_tree(f, 0); /* Rotate left */
else if (is_red(f->child[0]) && is_red(f->child[0]->child[0]))
*root = rotate_tree(f, 1); /* Rotate right */
}
Checkasm: assembly testing and benchmarking tool It provides the following features: * verify correctness by comparing output to the C version. * detect failure to save and restore clobbered callee-saved registers. * detect 32-bit parameters being used as if they were 64-bit in x86-64 (the upper halves are not guaranteed to be zero - but in practice they very often are, which makes those bugs hard to spot otherwise). * easy benchmarking. Compile by running 'make checkasm'. Execute by running 'tests/checkasm/checkasm'. Optional arguments are '--bench' to run benchmarks for all functions, '--bench=<pattern>' to run benchmarks for all functions that starts with <pattern>, and '<integer>' to seed the PRNG for reproducible results. Contains unit tests for most h264pred functions to get started, more tests can be added afterwards using those as a reference. Loosely based on code from x264. Currently only supports x86 and x86-64, but additional architectures shouldn't be too much of an obstacle to add. Note that functions with floating point parameters or floating point return values are not supported. Some compiler-specific features or preprocessor hacks would likely be required to add support for that. Signed-off-by: Janne Grunau <janne-libav@jannau.net>
2015-07-11 20:32:11 +02:00
/* Get a node with the specified name, creating it if it doesn't exist */
checkasm: Use a self-balancing tree Tested functions are internally kept in a binary search tree for efficient lookups. The downside of the current implementation is that the tree quickly becomes unbalanced which causes an unneccessary amount of comparisons between nodes. Improve this by changing the tree into a self-balancing left-leaning red-black tree with a worst case lookup/insertion time complexity of O(log n). Significantly reduces the recursion depth and makes the tests run around 10% faster overall. The relative performance improvement compared to the existing non-balanced tree will also most likely increase as more tests are added.
2015-09-25 18:56:00 +02:00
static CheckasmFunc *get_func(CheckasmFunc **root, const char *name)
Checkasm: assembly testing and benchmarking tool It provides the following features: * verify correctness by comparing output to the C version. * detect failure to save and restore clobbered callee-saved registers. * detect 32-bit parameters being used as if they were 64-bit in x86-64 (the upper halves are not guaranteed to be zero - but in practice they very often are, which makes those bugs hard to spot otherwise). * easy benchmarking. Compile by running 'make checkasm'. Execute by running 'tests/checkasm/checkasm'. Optional arguments are '--bench' to run benchmarks for all functions, '--bench=<pattern>' to run benchmarks for all functions that starts with <pattern>, and '<integer>' to seed the PRNG for reproducible results. Contains unit tests for most h264pred functions to get started, more tests can be added afterwards using those as a reference. Loosely based on code from x264. Currently only supports x86 and x86-64, but additional architectures shouldn't be too much of an obstacle to add. Note that functions with floating point parameters or floating point return values are not supported. Some compiler-specific features or preprocessor hacks would likely be required to add support for that. Signed-off-by: Janne Grunau <janne-libav@jannau.net>
2015-07-11 20:32:11 +02:00
{
checkasm: Use a self-balancing tree Tested functions are internally kept in a binary search tree for efficient lookups. The downside of the current implementation is that the tree quickly becomes unbalanced which causes an unneccessary amount of comparisons between nodes. Improve this by changing the tree into a self-balancing left-leaning red-black tree with a worst case lookup/insertion time complexity of O(log n). Significantly reduces the recursion depth and makes the tests run around 10% faster overall. The relative performance improvement compared to the existing non-balanced tree will also most likely increase as more tests are added.
2015-09-25 18:56:00 +02:00
CheckasmFunc *f = *root;
Checkasm: assembly testing and benchmarking tool It provides the following features: * verify correctness by comparing output to the C version. * detect failure to save and restore clobbered callee-saved registers. * detect 32-bit parameters being used as if they were 64-bit in x86-64 (the upper halves are not guaranteed to be zero - but in practice they very often are, which makes those bugs hard to spot otherwise). * easy benchmarking. Compile by running 'make checkasm'. Execute by running 'tests/checkasm/checkasm'. Optional arguments are '--bench' to run benchmarks for all functions, '--bench=<pattern>' to run benchmarks for all functions that starts with <pattern>, and '<integer>' to seed the PRNG for reproducible results. Contains unit tests for most h264pred functions to get started, more tests can be added afterwards using those as a reference. Loosely based on code from x264. Currently only supports x86 and x86-64, but additional architectures shouldn't be too much of an obstacle to add. Note that functions with floating point parameters or floating point return values are not supported. Some compiler-specific features or preprocessor hacks would likely be required to add support for that. Signed-off-by: Janne Grunau <janne-libav@jannau.net>
2015-07-11 20:32:11 +02:00
checkasm: Use a self-balancing tree Tested functions are internally kept in a binary search tree for efficient lookups. The downside of the current implementation is that the tree quickly becomes unbalanced which causes an unneccessary amount of comparisons between nodes. Improve this by changing the tree into a self-balancing left-leaning red-black tree with a worst case lookup/insertion time complexity of O(log n). Significantly reduces the recursion depth and makes the tests run around 10% faster overall. The relative performance improvement compared to the existing non-balanced tree will also most likely increase as more tests are added.
2015-09-25 18:56:00 +02:00
if (f) {
/* Search the tree for a matching node */
Checkasm: assembly testing and benchmarking tool It provides the following features: * verify correctness by comparing output to the C version. * detect failure to save and restore clobbered callee-saved registers. * detect 32-bit parameters being used as if they were 64-bit in x86-64 (the upper halves are not guaranteed to be zero - but in practice they very often are, which makes those bugs hard to spot otherwise). * easy benchmarking. Compile by running 'make checkasm'. Execute by running 'tests/checkasm/checkasm'. Optional arguments are '--bench' to run benchmarks for all functions, '--bench=<pattern>' to run benchmarks for all functions that starts with <pattern>, and '<integer>' to seed the PRNG for reproducible results. Contains unit tests for most h264pred functions to get started, more tests can be added afterwards using those as a reference. Loosely based on code from x264. Currently only supports x86 and x86-64, but additional architectures shouldn't be too much of an obstacle to add. Note that functions with floating point parameters or floating point return values are not supported. Some compiler-specific features or preprocessor hacks would likely be required to add support for that. Signed-off-by: Janne Grunau <janne-libav@jannau.net>
2015-07-11 20:32:11 +02:00
int cmp = cmp_func_names(name, f->name);
checkasm: Use a self-balancing tree Tested functions are internally kept in a binary search tree for efficient lookups. The downside of the current implementation is that the tree quickly becomes unbalanced which causes an unneccessary amount of comparisons between nodes. Improve this by changing the tree into a self-balancing left-leaning red-black tree with a worst case lookup/insertion time complexity of O(log n). Significantly reduces the recursion depth and makes the tests run around 10% faster overall. The relative performance improvement compared to the existing non-balanced tree will also most likely increase as more tests are added.
2015-09-25 18:56:00 +02:00
if (cmp) {
f = get_func(&f->child[cmp > 0], name);
Checkasm: assembly testing and benchmarking tool It provides the following features: * verify correctness by comparing output to the C version. * detect failure to save and restore clobbered callee-saved registers. * detect 32-bit parameters being used as if they were 64-bit in x86-64 (the upper halves are not guaranteed to be zero - but in practice they very often are, which makes those bugs hard to spot otherwise). * easy benchmarking. Compile by running 'make checkasm'. Execute by running 'tests/checkasm/checkasm'. Optional arguments are '--bench' to run benchmarks for all functions, '--bench=<pattern>' to run benchmarks for all functions that starts with <pattern>, and '<integer>' to seed the PRNG for reproducible results. Contains unit tests for most h264pred functions to get started, more tests can be added afterwards using those as a reference. Loosely based on code from x264. Currently only supports x86 and x86-64, but additional architectures shouldn't be too much of an obstacle to add. Note that functions with floating point parameters or floating point return values are not supported. Some compiler-specific features or preprocessor hacks would likely be required to add support for that. Signed-off-by: Janne Grunau <janne-libav@jannau.net>
2015-07-11 20:32:11 +02:00
checkasm: Use a self-balancing tree Tested functions are internally kept in a binary search tree for efficient lookups. The downside of the current implementation is that the tree quickly becomes unbalanced which causes an unneccessary amount of comparisons between nodes. Improve this by changing the tree into a self-balancing left-leaning red-black tree with a worst case lookup/insertion time complexity of O(log n). Significantly reduces the recursion depth and makes the tests run around 10% faster overall. The relative performance improvement compared to the existing non-balanced tree will also most likely increase as more tests are added.
2015-09-25 18:56:00 +02:00
/* Rebalance the tree on the way up if a new node was inserted */
if (!f->versions.func)
balance_tree(root);
}
} else {
/* Allocate and insert a new node into the tree */
int name_length = strlen(name);
f = *root = checkasm_malloc(sizeof(CheckasmFunc) + name_length);
memcpy(f->name, name, name_length + 1);
Checkasm: assembly testing and benchmarking tool It provides the following features: * verify correctness by comparing output to the C version. * detect failure to save and restore clobbered callee-saved registers. * detect 32-bit parameters being used as if they were 64-bit in x86-64 (the upper halves are not guaranteed to be zero - but in practice they very often are, which makes those bugs hard to spot otherwise). * easy benchmarking. Compile by running 'make checkasm'. Execute by running 'tests/checkasm/checkasm'. Optional arguments are '--bench' to run benchmarks for all functions, '--bench=<pattern>' to run benchmarks for all functions that starts with <pattern>, and '<integer>' to seed the PRNG for reproducible results. Contains unit tests for most h264pred functions to get started, more tests can be added afterwards using those as a reference. Loosely based on code from x264. Currently only supports x86 and x86-64, but additional architectures shouldn't be too much of an obstacle to add. Note that functions with floating point parameters or floating point return values are not supported. Some compiler-specific features or preprocessor hacks would likely be required to add support for that. Signed-off-by: Janne Grunau <janne-libav@jannau.net>
2015-07-11 20:32:11 +02:00
}
return f;
}
checkasm: Generalize crash handling This replaces the riscv specific handling from 7212466e735aa187d82f51dadbce957fe3da77f0 (which essentially is reverted), with a different implementation of the same (plus a bit more), based on the corresponding feature in dav1d's checkasm, supporting both Unix and Windows. See in particular the dav1d commits 0b6ee30eab2400e4f85b735ad29a68a842c34e21, 0421f787ea592fd2cc74c887f20b8dc31393788b, 8501a4b20135f93a4c3b426468e2240e872949c5 and d23e87f7aee26ddcf5f7a2e185112031477599a7, authored by Henrik Gramner. The overall approach compared to the existing implementation for riscv is the same; set up a signal handler, store the state with sigsetjmp, jump out of the crashing function with siglongjmp. The main difference is in what happens when the signal handler is invoked. In the previous implementation, it would resume from right before calling the crashing function, and then skip that call based on the setjmp return value. In the imported implementation from dav1d, we return to right before the check_func() call, which will skip testing the current function (as the pointer is the same as it was before). Other differences are: - Support for other signal handling mechanisms (Windows AddVectoredExceptionHandler) - Using RtlCaptureContext/RtlRestoreContext instead of setjmp/longjmp on Windows with SEH - Only catching signals once per function - if more than one signal is delivered before signal handling is reenabled, any signal is handled as it would without our handler - Not using an arch specific signal handler written in assembly Signed-off-by: Martin Storsjö <martin@martin.st>
2023-12-14 14:57:36 +02:00
checkasm_context checkasm_context_buf;
/* Crash handling: attempt to catch crashes and handle them
* gracefully instead of just aborting abruptly. */
#ifdef _WIN32
#if WINAPI_FAMILY_PARTITION(WINAPI_PARTITION_DESKTOP)
static LONG NTAPI signal_handler(EXCEPTION_POINTERS *e) {
int s;
if (!state.catch_signals)
return EXCEPTION_CONTINUE_SEARCH;
switch (e->ExceptionRecord->ExceptionCode) {
case EXCEPTION_FLT_DIVIDE_BY_ZERO:
case EXCEPTION_INT_DIVIDE_BY_ZERO:
s = SIGFPE;
break;
case EXCEPTION_ILLEGAL_INSTRUCTION:
case EXCEPTION_PRIV_INSTRUCTION:
s = SIGILL;
break;
case EXCEPTION_ACCESS_VIOLATION:
case EXCEPTION_ARRAY_BOUNDS_EXCEEDED:
case EXCEPTION_DATATYPE_MISALIGNMENT:
case EXCEPTION_STACK_OVERFLOW:
s = SIGSEGV;
break;
case EXCEPTION_IN_PAGE_ERROR:
s = SIGBUS;
break;
default:
return EXCEPTION_CONTINUE_SEARCH;
}
state.catch_signals = 0;
checkasm_load_context(s);
return EXCEPTION_CONTINUE_EXECUTION; /* never reached, but shuts up gcc */
}
#endif
#else
static void signal_handler(int s);
static const struct sigaction signal_handler_act = {
.sa_handler = signal_handler,
.sa_flags = SA_RESETHAND,
};
static void signal_handler(int s) {
if (state.catch_signals) {
state.catch_signals = 0;
sigaction(s, &signal_handler_act, NULL);
checkasm_load_context(s);
}
}
#endif
Checkasm: assembly testing and benchmarking tool It provides the following features: * verify correctness by comparing output to the C version. * detect failure to save and restore clobbered callee-saved registers. * detect 32-bit parameters being used as if they were 64-bit in x86-64 (the upper halves are not guaranteed to be zero - but in practice they very often are, which makes those bugs hard to spot otherwise). * easy benchmarking. Compile by running 'make checkasm'. Execute by running 'tests/checkasm/checkasm'. Optional arguments are '--bench' to run benchmarks for all functions, '--bench=<pattern>' to run benchmarks for all functions that starts with <pattern>, and '<integer>' to seed the PRNG for reproducible results. Contains unit tests for most h264pred functions to get started, more tests can be added afterwards using those as a reference. Loosely based on code from x264. Currently only supports x86 and x86-64, but additional architectures shouldn't be too much of an obstacle to add. Note that functions with floating point parameters or floating point return values are not supported. Some compiler-specific features or preprocessor hacks would likely be required to add support for that. Signed-off-by: Janne Grunau <janne-libav@jannau.net>
2015-07-11 20:32:11 +02:00
/* Perform tests and benchmarks for the specified cpu flag if supported by the host */
static void check_cpu_flag(const char *name, int flag)
{
int old_cpu_flag = state.cpu_flag;
flag |= old_cpu_flag;
checkasm: Remove use of deprecated av_set_cpu_flags_mask()
2015-09-26 15:43:49 +02:00
av_force_cpu_flags(-1);
state.cpu_flag = flag & av_get_cpu_flags();
av_force_cpu_flags(state.cpu_flag);
Checkasm: assembly testing and benchmarking tool It provides the following features: * verify correctness by comparing output to the C version. * detect failure to save and restore clobbered callee-saved registers. * detect 32-bit parameters being used as if they were 64-bit in x86-64 (the upper halves are not guaranteed to be zero - but in practice they very often are, which makes those bugs hard to spot otherwise). * easy benchmarking. Compile by running 'make checkasm'. Execute by running 'tests/checkasm/checkasm'. Optional arguments are '--bench' to run benchmarks for all functions, '--bench=<pattern>' to run benchmarks for all functions that starts with <pattern>, and '<integer>' to seed the PRNG for reproducible results. Contains unit tests for most h264pred functions to get started, more tests can be added afterwards using those as a reference. Loosely based on code from x264. Currently only supports x86 and x86-64, but additional architectures shouldn't be too much of an obstacle to add. Note that functions with floating point parameters or floating point return values are not supported. Some compiler-specific features or preprocessor hacks would likely be required to add support for that. Signed-off-by: Janne Grunau <janne-libav@jannau.net>
2015-07-11 20:32:11 +02:00
if (!flag || state.cpu_flag != old_cpu_flag) {
int i;
state.cpu_flag_name = name;
checkasm: Modify report format Makes it a bit more clear where each test belongs. Suggested by Anton Khirnov. Signed-off-by: Anton Khirnov <anton@khirnov.net>
2015-07-24 23:46:20 +02:00
for (i = 0; tests[i].func; i++) {
checkasm: Add --test parameter to check only specific components Inspired by a patch from Martin Storsjö <martin@martin.st>.
2016-11-04 00:40:26 +02:00
if (state.test_name && strcmp(tests[i].name, state.test_name))
continue;
checkasm: Modify report format Makes it a bit more clear where each test belongs. Suggested by Anton Khirnov. Signed-off-by: Anton Khirnov <anton@khirnov.net>
2015-07-24 23:46:20 +02:00
state.current_test_name = tests[i].name;
tests[i].func();
}
Checkasm: assembly testing and benchmarking tool It provides the following features: * verify correctness by comparing output to the C version. * detect failure to save and restore clobbered callee-saved registers. * detect 32-bit parameters being used as if they were 64-bit in x86-64 (the upper halves are not guaranteed to be zero - but in practice they very often are, which makes those bugs hard to spot otherwise). * easy benchmarking. Compile by running 'make checkasm'. Execute by running 'tests/checkasm/checkasm'. Optional arguments are '--bench' to run benchmarks for all functions, '--bench=<pattern>' to run benchmarks for all functions that starts with <pattern>, and '<integer>' to seed the PRNG for reproducible results. Contains unit tests for most h264pred functions to get started, more tests can be added afterwards using those as a reference. Loosely based on code from x264. Currently only supports x86 and x86-64, but additional architectures shouldn't be too much of an obstacle to add. Note that functions with floating point parameters or floating point return values are not supported. Some compiler-specific features or preprocessor hacks would likely be required to add support for that. Signed-off-by: Janne Grunau <janne-libav@jannau.net>
2015-07-11 20:32:11 +02:00
}
}
/* Print the name of the current CPU flag, but only do it once */
static void print_cpu_name(void)
{
if (state.cpu_flag_name) {
color_printf(COLOR_YELLOW, "%s:\n", state.cpu_flag_name);
state.cpu_flag_name = NULL;
}
}
checkasm: use perf API on Linux ARM* On ARM platforms, accessing the PMU registers requires special user access permissions. Since there is no other way to get accurate timers, the current implementation of timers in FFmpeg rely on these registers. Unfortunately, enabling user access to these registers on Linux is not trivial, and generally involve compiling a random and unreliable github kernel module, or patching somehow your kernel. Such module is very unlikely to reach the upstream anytime soon. Quoting Robin Murphin from ARM: > Say you do give userspace direct access to the PMU; now run two or more > programs at once that believe they can use the counters for their own > "minimal-overhead" profiling. Have fun interpreting those results... > > And that's not even getting into the implications of scheduling across > different CPUs, CPUidle, etc. where the PMU state is completely beyond > userspace's control. In general, the plan to provide userspace with > something which might happen to just about work in a few corner cases, > but is meaningless, misleading or downright broken in all others, is to > never do so. As a result, the alternative is to use the Performance Monitoring Linux API which makes use of these registers internally (assuming the PMU of your ARM board is supported in the kernel, which is definitely not a given...). While the Linux API is obviously cross platform, it does have a significant overhead which needs to be taken into account. As a result, that mode is only weakly enabled on ARM platforms exclusively. Note on the non flexibility of the implementation: the timers (native FFmpeg vs Linux API) are selected at compilation time to prevent the need of function calls, which would result in a negative impact on the cycle counters.
2017-09-01 15:11:18 +02:00
#if CONFIG_LINUX_PERF
static int bench_init_linux(void)
{
struct perf_event_attr attr = {
.type = PERF_TYPE_HARDWARE,
.size = sizeof(struct perf_event_attr),
.config = PERF_COUNT_HW_CPU_CYCLES,
.disabled = 1, // start counting only on demand
.exclude_kernel = 1,
.exclude_hv = 1,
};
printf("benchmarking with Linux Perf Monitoring API\n");
state.sysfd = syscall(__NR_perf_event_open, &attr, 0, -1, -1, 0);
if (state.sysfd == -1) {
checkasm: improve Linux perf error message Report the failing system call name, as is convention, rather than just a rather unhelpful "syscall".
2023-07-14 19:08:37 +02:00
perror("perf_event_open");
checkasm: use perf API on Linux ARM* On ARM platforms, accessing the PMU registers requires special user access permissions. Since there is no other way to get accurate timers, the current implementation of timers in FFmpeg rely on these registers. Unfortunately, enabling user access to these registers on Linux is not trivial, and generally involve compiling a random and unreliable github kernel module, or patching somehow your kernel. Such module is very unlikely to reach the upstream anytime soon. Quoting Robin Murphin from ARM: > Say you do give userspace direct access to the PMU; now run two or more > programs at once that believe they can use the counters for their own > "minimal-overhead" profiling. Have fun interpreting those results... > > And that's not even getting into the implications of scheduling across > different CPUs, CPUidle, etc. where the PMU state is completely beyond > userspace's control. In general, the plan to provide userspace with > something which might happen to just about work in a few corner cases, > but is meaningless, misleading or downright broken in all others, is to > never do so. As a result, the alternative is to use the Performance Monitoring Linux API which makes use of these registers internally (assuming the PMU of your ARM board is supported in the kernel, which is definitely not a given...). While the Linux API is obviously cross platform, it does have a significant overhead which needs to be taken into account. As a result, that mode is only weakly enabled on ARM platforms exclusively. Note on the non flexibility of the implementation: the timers (native FFmpeg vs Linux API) are selected at compilation time to prevent the need of function calls, which would result in a negative impact on the cycle counters.
2017-09-01 15:11:18 +02:00
return -1;
}
return 0;
}
lavu/checkasm: add (private) kperf timing for macOS Signed-off-by: J. Dekker <jdek@itanimul.li>
2021-07-20 19:09:22 +02:00
#elif CONFIG_MACOS_KPERF
static int bench_init_kperf(void)
{
lavu/kperf: use ff_thread_once() Signed-off-by: J. Dekker <jdek@itanimul.li>
2021-07-21 16:21:34 +02:00
ff_kperf_init();
lavu/checkasm: add (private) kperf timing for macOS Signed-off-by: J. Dekker <jdek@itanimul.li>
2021-07-20 19:09:22 +02:00
return 0;
}
#else
checkasm: use perf API on Linux ARM* On ARM platforms, accessing the PMU registers requires special user access permissions. Since there is no other way to get accurate timers, the current implementation of timers in FFmpeg rely on these registers. Unfortunately, enabling user access to these registers on Linux is not trivial, and generally involve compiling a random and unreliable github kernel module, or patching somehow your kernel. Such module is very unlikely to reach the upstream anytime soon. Quoting Robin Murphin from ARM: > Say you do give userspace direct access to the PMU; now run two or more > programs at once that believe they can use the counters for their own > "minimal-overhead" profiling. Have fun interpreting those results... > > And that's not even getting into the implications of scheduling across > different CPUs, CPUidle, etc. where the PMU state is completely beyond > userspace's control. In general, the plan to provide userspace with > something which might happen to just about work in a few corner cases, > but is meaningless, misleading or downright broken in all others, is to > never do so. As a result, the alternative is to use the Performance Monitoring Linux API which makes use of these registers internally (assuming the PMU of your ARM board is supported in the kernel, which is definitely not a given...). While the Linux API is obviously cross platform, it does have a significant overhead which needs to be taken into account. As a result, that mode is only weakly enabled on ARM platforms exclusively. Note on the non flexibility of the implementation: the timers (native FFmpeg vs Linux API) are selected at compilation time to prevent the need of function calls, which would result in a negative impact on the cycle counters.
2017-09-01 15:11:18 +02:00
static int bench_init_ffmpeg(void)
{
#ifdef AV_READ_TIME
printf("benchmarking with native FFmpeg timers\n");
return 0;
#else
fprintf(stderr, "checkasm: --bench is not supported on your system\n");
return -1;
#endif
}
tests/checkasm/checkasm: Do not define an unused function. Fixes the following warning: tests/checkasm/checkasm.c:615:12: warning: 'bench_init_ffmpeg' defined but not used
2019-01-31 21:16:17 +02:00
#endif
checkasm: use perf API on Linux ARM* On ARM platforms, accessing the PMU registers requires special user access permissions. Since there is no other way to get accurate timers, the current implementation of timers in FFmpeg rely on these registers. Unfortunately, enabling user access to these registers on Linux is not trivial, and generally involve compiling a random and unreliable github kernel module, or patching somehow your kernel. Such module is very unlikely to reach the upstream anytime soon. Quoting Robin Murphin from ARM: > Say you do give userspace direct access to the PMU; now run two or more > programs at once that believe they can use the counters for their own > "minimal-overhead" profiling. Have fun interpreting those results... > > And that's not even getting into the implications of scheduling across > different CPUs, CPUidle, etc. where the PMU state is completely beyond > userspace's control. In general, the plan to provide userspace with > something which might happen to just about work in a few corner cases, > but is meaningless, misleading or downright broken in all others, is to > never do so. As a result, the alternative is to use the Performance Monitoring Linux API which makes use of these registers internally (assuming the PMU of your ARM board is supported in the kernel, which is definitely not a given...). While the Linux API is obviously cross platform, it does have a significant overhead which needs to be taken into account. As a result, that mode is only weakly enabled on ARM platforms exclusively. Note on the non flexibility of the implementation: the timers (native FFmpeg vs Linux API) are selected at compilation time to prevent the need of function calls, which would result in a negative impact on the cycle counters.
2017-09-01 15:11:18 +02:00
static int bench_init(void)
{
#if CONFIG_LINUX_PERF
int ret = bench_init_linux();
lavu/checkasm: add (private) kperf timing for macOS Signed-off-by: J. Dekker <jdek@itanimul.li>
2021-07-20 19:09:22 +02:00
#elif CONFIG_MACOS_KPERF
int ret = bench_init_kperf();
checkasm: use perf API on Linux ARM* On ARM platforms, accessing the PMU registers requires special user access permissions. Since there is no other way to get accurate timers, the current implementation of timers in FFmpeg rely on these registers. Unfortunately, enabling user access to these registers on Linux is not trivial, and generally involve compiling a random and unreliable github kernel module, or patching somehow your kernel. Such module is very unlikely to reach the upstream anytime soon. Quoting Robin Murphin from ARM: > Say you do give userspace direct access to the PMU; now run two or more > programs at once that believe they can use the counters for their own > "minimal-overhead" profiling. Have fun interpreting those results... > > And that's not even getting into the implications of scheduling across > different CPUs, CPUidle, etc. where the PMU state is completely beyond > userspace's control. In general, the plan to provide userspace with > something which might happen to just about work in a few corner cases, > but is meaningless, misleading or downright broken in all others, is to > never do so. As a result, the alternative is to use the Performance Monitoring Linux API which makes use of these registers internally (assuming the PMU of your ARM board is supported in the kernel, which is definitely not a given...). While the Linux API is obviously cross platform, it does have a significant overhead which needs to be taken into account. As a result, that mode is only weakly enabled on ARM platforms exclusively. Note on the non flexibility of the implementation: the timers (native FFmpeg vs Linux API) are selected at compilation time to prevent the need of function calls, which would result in a negative impact on the cycle counters.
2017-09-01 15:11:18 +02:00
#else
int ret = bench_init_ffmpeg();
#endif
if (ret < 0)
return ret;
state.nop_time = measure_nop_time();
printf("nop: %d.%d\n", state.nop_time/10, state.nop_time%10);
return 0;
}
static void bench_uninit(void)
{
#if CONFIG_LINUX_PERF
if (state.sysfd > 0)
close(state.sysfd);
#endif
}
checkasm: print usage on invalid arguments This checks that arguments are handled. If not, then this prints a short usage notice and returns an error.
2023-07-14 20:43:01 +02:00
static int usage(const char *path)
{
fprintf(stderr,
"Usage: %s [--bench] [--test=<pattern>] [--verbose] [seed]\n",
path);
return 1;
}
Checkasm: assembly testing and benchmarking tool It provides the following features: * verify correctness by comparing output to the C version. * detect failure to save and restore clobbered callee-saved registers. * detect 32-bit parameters being used as if they were 64-bit in x86-64 (the upper halves are not guaranteed to be zero - but in practice they very often are, which makes those bugs hard to spot otherwise). * easy benchmarking. Compile by running 'make checkasm'. Execute by running 'tests/checkasm/checkasm'. Optional arguments are '--bench' to run benchmarks for all functions, '--bench=<pattern>' to run benchmarks for all functions that starts with <pattern>, and '<integer>' to seed the PRNG for reproducible results. Contains unit tests for most h264pred functions to get started, more tests can be added afterwards using those as a reference. Loosely based on code from x264. Currently only supports x86 and x86-64, but additional architectures shouldn't be too much of an obstacle to add. Note that functions with floating point parameters or floating point return values are not supported. Some compiler-specific features or preprocessor hacks would likely be required to add support for that. Signed-off-by: Janne Grunau <janne-libav@jannau.net>
2015-07-11 20:32:11 +02:00
int main(int argc, char *argv[])
{
checkasm: Add --test parameter to check only specific components Inspired by a patch from Martin Storsjö <martin@martin.st>.
2016-11-04 00:40:26 +02:00
unsigned int seed = av_get_random_seed();
checkasm: Read the unsigned value as it should Reading a value larger than int using atoi() may give the wrong result.
2016-09-11 01:14:37 +02:00
int i, ret = 0;
Checkasm: assembly testing and benchmarking tool It provides the following features: * verify correctness by comparing output to the C version. * detect failure to save and restore clobbered callee-saved registers. * detect 32-bit parameters being used as if they were 64-bit in x86-64 (the upper halves are not guaranteed to be zero - but in practice they very often are, which makes those bugs hard to spot otherwise). * easy benchmarking. Compile by running 'make checkasm'. Execute by running 'tests/checkasm/checkasm'. Optional arguments are '--bench' to run benchmarks for all functions, '--bench=<pattern>' to run benchmarks for all functions that starts with <pattern>, and '<integer>' to seed the PRNG for reproducible results. Contains unit tests for most h264pred functions to get started, more tests can be added afterwards using those as a reference. Loosely based on code from x264. Currently only supports x86 and x86-64, but additional architectures shouldn't be too much of an obstacle to add. Note that functions with floating point parameters or floating point return values are not supported. Some compiler-specific features or preprocessor hacks would likely be required to add support for that. Signed-off-by: Janne Grunau <janne-libav@jannau.net>
2015-07-11 20:32:11 +02:00
checkasm: Generalize crash handling This replaces the riscv specific handling from 7212466e735aa187d82f51dadbce957fe3da77f0 (which essentially is reverted), with a different implementation of the same (plus a bit more), based on the corresponding feature in dav1d's checkasm, supporting both Unix and Windows. See in particular the dav1d commits 0b6ee30eab2400e4f85b735ad29a68a842c34e21, 0421f787ea592fd2cc74c887f20b8dc31393788b, 8501a4b20135f93a4c3b426468e2240e872949c5 and d23e87f7aee26ddcf5f7a2e185112031477599a7, authored by Henrik Gramner. The overall approach compared to the existing implementation for riscv is the same; set up a signal handler, store the state with sigsetjmp, jump out of the crashing function with siglongjmp. The main difference is in what happens when the signal handler is invoked. In the previous implementation, it would resume from right before calling the crashing function, and then skip that call based on the setjmp return value. In the imported implementation from dav1d, we return to right before the check_func() call, which will skip testing the current function (as the pointer is the same as it was before). Other differences are: - Support for other signal handling mechanisms (Windows AddVectoredExceptionHandler) - Using RtlCaptureContext/RtlRestoreContext instead of setjmp/longjmp on Windows with SEH - Only catching signals once per function - if more than one signal is delivered before signal handling is reenabled, any signal is handled as it would without our handler - Not using an arch specific signal handler written in assembly Signed-off-by: Martin Storsjö <martin@martin.st>
2023-12-14 14:57:36 +02:00
#ifdef _WIN32
#if WINAPI_FAMILY_PARTITION(WINAPI_PARTITION_DESKTOP)
AddVectoredExceptionHandler(0, signal_handler);
#endif
#else
sigaction(SIGBUS, &signal_handler_act, NULL);
sigaction(SIGFPE, &signal_handler_act, NULL);
sigaction(SIGILL, &signal_handler_act, NULL);
sigaction(SIGSEGV, &signal_handler_act, NULL);
#endif
checkasm: Check register clobbering on arm Use two separate functions, depending on whether VFP/NEON is available. This is set to require armv5te - it uses blx, which is only available since armv5t, but we don't have a separate configure item for that. (It also uses ldrd, which requires armv5te, but this could be avoided if necessary.) Signed-off-by: Martin Storsjö <martin@martin.st>
2015-12-30 23:46:06 +02:00
#if ARCH_ARM && HAVE_ARMV5TE_EXTERNAL
if (have_vfp(av_get_cpu_flags()) || have_neon(av_get_cpu_flags()))
checkasm_checked_call = checkasm_checked_call_vfp;
#endif
checkasm: Modify report format Makes it a bit more clear where each test belongs. Suggested by Anton Khirnov. Signed-off-by: Anton Khirnov <anton@khirnov.net>
2015-07-24 23:46:20 +02:00
if (!tests[0].func || !cpus[0].flag) {
Checkasm: assembly testing and benchmarking tool It provides the following features: * verify correctness by comparing output to the C version. * detect failure to save and restore clobbered callee-saved registers. * detect 32-bit parameters being used as if they were 64-bit in x86-64 (the upper halves are not guaranteed to be zero - but in practice they very often are, which makes those bugs hard to spot otherwise). * easy benchmarking. Compile by running 'make checkasm'. Execute by running 'tests/checkasm/checkasm'. Optional arguments are '--bench' to run benchmarks for all functions, '--bench=<pattern>' to run benchmarks for all functions that starts with <pattern>, and '<integer>' to seed the PRNG for reproducible results. Contains unit tests for most h264pred functions to get started, more tests can be added afterwards using those as a reference. Loosely based on code from x264. Currently only supports x86 and x86-64, but additional architectures shouldn't be too much of an obstacle to add. Note that functions with floating point parameters or floating point return values are not supported. Some compiler-specific features or preprocessor hacks would likely be required to add support for that. Signed-off-by: Janne Grunau <janne-libav@jannau.net>
2015-07-11 20:32:11 +02:00
fprintf(stderr, "checkasm: no tests to perform\n");
checkasm: exit with status 0 instead of 1 if there are no tests to perform
2015-07-17 18:07:57 +02:00
return 0;
Checkasm: assembly testing and benchmarking tool It provides the following features: * verify correctness by comparing output to the C version. * detect failure to save and restore clobbered callee-saved registers. * detect 32-bit parameters being used as if they were 64-bit in x86-64 (the upper halves are not guaranteed to be zero - but in practice they very often are, which makes those bugs hard to spot otherwise). * easy benchmarking. Compile by running 'make checkasm'. Execute by running 'tests/checkasm/checkasm'. Optional arguments are '--bench' to run benchmarks for all functions, '--bench=<pattern>' to run benchmarks for all functions that starts with <pattern>, and '<integer>' to seed the PRNG for reproducible results. Contains unit tests for most h264pred functions to get started, more tests can be added afterwards using those as a reference. Loosely based on code from x264. Currently only supports x86 and x86-64, but additional architectures shouldn't be too much of an obstacle to add. Note that functions with floating point parameters or floating point return values are not supported. Some compiler-specific features or preprocessor hacks would likely be required to add support for that. Signed-off-by: Janne Grunau <janne-libav@jannau.net>
2015-07-11 20:32:11 +02:00
}
checkasm: print usage on invalid arguments This checks that arguments are handled. If not, then this prints a short usage notice and returns an error.
2023-07-14 20:43:01 +02:00
for (i = 1; i < argc; i++) {
const char *arg = argv[i];
unsigned long l;
char *end;
if (!strncmp(arg, "--bench", 7)) {
checkasm: use perf API on Linux ARM* On ARM platforms, accessing the PMU registers requires special user access permissions. Since there is no other way to get accurate timers, the current implementation of timers in FFmpeg rely on these registers. Unfortunately, enabling user access to these registers on Linux is not trivial, and generally involve compiling a random and unreliable github kernel module, or patching somehow your kernel. Such module is very unlikely to reach the upstream anytime soon. Quoting Robin Murphin from ARM: > Say you do give userspace direct access to the PMU; now run two or more > programs at once that believe they can use the counters for their own > "minimal-overhead" profiling. Have fun interpreting those results... > > And that's not even getting into the implications of scheduling across > different CPUs, CPUidle, etc. where the PMU state is completely beyond > userspace's control. In general, the plan to provide userspace with > something which might happen to just about work in a few corner cases, > but is meaningless, misleading or downright broken in all others, is to > never do so. As a result, the alternative is to use the Performance Monitoring Linux API which makes use of these registers internally (assuming the PMU of your ARM board is supported in the kernel, which is definitely not a given...). While the Linux API is obviously cross platform, it does have a significant overhead which needs to be taken into account. As a result, that mode is only weakly enabled on ARM platforms exclusively. Note on the non flexibility of the implementation: the timers (native FFmpeg vs Linux API) are selected at compilation time to prevent the need of function calls, which would result in a negative impact on the cycle counters.
2017-09-01 15:11:18 +02:00
if (bench_init() < 0)
return 1;
checkasm: print usage on invalid arguments This checks that arguments are handled. If not, then this prints a short usage notice and returns an error.
2023-07-14 20:43:01 +02:00
if (arg[7] == '=') {
state.bench_pattern = arg + 8;
checkasm: Add --test parameter to check only specific components Inspired by a patch from Martin Storsjö <martin@martin.st>.
2016-11-04 00:40:26 +02:00
state.bench_pattern_len = strlen(state.bench_pattern);
} else
state.bench_pattern = "";
checkasm: print usage on invalid arguments This checks that arguments are handled. If not, then this prints a short usage notice and returns an error.
2023-07-14 20:43:01 +02:00
} else if (!strncmp(arg, "--test=", 7)) {
state.test_name = arg + 7;
} else if (!strcmp(arg, "--verbose") || !strcmp(arg, "-v")) {
checkasm: add function to check and diff memory This was ported from dav1d (c950e7101bdf5f7117bfca816984a21e550509f0). Signed-off-by: Josh de Kock <josh@itanimul.li>
2019-06-20 22:38:06 +02:00
state.verbose = 1;
checkasm: print usage on invalid arguments This checks that arguments are handled. If not, then this prints a short usage notice and returns an error.
2023-07-14 20:43:01 +02:00
} else if ((l = strtoul(arg, &end, 10)) <= UINT_MAX &&
*end == '\0') {
seed = l;
checkasm: Add --test parameter to check only specific components Inspired by a patch from Martin Storsjö <martin@martin.st>.
2016-11-04 00:40:26 +02:00
} else {
checkasm: print usage on invalid arguments This checks that arguments are handled. If not, then this prints a short usage notice and returns an error.
2023-07-14 20:43:01 +02:00
return usage(argv[0]);
checkasm: Add --test parameter to check only specific components Inspired by a patch from Martin Storsjö <martin@martin.st>.
2016-11-04 00:40:26 +02:00
}
Checkasm: assembly testing and benchmarking tool It provides the following features: * verify correctness by comparing output to the C version. * detect failure to save and restore clobbered callee-saved registers. * detect 32-bit parameters being used as if they were 64-bit in x86-64 (the upper halves are not guaranteed to be zero - but in practice they very often are, which makes those bugs hard to spot otherwise). * easy benchmarking. Compile by running 'make checkasm'. Execute by running 'tests/checkasm/checkasm'. Optional arguments are '--bench' to run benchmarks for all functions, '--bench=<pattern>' to run benchmarks for all functions that starts with <pattern>, and '<integer>' to seed the PRNG for reproducible results. Contains unit tests for most h264pred functions to get started, more tests can be added afterwards using those as a reference. Loosely based on code from x264. Currently only supports x86 and x86-64, but additional architectures shouldn't be too much of an obstacle to add. Note that functions with floating point parameters or floating point return values are not supported. Some compiler-specific features or preprocessor hacks would likely be required to add support for that. Signed-off-by: Janne Grunau <janne-libav@jannau.net>
2015-07-11 20:32:11 +02:00
}
fprintf(stderr, "checkasm: using random seed %u\n", seed);
av_lfg_init(&checkasm_lfg, seed);
check_cpu_flag(NULL, 0);
for (i = 0; cpus[i].flag; i++)
check_cpu_flag(cpus[i].name, cpus[i].flag);
if (state.num_failed) {
fprintf(stderr, "checkasm: %d of %d tests have failed\n", state.num_failed, state.num_checked);
ret = 1;
} else {
fprintf(stderr, "checkasm: all %d tests passed\n", state.num_checked);
if (state.bench_pattern) {
print_benchs(state.funcs);
}
}
destroy_func_tree(state.funcs);
checkasm: use perf API on Linux ARM* On ARM platforms, accessing the PMU registers requires special user access permissions. Since there is no other way to get accurate timers, the current implementation of timers in FFmpeg rely on these registers. Unfortunately, enabling user access to these registers on Linux is not trivial, and generally involve compiling a random and unreliable github kernel module, or patching somehow your kernel. Such module is very unlikely to reach the upstream anytime soon. Quoting Robin Murphin from ARM: > Say you do give userspace direct access to the PMU; now run two or more > programs at once that believe they can use the counters for their own > "minimal-overhead" profiling. Have fun interpreting those results... > > And that's not even getting into the implications of scheduling across > different CPUs, CPUidle, etc. where the PMU state is completely beyond > userspace's control. In general, the plan to provide userspace with > something which might happen to just about work in a few corner cases, > but is meaningless, misleading or downright broken in all others, is to > never do so. As a result, the alternative is to use the Performance Monitoring Linux API which makes use of these registers internally (assuming the PMU of your ARM board is supported in the kernel, which is definitely not a given...). While the Linux API is obviously cross platform, it does have a significant overhead which needs to be taken into account. As a result, that mode is only weakly enabled on ARM platforms exclusively. Note on the non flexibility of the implementation: the timers (native FFmpeg vs Linux API) are selected at compilation time to prevent the need of function calls, which would result in a negative impact on the cycle counters.
2017-09-01 15:11:18 +02:00
bench_uninit();
Checkasm: assembly testing and benchmarking tool It provides the following features: * verify correctness by comparing output to the C version. * detect failure to save and restore clobbered callee-saved registers. * detect 32-bit parameters being used as if they were 64-bit in x86-64 (the upper halves are not guaranteed to be zero - but in practice they very often are, which makes those bugs hard to spot otherwise). * easy benchmarking. Compile by running 'make checkasm'. Execute by running 'tests/checkasm/checkasm'. Optional arguments are '--bench' to run benchmarks for all functions, '--bench=<pattern>' to run benchmarks for all functions that starts with <pattern>, and '<integer>' to seed the PRNG for reproducible results. Contains unit tests for most h264pred functions to get started, more tests can be added afterwards using those as a reference. Loosely based on code from x264. Currently only supports x86 and x86-64, but additional architectures shouldn't be too much of an obstacle to add. Note that functions with floating point parameters or floating point return values are not supported. Some compiler-specific features or preprocessor hacks would likely be required to add support for that. Signed-off-by: Janne Grunau <janne-libav@jannau.net>
2015-07-11 20:32:11 +02:00
return ret;
}
/* Decide whether or not the specified function needs to be tested and
* allocate/initialize data structures if needed. Returns a pointer to a
* reference function if the function should be tested, otherwise NULL */
checkasm: Explicitly declare function prototypes Now we no longer have to rely on function pointers intentionally declared without specified argument types. This makes it easier to support functions with floating point parameters or return values as well as functions returning 64-bit values on 32-bit architectures. It also avoids having to explicitly cast strides to ptrdiff_t for example.
2015-08-16 13:00:21 +02:00
void *checkasm_check_func(void *func, const char *name, ...)
Checkasm: assembly testing and benchmarking tool It provides the following features: * verify correctness by comparing output to the C version. * detect failure to save and restore clobbered callee-saved registers. * detect 32-bit parameters being used as if they were 64-bit in x86-64 (the upper halves are not guaranteed to be zero - but in practice they very often are, which makes those bugs hard to spot otherwise). * easy benchmarking. Compile by running 'make checkasm'. Execute by running 'tests/checkasm/checkasm'. Optional arguments are '--bench' to run benchmarks for all functions, '--bench=<pattern>' to run benchmarks for all functions that starts with <pattern>, and '<integer>' to seed the PRNG for reproducible results. Contains unit tests for most h264pred functions to get started, more tests can be added afterwards using those as a reference. Loosely based on code from x264. Currently only supports x86 and x86-64, but additional architectures shouldn't be too much of an obstacle to add. Note that functions with floating point parameters or floating point return values are not supported. Some compiler-specific features or preprocessor hacks would likely be required to add support for that. Signed-off-by: Janne Grunau <janne-libav@jannau.net>
2015-07-11 20:32:11 +02:00
{
char name_buf[256];
checkasm: Explicitly declare function prototypes Now we no longer have to rely on function pointers intentionally declared without specified argument types. This makes it easier to support functions with floating point parameters or return values as well as functions returning 64-bit values on 32-bit architectures. It also avoids having to explicitly cast strides to ptrdiff_t for example.
2015-08-16 13:00:21 +02:00
void *ref = func;
Checkasm: assembly testing and benchmarking tool It provides the following features: * verify correctness by comparing output to the C version. * detect failure to save and restore clobbered callee-saved registers. * detect 32-bit parameters being used as if they were 64-bit in x86-64 (the upper halves are not guaranteed to be zero - but in practice they very often are, which makes those bugs hard to spot otherwise). * easy benchmarking. Compile by running 'make checkasm'. Execute by running 'tests/checkasm/checkasm'. Optional arguments are '--bench' to run benchmarks for all functions, '--bench=<pattern>' to run benchmarks for all functions that starts with <pattern>, and '<integer>' to seed the PRNG for reproducible results. Contains unit tests for most h264pred functions to get started, more tests can be added afterwards using those as a reference. Loosely based on code from x264. Currently only supports x86 and x86-64, but additional architectures shouldn't be too much of an obstacle to add. Note that functions with floating point parameters or floating point return values are not supported. Some compiler-specific features or preprocessor hacks would likely be required to add support for that. Signed-off-by: Janne Grunau <janne-libav@jannau.net>
2015-07-11 20:32:11 +02:00
CheckasmFuncVersion *v;
int name_length;
va_list arg;
va_start(arg, name);
name_length = vsnprintf(name_buf, sizeof(name_buf), name, arg);
va_end(arg);
if (!func || name_length <= 0 || name_length >= sizeof(name_buf))
return NULL;
checkasm: Use a self-balancing tree Tested functions are internally kept in a binary search tree for efficient lookups. The downside of the current implementation is that the tree quickly becomes unbalanced which causes an unneccessary amount of comparisons between nodes. Improve this by changing the tree into a self-balancing left-leaning red-black tree with a worst case lookup/insertion time complexity of O(log n). Significantly reduces the recursion depth and makes the tests run around 10% faster overall. The relative performance improvement compared to the existing non-balanced tree will also most likely increase as more tests are added.
2015-09-25 18:56:00 +02:00
state.current_func = get_func(&state.funcs, name_buf);
state.funcs->color = 1;
Checkasm: assembly testing and benchmarking tool It provides the following features: * verify correctness by comparing output to the C version. * detect failure to save and restore clobbered callee-saved registers. * detect 32-bit parameters being used as if they were 64-bit in x86-64 (the upper halves are not guaranteed to be zero - but in practice they very often are, which makes those bugs hard to spot otherwise). * easy benchmarking. Compile by running 'make checkasm'. Execute by running 'tests/checkasm/checkasm'. Optional arguments are '--bench' to run benchmarks for all functions, '--bench=<pattern>' to run benchmarks for all functions that starts with <pattern>, and '<integer>' to seed the PRNG for reproducible results. Contains unit tests for most h264pred functions to get started, more tests can be added afterwards using those as a reference. Loosely based on code from x264. Currently only supports x86 and x86-64, but additional architectures shouldn't be too much of an obstacle to add. Note that functions with floating point parameters or floating point return values are not supported. Some compiler-specific features or preprocessor hacks would likely be required to add support for that. Signed-off-by: Janne Grunau <janne-libav@jannau.net>
2015-07-11 20:32:11 +02:00
v = &state.current_func->versions;
if (v->func) {
CheckasmFuncVersion *prev;
do {
/* Only test functions that haven't already been tested */
if (v->func == func)
return NULL;
if (v->ok)
ref = v->func;
prev = v;
} while ((v = v->next));
v = prev->next = checkasm_malloc(sizeof(CheckasmFuncVersion));
}
v->func = func;
v->ok = 1;
v->cpu = state.cpu_flag;
state.current_func_ver = v;
if (state.cpu_flag)
state.num_checked++;
return ref;
}
/* Decide whether or not the current function needs to be benchmarked */
int checkasm_bench_func(void)
{
return !state.num_failed && state.bench_pattern &&
!strncmp(state.current_func->name, state.bench_pattern, state.bench_pattern_len);
}
/* Indicate that the current test has failed */
void checkasm_fail_func(const char *msg, ...)
{
if (state.current_func_ver->cpu && state.current_func_ver->ok) {
va_list arg;
print_cpu_name();
fprintf(stderr, " %s_%s (", state.current_func->name, cpu_suffix(state.current_func_ver->cpu));
va_start(arg, msg);
vfprintf(stderr, msg, arg);
va_end(arg);
fprintf(stderr, ")\n");
state.current_func_ver->ok = 0;
state.num_failed++;
}
}
checkasm: Generalize crash handling This replaces the riscv specific handling from 7212466e735aa187d82f51dadbce957fe3da77f0 (which essentially is reverted), with a different implementation of the same (plus a bit more), based on the corresponding feature in dav1d's checkasm, supporting both Unix and Windows. See in particular the dav1d commits 0b6ee30eab2400e4f85b735ad29a68a842c34e21, 0421f787ea592fd2cc74c887f20b8dc31393788b, 8501a4b20135f93a4c3b426468e2240e872949c5 and d23e87f7aee26ddcf5f7a2e185112031477599a7, authored by Henrik Gramner. The overall approach compared to the existing implementation for riscv is the same; set up a signal handler, store the state with sigsetjmp, jump out of the crashing function with siglongjmp. The main difference is in what happens when the signal handler is invoked. In the previous implementation, it would resume from right before calling the crashing function, and then skip that call based on the setjmp return value. In the imported implementation from dav1d, we return to right before the check_func() call, which will skip testing the current function (as the pointer is the same as it was before). Other differences are: - Support for other signal handling mechanisms (Windows AddVectoredExceptionHandler) - Using RtlCaptureContext/RtlRestoreContext instead of setjmp/longjmp on Windows with SEH - Only catching signals once per function - if more than one signal is delivered before signal handling is reenabled, any signal is handled as it would without our handler - Not using an arch specific signal handler written in assembly Signed-off-by: Martin Storsjö <martin@martin.st>
2023-12-14 14:57:36 +02:00
void checkasm_set_signal_handler_state(int enabled) {
state.catch_signals = enabled;
}
int checkasm_handle_signal(int s) {
if (s) {
checkasm: add helper to report a fatal signal
2023-11-16 17:45:02 +02:00
#ifdef __GLIBC__
checkasm: Generalize crash handling This replaces the riscv specific handling from 7212466e735aa187d82f51dadbce957fe3da77f0 (which essentially is reverted), with a different implementation of the same (plus a bit more), based on the corresponding feature in dav1d's checkasm, supporting both Unix and Windows. See in particular the dav1d commits 0b6ee30eab2400e4f85b735ad29a68a842c34e21, 0421f787ea592fd2cc74c887f20b8dc31393788b, 8501a4b20135f93a4c3b426468e2240e872949c5 and d23e87f7aee26ddcf5f7a2e185112031477599a7, authored by Henrik Gramner. The overall approach compared to the existing implementation for riscv is the same; set up a signal handler, store the state with sigsetjmp, jump out of the crashing function with siglongjmp. The main difference is in what happens when the signal handler is invoked. In the previous implementation, it would resume from right before calling the crashing function, and then skip that call based on the setjmp return value. In the imported implementation from dav1d, we return to right before the check_func() call, which will skip testing the current function (as the pointer is the same as it was before). Other differences are: - Support for other signal handling mechanisms (Windows AddVectoredExceptionHandler) - Using RtlCaptureContext/RtlRestoreContext instead of setjmp/longjmp on Windows with SEH - Only catching signals once per function - if more than one signal is delivered before signal handling is reenabled, any signal is handled as it would without our handler - Not using an arch specific signal handler written in assembly Signed-off-by: Martin Storsjö <martin@martin.st>
2023-12-14 14:57:36 +02:00
checkasm_fail_func("fatal signal %d: %s", s, strsignal(s));
checkasm: add helper to report a fatal signal
2023-11-16 17:45:02 +02:00
#else
checkasm: Generalize crash handling This replaces the riscv specific handling from 7212466e735aa187d82f51dadbce957fe3da77f0 (which essentially is reverted), with a different implementation of the same (plus a bit more), based on the corresponding feature in dav1d's checkasm, supporting both Unix and Windows. See in particular the dav1d commits 0b6ee30eab2400e4f85b735ad29a68a842c34e21, 0421f787ea592fd2cc74c887f20b8dc31393788b, 8501a4b20135f93a4c3b426468e2240e872949c5 and d23e87f7aee26ddcf5f7a2e185112031477599a7, authored by Henrik Gramner. The overall approach compared to the existing implementation for riscv is the same; set up a signal handler, store the state with sigsetjmp, jump out of the crashing function with siglongjmp. The main difference is in what happens when the signal handler is invoked. In the previous implementation, it would resume from right before calling the crashing function, and then skip that call based on the setjmp return value. In the imported implementation from dav1d, we return to right before the check_func() call, which will skip testing the current function (as the pointer is the same as it was before). Other differences are: - Support for other signal handling mechanisms (Windows AddVectoredExceptionHandler) - Using RtlCaptureContext/RtlRestoreContext instead of setjmp/longjmp on Windows with SEH - Only catching signals once per function - if more than one signal is delivered before signal handling is reenabled, any signal is handled as it would without our handler - Not using an arch specific signal handler written in assembly Signed-off-by: Martin Storsjö <martin@martin.st>
2023-12-14 14:57:36 +02:00
checkasm_fail_func(s == SIGFPE ? "fatal arithmetic error" :
s == SIGILL ? "illegal instruction" :
s == SIGBUS ? "bus error" :
"segmentation fault");
checkasm: add helper to report a fatal signal
2023-11-16 17:45:02 +02:00
#endif
checkasm: Generalize crash handling This replaces the riscv specific handling from 7212466e735aa187d82f51dadbce957fe3da77f0 (which essentially is reverted), with a different implementation of the same (plus a bit more), based on the corresponding feature in dav1d's checkasm, supporting both Unix and Windows. See in particular the dav1d commits 0b6ee30eab2400e4f85b735ad29a68a842c34e21, 0421f787ea592fd2cc74c887f20b8dc31393788b, 8501a4b20135f93a4c3b426468e2240e872949c5 and d23e87f7aee26ddcf5f7a2e185112031477599a7, authored by Henrik Gramner. The overall approach compared to the existing implementation for riscv is the same; set up a signal handler, store the state with sigsetjmp, jump out of the crashing function with siglongjmp. The main difference is in what happens when the signal handler is invoked. In the previous implementation, it would resume from right before calling the crashing function, and then skip that call based on the setjmp return value. In the imported implementation from dav1d, we return to right before the check_func() call, which will skip testing the current function (as the pointer is the same as it was before). Other differences are: - Support for other signal handling mechanisms (Windows AddVectoredExceptionHandler) - Using RtlCaptureContext/RtlRestoreContext instead of setjmp/longjmp on Windows with SEH - Only catching signals once per function - if more than one signal is delivered before signal handling is reenabled, any signal is handled as it would without our handler - Not using an arch specific signal handler written in assembly Signed-off-by: Martin Storsjö <martin@martin.st>
2023-12-14 14:57:36 +02:00
}
return s;
checkasm: add helper to report a fatal signal
2023-11-16 17:45:02 +02:00
}
checkasm: use perf API on Linux ARM* On ARM platforms, accessing the PMU registers requires special user access permissions. Since there is no other way to get accurate timers, the current implementation of timers in FFmpeg rely on these registers. Unfortunately, enabling user access to these registers on Linux is not trivial, and generally involve compiling a random and unreliable github kernel module, or patching somehow your kernel. Such module is very unlikely to reach the upstream anytime soon. Quoting Robin Murphin from ARM: > Say you do give userspace direct access to the PMU; now run two or more > programs at once that believe they can use the counters for their own > "minimal-overhead" profiling. Have fun interpreting those results... > > And that's not even getting into the implications of scheduling across > different CPUs, CPUidle, etc. where the PMU state is completely beyond > userspace's control. In general, the plan to provide userspace with > something which might happen to just about work in a few corner cases, > but is meaningless, misleading or downright broken in all others, is to > never do so. As a result, the alternative is to use the Performance Monitoring Linux API which makes use of these registers internally (assuming the PMU of your ARM board is supported in the kernel, which is definitely not a given...). While the Linux API is obviously cross platform, it does have a significant overhead which needs to be taken into account. As a result, that mode is only weakly enabled on ARM platforms exclusively. Note on the non flexibility of the implementation: the timers (native FFmpeg vs Linux API) are selected at compilation time to prevent the need of function calls, which would result in a negative impact on the cycle counters.
2017-09-01 15:11:18 +02:00
/* Get the benchmark context of the current function */
CheckasmPerf *checkasm_get_perf_context(void)
Checkasm: assembly testing and benchmarking tool It provides the following features: * verify correctness by comparing output to the C version. * detect failure to save and restore clobbered callee-saved registers. * detect 32-bit parameters being used as if they were 64-bit in x86-64 (the upper halves are not guaranteed to be zero - but in practice they very often are, which makes those bugs hard to spot otherwise). * easy benchmarking. Compile by running 'make checkasm'. Execute by running 'tests/checkasm/checkasm'. Optional arguments are '--bench' to run benchmarks for all functions, '--bench=<pattern>' to run benchmarks for all functions that starts with <pattern>, and '<integer>' to seed the PRNG for reproducible results. Contains unit tests for most h264pred functions to get started, more tests can be added afterwards using those as a reference. Loosely based on code from x264. Currently only supports x86 and x86-64, but additional architectures shouldn't be too much of an obstacle to add. Note that functions with floating point parameters or floating point return values are not supported. Some compiler-specific features or preprocessor hacks would likely be required to add support for that. Signed-off-by: Janne Grunau <janne-libav@jannau.net>
2015-07-11 20:32:11 +02:00
{
checkasm: use perf API on Linux ARM* On ARM platforms, accessing the PMU registers requires special user access permissions. Since there is no other way to get accurate timers, the current implementation of timers in FFmpeg rely on these registers. Unfortunately, enabling user access to these registers on Linux is not trivial, and generally involve compiling a random and unreliable github kernel module, or patching somehow your kernel. Such module is very unlikely to reach the upstream anytime soon. Quoting Robin Murphin from ARM: > Say you do give userspace direct access to the PMU; now run two or more > programs at once that believe they can use the counters for their own > "minimal-overhead" profiling. Have fun interpreting those results... > > And that's not even getting into the implications of scheduling across > different CPUs, CPUidle, etc. where the PMU state is completely beyond > userspace's control. In general, the plan to provide userspace with > something which might happen to just about work in a few corner cases, > but is meaningless, misleading or downright broken in all others, is to > never do so. As a result, the alternative is to use the Performance Monitoring Linux API which makes use of these registers internally (assuming the PMU of your ARM board is supported in the kernel, which is definitely not a given...). While the Linux API is obviously cross platform, it does have a significant overhead which needs to be taken into account. As a result, that mode is only weakly enabled on ARM platforms exclusively. Note on the non flexibility of the implementation: the timers (native FFmpeg vs Linux API) are selected at compilation time to prevent the need of function calls, which would result in a negative impact on the cycle counters.
2017-09-01 15:11:18 +02:00
CheckasmPerf *perf = &state.current_func_ver->perf;
memset(perf, 0, sizeof(*perf));
perf->sysfd = state.sysfd;
return perf;
Checkasm: assembly testing and benchmarking tool It provides the following features: * verify correctness by comparing output to the C version. * detect failure to save and restore clobbered callee-saved registers. * detect 32-bit parameters being used as if they were 64-bit in x86-64 (the upper halves are not guaranteed to be zero - but in practice they very often are, which makes those bugs hard to spot otherwise). * easy benchmarking. Compile by running 'make checkasm'. Execute by running 'tests/checkasm/checkasm'. Optional arguments are '--bench' to run benchmarks for all functions, '--bench=<pattern>' to run benchmarks for all functions that starts with <pattern>, and '<integer>' to seed the PRNG for reproducible results. Contains unit tests for most h264pred functions to get started, more tests can be added afterwards using those as a reference. Loosely based on code from x264. Currently only supports x86 and x86-64, but additional architectures shouldn't be too much of an obstacle to add. Note that functions with floating point parameters or floating point return values are not supported. Some compiler-specific features or preprocessor hacks would likely be required to add support for that. Signed-off-by: Janne Grunau <janne-libav@jannau.net>
2015-07-11 20:32:11 +02:00
}
/* Print the outcome of all tests performed since the last time this function was called */
void checkasm_report(const char *name, ...)
{
static int prev_checked, prev_failed, max_length;
if (state.num_checked > prev_checked) {
checkasm: Modify report format Makes it a bit more clear where each test belongs. Suggested by Anton Khirnov. Signed-off-by: Anton Khirnov <anton@khirnov.net>
2015-07-24 23:46:20 +02:00
int pad_length = max_length + 4;
va_list arg;
Checkasm: assembly testing and benchmarking tool It provides the following features: * verify correctness by comparing output to the C version. * detect failure to save and restore clobbered callee-saved registers. * detect 32-bit parameters being used as if they were 64-bit in x86-64 (the upper halves are not guaranteed to be zero - but in practice they very often are, which makes those bugs hard to spot otherwise). * easy benchmarking. Compile by running 'make checkasm'. Execute by running 'tests/checkasm/checkasm'. Optional arguments are '--bench' to run benchmarks for all functions, '--bench=<pattern>' to run benchmarks for all functions that starts with <pattern>, and '<integer>' to seed the PRNG for reproducible results. Contains unit tests for most h264pred functions to get started, more tests can be added afterwards using those as a reference. Loosely based on code from x264. Currently only supports x86 and x86-64, but additional architectures shouldn't be too much of an obstacle to add. Note that functions with floating point parameters or floating point return values are not supported. Some compiler-specific features or preprocessor hacks would likely be required to add support for that. Signed-off-by: Janne Grunau <janne-libav@jannau.net>
2015-07-11 20:32:11 +02:00
checkasm: Modify report format Makes it a bit more clear where each test belongs. Suggested by Anton Khirnov. Signed-off-by: Anton Khirnov <anton@khirnov.net>
2015-07-24 23:46:20 +02:00
print_cpu_name();
pad_length -= fprintf(stderr, " - %s.", state.current_test_name);
va_start(arg, name);
pad_length -= vfprintf(stderr, name, arg);
va_end(arg);
fprintf(stderr, "%*c", FFMAX(pad_length, 0) + 2, '[');
Checkasm: assembly testing and benchmarking tool It provides the following features: * verify correctness by comparing output to the C version. * detect failure to save and restore clobbered callee-saved registers. * detect 32-bit parameters being used as if they were 64-bit in x86-64 (the upper halves are not guaranteed to be zero - but in practice they very often are, which makes those bugs hard to spot otherwise). * easy benchmarking. Compile by running 'make checkasm'. Execute by running 'tests/checkasm/checkasm'. Optional arguments are '--bench' to run benchmarks for all functions, '--bench=<pattern>' to run benchmarks for all functions that starts with <pattern>, and '<integer>' to seed the PRNG for reproducible results. Contains unit tests for most h264pred functions to get started, more tests can be added afterwards using those as a reference. Loosely based on code from x264. Currently only supports x86 and x86-64, but additional architectures shouldn't be too much of an obstacle to add. Note that functions with floating point parameters or floating point return values are not supported. Some compiler-specific features or preprocessor hacks would likely be required to add support for that. Signed-off-by: Janne Grunau <janne-libav@jannau.net>
2015-07-11 20:32:11 +02:00
if (state.num_failed == prev_failed)
color_printf(COLOR_GREEN, "OK");
else
color_printf(COLOR_RED, "FAILED");
fprintf(stderr, "]\n");
prev_checked = state.num_checked;
prev_failed = state.num_failed;
} else if (!state.cpu_flag) {
/* Calculate the amount of padding required to make the output vertically aligned */
checkasm: Modify report format Makes it a bit more clear where each test belongs. Suggested by Anton Khirnov. Signed-off-by: Anton Khirnov <anton@khirnov.net>
2015-07-24 23:46:20 +02:00
int length = strlen(state.current_test_name);
va_list arg;
va_start(arg, name);
length += vsnprintf(NULL, 0, name, arg);
va_end(arg);
Checkasm: assembly testing and benchmarking tool It provides the following features: * verify correctness by comparing output to the C version. * detect failure to save and restore clobbered callee-saved registers. * detect 32-bit parameters being used as if they were 64-bit in x86-64 (the upper halves are not guaranteed to be zero - but in practice they very often are, which makes those bugs hard to spot otherwise). * easy benchmarking. Compile by running 'make checkasm'. Execute by running 'tests/checkasm/checkasm'. Optional arguments are '--bench' to run benchmarks for all functions, '--bench=<pattern>' to run benchmarks for all functions that starts with <pattern>, and '<integer>' to seed the PRNG for reproducible results. Contains unit tests for most h264pred functions to get started, more tests can be added afterwards using those as a reference. Loosely based on code from x264. Currently only supports x86 and x86-64, but additional architectures shouldn't be too much of an obstacle to add. Note that functions with floating point parameters or floating point return values are not supported. Some compiler-specific features or preprocessor hacks would likely be required to add support for that. Signed-off-by: Janne Grunau <janne-libav@jannau.net>
2015-07-11 20:32:11 +02:00
if (length > max_length)
max_length = length;
}
}
checkasm: add function to check and diff memory This was ported from dav1d (c950e7101bdf5f7117bfca816984a21e550509f0). Signed-off-by: Josh de Kock <josh@itanimul.li>
2019-06-20 22:38:06 +02:00
#define DEF_CHECKASM_CHECK_FUNC(type, fmt) \
checkasm: Remove unnecessary const on scalar parameters The ffmpeg coding style doesn't usually use const on scalar parameters (or on the pointer values - as opposed to the type that is pointed to, where it has a semantic meaning), contrary to the dav1d coding style (where this was imported from). This avoids warnings about differences in the type signatures between declaration and definition of this function, with older versions of MSVC. The issue was observed with one version of MSVC 2017, 19.16.27024.1, with warnings like these: src/tests/checkasm/checkasm.c(969): warning C4028: formal parameter 3 different from declaration The warning itself is bogus as the const here is harmless, and newer versions of MSVC no longer warn about this. Signed-off-by: Martin Storsjö <martin@martin.st>
2023-12-16 00:33:59 +02:00
int checkasm_check_##type(const char *file, int line, \
checkasm: add function to check and diff memory This was ported from dav1d (c950e7101bdf5f7117bfca816984a21e550509f0). Signed-off-by: Josh de Kock <josh@itanimul.li>
2019-06-20 22:38:06 +02:00
const type *buf1, ptrdiff_t stride1, \
const type *buf2, ptrdiff_t stride2, \
checkasm: Remove unnecessary const on scalar parameters The ffmpeg coding style doesn't usually use const on scalar parameters (or on the pointer values - as opposed to the type that is pointed to, where it has a semantic meaning), contrary to the dav1d coding style (where this was imported from). This avoids warnings about differences in the type signatures between declaration and definition of this function, with older versions of MSVC. The issue was observed with one version of MSVC 2017, 19.16.27024.1, with warnings like these: src/tests/checkasm/checkasm.c(969): warning C4028: formal parameter 3 different from declaration The warning itself is bogus as the const here is harmless, and newer versions of MSVC no longer warn about this. Signed-off-by: Martin Storsjö <martin@martin.st>
2023-12-16 00:33:59 +02:00
int w, int h, const char *name) \
checkasm: add function to check and diff memory This was ported from dav1d (c950e7101bdf5f7117bfca816984a21e550509f0). Signed-off-by: Josh de Kock <josh@itanimul.li>
2019-06-20 22:38:06 +02:00
{ \
int y = 0; \
stride1 /= sizeof(*buf1); \
stride2 /= sizeof(*buf2); \
for (y = 0; y < h; y++) \
if (memcmp(&buf1[y*stride1], &buf2[y*stride2], w*sizeof(*buf1))) \
break; \
if (y == h) \
return 0; \
checkasm_fail_func("%s:%d", file, line); \
if (!state.verbose) \
return 1; \
fprintf(stderr, "%s:\n", name); \
while (h--) { \
for (int x = 0; x < w; x++) \
fprintf(stderr, " " fmt, buf1[x]); \
fprintf(stderr, " "); \
for (int x = 0; x < w; x++) \
fprintf(stderr, " " fmt, buf2[x]); \
fprintf(stderr, " "); \
for (int x = 0; x < w; x++) \
fprintf(stderr, "%c", buf1[x] != buf2[x] ? 'x' : '.'); \
buf1 += stride1; \
buf2 += stride2; \
fprintf(stderr, "\n"); \
} \
return 1; \
}
DEF_CHECKASM_CHECK_FUNC(uint8_t, "%02x")
DEF_CHECKASM_CHECK_FUNC(uint16_t, "%04x")
checkasm: add a verbose check function for uint32_t data
2022-10-26 17:51:36 +02:00
DEF_CHECKASM_CHECK_FUNC(uint32_t, "%08x")
checkasm: add function to check and diff memory This was ported from dav1d (c950e7101bdf5f7117bfca816984a21e550509f0). Signed-off-by: Josh de Kock <josh@itanimul.li>
2019-06-20 22:38:06 +02:00
DEF_CHECKASM_CHECK_FUNC(int16_t, "%6d")
DEF_CHECKASM_CHECK_FUNC(int32_t, "%9d")
Reference in New Issue Copy Permalink