3a2a874994, which switched to using
the checkasm core from the separate checkasm project, removed the
thread dependency from the checkasm executable, as the checkasm
library itself has a thread dependency.
However, checkasm doesn't always include that thread dependency,
it only does that when pthread_setaffinity_np is detected.
The dav1d object files themselves use pthreads as well, causing
undefined symbols if checkasm doesn't link in pthreads.
This should fix linking on OpenBSD after
3a2a874994, fixing issue #467.
This was lost in 3a2a874994.
Without this, checkasm ends up printing a quite confusing output
consisting only of the functions that have two or more assembly
implementations, if trim_dsp happens to be enabled.
For this to have an effect, it requires using a newer version of
the wrapped checkasm subproject; including checkasm commit
be05a7972e47c658a7c5c186294d27caa5735db2 or newer.
The glue code in our headers, for integrating with the external
checkasm, was incompatible with MSVC.
MSVC has a nonstandard handling of __VA_ARGS__ with macros; when
one macro invokes another macro, __VA_ARGS__ gets treated as one
single parameter and can't map to more than one parameter in the
invoked macro. (In other words, when calling another macro,
__VA_ARGS__ must map in its entirety to a ... parameter of the
other macro.)
Modern versions of MSVC do implement the correct mode as well,
but defaults to the old one for backwards compatibility. To
choose the new mode, we'd have to build our code with
-Zc:preprocessor. That's certainly doable, but it's fairly easy to
avoid the issue as well.
To avoid this issue, change the variadic PIXEL_RECT(...) to explicitly
names its arguments. There's actually no variability in the arguments
involved here. (Alternatively, we could force the preprocessor to expand
the arguments one extra time, avoiding the issue, with e.g.
"#define EXPAND(x) x" and wrapping PIXEL_RECT with it, e.g.
"#define PIXEL_RECT(...) EXPAND(BUF_RECT(pixel, __VA_ARGS__))".)
See [1], [2] and [3] for more discussion on the matter.
[1] https://stackoverflow.com/a/5134656/3115956
[2] https://stackoverflow.com/a/7459803/3115956
[2] https://learn.microsoft.com/en-us/cpp/preprocessor/preprocessor-experimental-overview?view=msvc-160
There are a number of benefits tied to the upstream / third-party checkasm
version, including:
- Improved long-term maintainability, code reuse with other projects, etc.
- Vastly improved overall performance / runtime for benchmarking, due
primarily to the ability to scale the runtime of each test to that test's
complexity.
- Much more robust statistical analysis of benchmarking results; including
robust outlier rejection, an estimation of the histogram, and the ability
to report the variance / stddev in addition to the (trimmed) mean.
- Interactive HTML and JSON output formats in addition to CSV/TSV.
- More readable and user-friendly output across the board, especially for
failures and data dumps (e.g. also showing errors inside padding bytes).
- Better cross-platform support, including dynamic fallback of timer
implementations on ARM platforms, a better RISC-V harness, and more.
There are multiple approaches to how we can solve the problem of integrating
this third party checkasm into dav1d, but I think the hybrid approach of
loading it as an external dependency, falling back to a meson wrap file,
provides the best overall compromise. This avoids the messiness of git e.g.
git submodules, while still allowing us to pin individual tags.
CLOCK_MONOTONIC is specified as returning time "since an unspecified point in the past". On RISC OS with UnixLib this returns the time since the last hard reset, but with SharedCLibrary this returns the time since the program started - combined with the coarse resolution used internally, this almost always results in a seed of 0.
CLOCK_REALTIME meanwhile is specified as returning time since the epoch, so it should behave consistently across all platforms.
This works fine when the referenced symbol has the same prefix
as PRIVATE_PREFIX in the same file; otherwise we could also
create a macro like X() that only prepends the extern symbol
prefix but no symbol namespace prefix.
This would allow to immediately detect unintended writes out of
bounds like the ones fixed in
72b5380757 and
1c7433a5eb.
Extend the PIXEL_RECT macro to provide a variable containing the
full, padded height of the buffer, for uses that operate on the
full buffer.
Allow overwriting past the right edge of the target output rectangle,
up to an alignment of 64 pixels, but allow no overwrite past the
bottom.
Now checkasm calls the test function 'func_new' through
the wrapper 'checked_call' instead of calling it directly.
The purpose of the wrapper is to check if 'func_new' correctly
saves and restores static registers. The wrapper writes dirty
values to the static registers, and after calling 'func_new',
it checks if the dirty values in the static registers remain consistent.
Change-Id: Ia9290b55ab0f2dd87801f6fd175813d3f717d851
Both POSIX and the C standard places several environmental limits on
setjmp() invocations, with essentially anything beyond comparing the
return value with a constant as a simple branch condition being UB.
We were previously performing a function call using the setjmp()
return value as an argument, which is technically not allowed
even though it happened to work correctly in practice.
Some systems may loosen those restrictions and allow for more
flexible usage, but we shouldn't be relying on that.
Port improvements from the hi token functions to the rest of the symbol
adaption functions. These weren't originally ported since they didn't
work with arbitrary padding. In practice, zero padding is already used
and only the tests need to be updated.
Results - Neoverse N1
Old:
msac_decode_symbol_adapt4_c: 41.4 ( 1.00x)
msac_decode_symbol_adapt4_neon: 31.0 ( 1.34x)
msac_decode_symbol_adapt8_c: 54.5 ( 1.00x)
msac_decode_symbol_adapt8_neon: 32.2 ( 1.69x)
msac_decode_symbol_adapt16_c: 85.6 ( 1.00x)
msac_decode_symbol_adapt16_neon: 37.5 ( 2.28x)
New:
msac_decode_symbol_adapt4_c: 41.5 ( 1.00x)
msac_decode_symbol_adapt4_neon: 27.7 ( 1.50x)
msac_decode_symbol_adapt8_c: 55.7 ( 1.00x)
msac_decode_symbol_adapt8_neon: 30.1 ( 1.85x)
msac_decode_symbol_adapt16_c: 82.4 ( 1.00x)
msac_decode_symbol_adapt16_neon: 35.2 ( 2.34x)
It was originally disabled due to older meson versions mixing the output
of 'meson test -v' from different tests, which made the log difficult to
read. Newer versions however caches the output from each test as it runs
and prints it in one contiguous block, so that's no longer an issue.
On AArch64, the performance counter registers usually are
restricted and not accessible from user space.
On macOS, we currently use mach_absolute_time() as timer on
aarch64. This measures wallclock time but with a very coarse
resolution.
There is a private API, kperf, that one can use for getting
high precision timers though. Unfortunately, it requires running
the checkasm binary as root (e.g. with sudo).
Also, as it is a private, undocumented API, it can potentially
change at any time.
This is handled by adding a new meson build option, for switching
to this timer. If the timer source in checkasm could be changed
at runtime with an option, this wouldn't need to be a build time
option.
This allows getting benchmarks like this:
mc_8tap_regular_w16_hv_8bpc_c: 1522.1 ( 1.00x)
mc_8tap_regular_w16_hv_8bpc_neon: 331.8 ( 4.59x)
Instead of this:
mc_8tap_regular_w16_hv_8bpc_c: 9.0 ( 1.00x)
mc_8tap_regular_w16_hv_8bpc_neon: 1.9 ( 4.76x)
Co-authored-by: J. Dekker <jdek@itanimul.li>
Prints a list of cpuflags available for the current architecture.
Flags which are supported on the current system will be printed in
green, and flags which are unsupported in red with a ~ prefix.
The 6-tap sub-pel filter specialisation uses different code paths for
sharp (8-tap) and regular/smooth (6-tap) filtering kernels.
This patch enables benchmarking for the different code paths.
* Process the entire buffer to get better coverage of eob handling.
* Use a more reasonable buffer size.
* Ignore trailing dif bits to allow for more implementation flexibility.
Only print the paths relative to the argon directory. This avoids
excessive terminal line wrapping due to long path names which
otherwise interferes with the '\r' usage for progress reporting.
Martin Storsjö