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.
longjmp on Windows uses SEH to unwind on ARM/ARM64 too, just like on
x86_64, thus use RtlCaptureContext/RtlRestoreContext instead of
setjmp/longjmp on those architectures as well.
This allows for the use of standard VT100 escape codes for text coloring,
which simplifies things by eliminating a bunch of Windows-specific code.
This is only supported since Windows 10. Things will still run on
older systems, just without colored text output.
Pack two indices into each byte instead of storing them separately.
Reduces memory usage by up to 16 kB per sb128 in streams that uses
screen content tools when frame-threading is enabled, at the cost
of some additional computational overhead for packing/unpacking.
98b0c96d21 added an include of
src/ref.h in src/fg_apply_tmpl.c. That template source file is
included in tests/checkasm/filmgrain.c.
src/ref.h includes <stdatomic.h>. Including this file requires
declaring a dependency on stdatomic_dependencies in meson, which
provides the fallback implementation of stdatomic.h when building
with MSVC.
Add an option for selecting the core where the single thread of
checkasm runs. This allows benchmarking on specific CPU cores on
heterogenous CPUs, like ARM big.LITTLE configurations.
On Linux, one can easily wrap an invocation of checkasm with
"taskset -c <n> [...]" - so this option isn't very essential
there - however it is quite useful on Windows.
On Windows, it is somewhat possible to do the same by launching
the tool with "start /B /affinity <hexmask> [...]", but that
doesn't work well with scripting ("start" returns before the
command has finished running, and it's not obvious how to
invoke "start" from within WSL).
Using "taskset" to launch processes on specific cores within WSL
on Windows doesn't work - regardless of the Linux level affinity,
the process ends up running on the performance cores anyway.
These functions contain a number of different codepaths; try to
make sure that we hit most codepaths for each size combination.
This both gives better test coverage in one single run of checkasm,
but also should give a better averaged runtime in benchmarks.
Martin Storsjö