On Sat, Feb 08, 2025 at 01:59:32AM +0100, Lynne wrote:
> On 07/02/2025 20:42, Krzysztof Pyrkosz via ffmpeg-devel wrote:
> > This change removes one extra floating point operation and simplifies
> > load operations at the beginning of the loop by using dedicated register
> > for each of the 5 pointers and interleaving it with calculations. The
> > first case seems to be a bit slower, but the performance increase is
> > substantial in the other two.
> >
> > A78 before:
> > postfilter_15_neon: 1684.8 ( 4.23x)
> > postfilter_512_neon: 1395.5 ( 5.10x)
> > postfilter_1022_neon: 1357.0 ( 5.25x)
> >
> > After:
> > postfilter_15_neon: 1742.2 ( 4.09x)
> > postfilter_512_neon: 1169.8 ( 6.09x)
> > postfilter_1022_neon: 1160.0 ( 6.12x)
> >
> >
> > A72 before:
> > postfilter_15_neon: 3144.8 ( 2.39x)
> > postfilter_512_neon: 3141.2 ( 2.39x)
> > postfilter_1022_neon: 3230.0 ( 2.33x)
> >
> > After:
> > postfilter_15_neon: 2847.8 ( 2.64x)
> > postfilter_512_neon: 2877.8 ( 2.61x)
> > postfilter_1022_neon: 2837.2 ( 2.65x)
> >
> >
> > x13s before:
> > postfilter_15_neon: 1615.4 ( 2.61x)
> > postfilter_512_neon: 963.1 ( 4.39x)
> > postfilter_1022_neon: 963.6 ( 4.39x)
> >
> > After:
> > postfilter_15_neon: 1749.6 ( 2.41x)
> > postfilter_512_neon: 707.1 ( 5.97x)
> > postfilter_1022_neon: 706.1 ( 5.99x)
> >
> >
> > Krzysztof
> >
> > ---
> > libavcodec/aarch64/opusdsp_neon.S | 31 ++++++++++++-------------------
> > 1 file changed, 12 insertions(+), 19 deletions(-)
> >
> > diff --git a/libavcodec/aarch64/opusdsp_neon.S
> > b/libavcodec/aarch64/opusdsp_neon.S
> > index 253825aa61..990fc44c70 100644
> > --- a/libavcodec/aarch64/opusdsp_neon.S
> > +++ b/libavcodec/aarch64/opusdsp_neon.S
> > @@ -55,35 +55,28 @@ endfunc
> > function ff_opus_postfilter_neon, export=1
> > ld1 {v0.4s}, [x2]
> > + sub x5, x0, w1, sxtw #2
> > + sub x1, x5, #8
> > dup v1.4s, v0.s[1]
> > dup v2.4s, v0.s[2]
> > dup v0.4s, v0.s[0]
> > - add w1, w1, #2
> > - sub x1, x0, x1, lsl #2
> > -
> > - ld1 {v3.4s}, [x1]
> > + ld1 {v3.4s}, [x1], #16
> > + sub x4, x5, #4
> > + add x6, x5, #4
> > fmul v3.4s, v3.4s, v2.4s
> > -1: add x1, x1, #4
> > - ld1 {v4.4s}, [x1]
> > - add x1, x1, #4
> > - ld1 {v5.4s}, [x1]
> > - add x1, x1, #4
> > - ld1 {v6.4s}, [x1]
> > - add x1, x1, #4
> > - ld1 {v7.4s}, [x1]
> > -
> > +1: ld1 {v7.4s}, [x1], #16
> > + ld1 {v4.4s}, [x4], #16
> > fmla v3.4s, v7.4s, v2.4s
> > + ld1 {v6.4s}, [x6], #16
> > + ld1 {v5.4s}, [x5], #16
> > fadd v6.4s, v6.4s, v4.4s
> > + fmla v3.4s, v5.4s, v0.4s
> > ld1 {v4.4s}, [x0]
> > - fmla v4.4s, v5.4s, v0.4s
> > -
> > - fmul v6.4s, v6.4s, v1.4s
> > - fadd v6.4s, v6.4s, v3.4s
> > -
> > - fadd v4.4s, v4.4s, v6.4s
> > + fmla v3.4s, v6.4s, v1.4s
> > + fadd v4.4s, v4.4s, v3.4s
> > fmul v3.4s, v7.4s, v2.4s
> > st1 {v4.4s}, [x0], #16
>
> This function was written and optimized for A53 cores. The fmla chain is
> very performance sensitive on in-order CPUs?
> Could you post a perf difference from an in-order CPU?
Here are my benchmarks on Raspberry Pi 3B+.
Before:
deemphasis_neon: 4121.8 ( 2.11x)
postfilter_15_neon: 9405.2 ( 2.46x)
postfilter_512_neon: 9457.0 ( 2.44x)
postfilter_1022_neon: 9398.0 ( 2.46x)
After:
deemphasis_neon: 4135.8 ( 2.10x)
postfilter_15_neon: 7967.2 ( 2.90x)
postfilter_512_neon: 7980.2 ( 2.89x)
postfilter_1022_neon: 7980.0 ( 2.89x)
Krzysztof
_______________________________________________
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".
