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".

Reply via email to