On Wed, 25 May 2022, Swinney, Jonathan wrote:
This is a resubmission of changes to the hscale function for aarch64. I
added a test as a separate patch so that it would be easier to get
consistent before and after performance data. After Martin already
submitted the improvement to the final section which adds up the
results, the additional performance gains of the changes to the
filterSize == 8 were marginal, so I took them out of this patch to show
only the work with clear improvement. I may submit changes to the other
function in the future.
I also removed my changes to vertical scaling from the patch series
because there are some problems with the existing checkasm for
yuv2planeX in aarch64. Martin, do you know why there is a different
reference function used for testing in tests/checkasm/sw_scale.c than
the one in libswscale/output.c? I haven't figured out how to reconcile
these differences so I will resubmit that change later once I do.
It looks to me like that there's some amount of functions that aren't
bitexact there, see the comment:
// The reference function is not the scalar function selected when mmx
// is deactivated as the SIMD functions do not give the same result as
// the scalar ones due to rounding. The SIMD functions are activated by
// the flag SWS_ACCURATE_RND
This is a bit tricky...
If I understand it, the test tries to do a bitexact test of what the
non-bitexact function does, and thus provides a separate C replacement
that does rounding in the same way as this specific SIMD function.
I think a more comprehensive test would work like this:
- Initialize sws with SWS_ACCURATE_RND
- Do the regular check_func()
- Test that the output indeed is exact compared with the reference (the
default C function used in swscale)
If I understand correctly, the x86 routines are inexact and wouldn't be
tested by this. Therefore, afterwards, the test could do this:
- Initialize sws without SWS_ACCURATE_RND
- Call check_func("yuv2yuv..._inexact") to get a separate function name
and reference for that
- Do a fuzzy test for the output, i.e. allow each pixel to be off by e.g.
1 from the expected reference value.
This would be less strict for the current x86 routines, as it doesn't
check that it rounds exactly like the specific reference in the test, but
would allow testing all exact functions, and all inexact functions even if
they round differently.
// Martin
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".