diff options
author | Rémi Denis-Courmont <remi@remlab.net> | 2023-11-19 17:50:49 +0200 |
---|---|---|
committer | Rémi Denis-Courmont <remi@remlab.net> | 2023-11-23 18:57:18 +0200 |
commit | 0183c2c83091b727f3b881c8797b45c8f6915f1b (patch) | |
tree | 39e44c5cb90a94dbd4b9cc57caee29d767493499 /libavformat/rtpenc_mpv.c | |
parent | b88d4058f95de7ebf8322358d2e72cbeaffec49e (diff) | |
download | ffmpeg-0183c2c83091b727f3b881c8797b45c8f6915f1b.tar.gz |
lavc/aacpsdsp: use LMUL=2 and amortise strides
The input is laid out in 16 segments, of which 13 actually need to be
loaded. There are no really efficient ways to deal with this:
1) If we load 8 segments wit unit stride, then narrow to 16 segments with
right shifts, we can only get one half-size vector per segment, or just 2
elements per vector (EMUL=1/2) - at least with 128-bit vectors.
This ends up unsurprisingly about as fas as the C code.
2) The current approach is to load with strides. We keep that approach,
but improve it using three 4-segmented loads instead of 12 single-segment
loads. This divides the number of distinct loaded addresses by 4.
3) A potential third approach would be to avoid segmentation altogether
and splat the scalar coefficient into vectors. Then we can use a
unit-stride and maximum EMUL. But the downside then is that we have to
multiply the 3 (of 16) unused segments with zero as part of the
multiply-accumulate operations.
In addition, we also reuse vectors mid-loop so as to increase the EMUL
from 1 to 2, which also improves performance a little bit.
Oeverall the gains are quite small with the device under test, as it does
not deal with segmented loads very well. But at least the code is tidier,
and should enjoy bigger speed-ups on better hardware implementation.
Before:
ps_hybrid_analysis_c: 1819.2
ps_hybrid_analysis_rvv_f32: 1037.0 (before)
ps_hybrid_analysis_rvv_f32: 990.0 (after)
Diffstat (limited to 'libavformat/rtpenc_mpv.c')
0 files changed, 0 insertions, 0 deletions