This PR adds support for Arm aarch64 builds, including the corresponding NEON accelerated vector library.
As part of this work I also improved testing:
- Native C++ unit tests support using `googletest` integrated into CMake/CTest.
- First unit test suite added, for 4-wide SIMD implementations.
- Command line functional tests can target any build, not just AVX2.
Note rebuilding reference data for older encoders now needs a
modified encoder which emits a version 2.1 performance metric
field, so we get consistent data from all of them.
The current code makes a copy of the original data (imageblock.orig_data), transferring into working buffers (imageblock.data_[rgba]) for each encoding trial. The working buffer is overwritten by each trial, so we have to repopulate the working buffer after each trial which is a significant (10-15%) overhead for the fast searches. In reality the output of the decompression is never really used - we only need to compute RMS error for the trial (which can be done inline) and throw the output away.
This patch removes the orig_data copy of the data, and uses only the data_[rgba] fields. Data encoding transforms at the start/end of the block are done in-place, and the data is no longer overwritten during each trial. Some parts of the code needed to be adapted to the fact that the "working" encoding of the data is not the original encoding.
PSNR is identical for LDR images, but has minor changes for HDR images. This is because we now compute derivatives on a converted form of the modified data, so we have an additional conversion round-trip which can add some rounding. On our test set this actually slightly improves PSNR, but I suspect this is just luck.
* Input images can now include jpg files
* Output images are stored for all quality levels, not just the last one run
* Baseline reference for comparison is configurable (defaults to last stable release).
* Baseline reference can now include a "last known good" master result set.
In the original code running trials for 2 or 3 partitions using two planes of weights, two different color components were tested as candidates for the second weight plane. The second component is rarely a good candidate, so the IQ benefits of this are tiny given the processing cost.
For the Kodak test set with -medium compression we get an average of 8% performance improvement, for negligible quality loss (< 0.01 dB).
Coding time: Mean: +1.08x Std: 0.03x
Image quality: Mean: -0.00 dB Std: 0.00 dB
There is a larger quality impact for -through and -exhaustive - although it is still very small (0.03 dB) - in particular for normal maps. However, in reality no developers are really using those search modes in production as they are far too slow so this seems acceptable.
This phase introduces the first phase of the API split between the API front-end and the CODEC backed. However, some aspects of the final design are not yet supported:
This build only only supports automatic multi-threading; no user owned thread pools are supported.
Some memory allocations still tied to the compression pass, not the context, so reusing the context will have higher than planned CPU overhead due to the repeated memory allocation (although the impact is probably small unless compression small image).
The input image layout is still the legacy format and must be pre-padded by the caller for any pass using the area-based perceptual metrics.
* All CLI options now have at least some positive coverage
that the option is accepted and used.
* All CLI options that accept additonal arguments now have
full truncated command line negative test coverage.
* Tests for esw/dsw swizzle validity have been added.
This PR adds the beginnings of a command line functional test suite, ensuring that command line options are correctly wired up and processed. For this first PR not every option is tested, but this suite includes positive tests and negative tests for all of the common operations. See the testing documentation page for more details on how to run these tests.
Some negative tests are currently marked as skipped pending bug fix (notably, the code is intolerant of missing input files, or output directories), so the test suite does currently pass on both Windows and Linux (macOS should pass, but is not tested).
In addition this commit increases the astcenc stack size on Windows to 4MB. We have had persistent problem with stack space on Windows builds, which only have 1MB stacks by default compared to Linux which reserves 8MB. Something in a recent VS2019 upgrade make the build use more stack space which just pushed us over the 1MB limit, so bumped these up to 4MB which should be more than enough.
ql