On Sat, 24 Sep 2022, Lynne wrote:
What about ac3dsp then - that one seems like it's fairly optimized for arm?
Haven't touched them, they're still being used. Unfortunately, for AC3,
the full MDCT optimizations in lavc do make a difference and the overall
decoder becomes 15% slower with this patch on for aarch64 with lavu/tx's
asm disabled and 7% slower with lavu/tx's asm enabled.
Hmm, that's a shame...
I do plan to write an aarch64 MDCT NEON SIMD code in a month or so,
unless someone is faster, which should make the decoder at least 10%
faster with lavu/tx.
Would you consider holding off of converting the ac3 decoder until this
point, to avoid unnecessary temporary performance regressions at least for
the architectures that are covered by the new lavu/tx framework?
If you'd like to help out, I've documented the C factorizations used in
docs/transforms.md.
Sorry, I don't think I have time at the moment to take on writing new code
from scratch for this...
I could maybe consider porting the aarch64 assembly to arm32; if it's not
register starved, it's usually quite straightforward to do such rewrites
(there's either half the number of SIMD registers compared to aarch64, or
the same number but half the length).
The reason why I'm asking about arm32, is because ffmpeg has got a bunch
of users who have spent a fair amount of effort on reaching specific
performance levels for some codecs, both for raspberry pi 1 (which doesn't
have neon but only vfp) and for the newer ones with neon. I don't remember
exactly which codecs are relevant for these users - I doubt opus is, but
ac3 and dca are, iirc.
I'm CCing Ben Avison who has contributed a lot of optimizations in this
area.
// 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".
