Every use is replaced with a block-wide per-channel weighting.
This removes support for:
* -v and -va for effor function control
* -b for deblocking
* -a for alpha weighting (still supported for RDO)
This change makes the output of the codec invariant across operating systems (removed std::math dependency), and across CPU architectures (NEON vector code now matches the halving reduction patterns used by x86-64).
This PR implements the ability to convert floats stored in vfloat4 vectors to fp16 bit patterns stored in vint4 vectors. Scalar versions are also provided as overloaded functions of the same name, for sake of convenience.
The code has been refactored to take advantage of the vectorization opportunities this gives, in particular using NEON (Arm) and F16C (x86-64) ISA support for float<>fp16 conversion. The F16C support is tied to the AVX2 enable config option, it is not a separate enable. In cases where the soft-float code is not needed, code size reduces by ~5KB.
Prior to this PR we had two vec4 implementations for floats, the legacy "float4" and the newer "vfloat4". The newer vfloat4 is a superset of the capabilities of the float4, and using it everywhere would give other opportunities to optimize by e.g. using the conditional select functionality rather than scalarizing chunks of vector code.
This patch is just the basic migration - where possible I've translated the original code without additional refactoring. Further optimizations to make better use of the vfloat4 functionality will come later. Overall this patch has no impact on IQ or performance, but does give a slight reduction in code size.
This is an IQ bug introduced in 2.2 caused by an unneeded
clamp on the variance summed area table. The SAT is already
padded with the kernel radius, so the clamp isn't needed.
The input image initital transfer into the table _is_ still
clamped, as the input image isn't padded.
This implementation alters the algorithm and vectorizes these two functions.
The algorithm change will have a minor image quality impact; it now uses a faster approximation for selecting which component to assign to a second plane when choosing a partition. There is an insignificant IQ hit on -medium (under < 0.01dB), as we rarely use two planes anyway, and a slightly larger one on -thorough (under < -0.05dB). The significant (>10%) performance gain on -thorough is worth the quality loss (i.e. users are more likely to use -thorough if it's faster, and the overall IQ gain vs medium is still net positive).
This implementation changes the core codec API for images so they they are no longer 3D arrays (which require a pointer tree to get allocated and created). Instead images are passed as an array of 2D image slices, building up 3D images in layers. Each slice consists of tightly packed 4 channel data with no padding between rows.
The common case usage of ASTC is 2D images, so in the common case the slice array consists of just a single slice, while leaving support for 3D as an option in the API when it's needed. In addition passing raw data slices loaded from other libraries is now possible, as there is no longer need for the pointer preamble. This can remove additional memory allocation and copy overheads
Slight performance improvement for -fastest is expected - but will be < 1%. The main improvement here is just improved ease of integration with data from other sources, and the ability to avoid two memory allocations for the same data.
Note that this change is ONLY the API change; the command line wrapper is still creating copies of the data from stb_image and tiny_exr, which isn't really needed. This will get fixed in a later PR.
Code to use this for HDR images is also implemented for the CLI
wrapper, but currently the HDR functionality in the wrapper is
still routed though FP16. Local testing indicates that this works
as expected.
* Update test data reference CSV
* Formatting cleanups
* Make image data type flexible
- No new types supported yet, but it's a precursor to just supporting f32 as an interface type.
Implement a new approach to threading the library compression function, removing the use of strict N-thread barriers to allow any number of threads (up to the max requested when the context was created, as the memory pool is still preallocated).
The new parallel manager allows:
* Single threaded init - the first thread to reach it runs it (optional)
* Parallel dynamic task assignment - worker threads keep requesting work until none remains.
* Completion synchronization - don't continue until all workers have exited the dynamic task assignment.
* Single threaded term - the first thread to reach it runs it (optional).
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.
ql