On Thu, 14 Mar 2024, J. Dekker wrote:
Martin Storsjö <mar...@martin.st> writes:
The first 32 elements of each row were correct, while the
last 16 were scrambled.
This hasn't been noticed, because the checkasm test erroneously
only checked half of the output (for 8 bit functions), and
apparently none of the samples as part of "fate-hevc" seem to
trigger this specific function.
---
libavcodec/aarch64/hevcdsp_epel_neon.S | 14 +++++++++-----
1 file changed, 9 insertions(+), 5 deletions(-)
Thanks for the fixes, wonder if we should use checkasm_check()
exclusively in checkasm rather than memcmp(), would probably be useful.
Wherever it makes sense and works, then yes, using checkasm_check()
probably is useful. (Within dav1d, we use it in most tests except for a
few.)
FWIW, many checkasm tests seem to have pretty naive setups, where e.g. all
rows are tightly packed. If they'd use a bigger stride with more padding
between rows, one can also detect some other cases of potential asm bugs.
Pushed set
Thanks!
// 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".
