aboutsummaryrefslogtreecommitdiffstats
path: root/libavformat/dashdec.c
diff options
context:
space:
mode:
authorRémi Denis-Courmont <remi@remlab.net>2023-11-19 17:50:49 +0200
committerRémi Denis-Courmont <remi@remlab.net>2023-11-23 18:57:18 +0200
commit0183c2c83091b727f3b881c8797b45c8f6915f1b (patch)
tree39e44c5cb90a94dbd4b9cc57caee29d767493499 /libavformat/dashdec.c
parentb88d4058f95de7ebf8322358d2e72cbeaffec49e (diff)
downloadffmpeg-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/dashdec.c')
0 files changed, 0 insertions, 0 deletions