* [FFmpeg-devel] [PATCHv2 2/2] lavc/flacdsp: optimise RVV vector type for lpc16
@ 2024-05-15 17:47 Rémi Denis-Courmont
2024-05-15 20:16 ` [FFmpeg-devel] [PATCH 3/3] lavc/flacdsp: optimise RVV vector type for lpc32 Rémi Denis-Courmont
0 siblings, 1 reply; 2+ messages in thread
From: Rémi Denis-Courmont @ 2024-05-15 17:47 UTC (permalink / raw)
To: ffmpeg-devel
This calculates the optimal vector type value at run-time based on the
hardware vector length and the FLAC LPC prediction order. In this
particular case, the additional computation is easily amortised over
the loop iterations:
T-Head C908:
C V before V after
1 48.0 214.7 95.2
2 64.7 214.2 94.7
3 79.7 213.5 94.5
4 96.2 196.5 94.2 #
5 111.0 195.7 118.5
6 127.0 211.2 102.0
7 143.7 194.2 101.5
8 175.7 193.2 101.2 #
9 176.2 224.2 126.0
10 191.5 192.0 125.5
11 224.5 191.2 124.7
12 223.0 190.2 124.2
13 239.2 189.5 123.7
14 253.7 188.7 139.5
15 286.2 188.0 122.7
16 284.0 187.0 122.5 #
17 300.2 186.5 186.5
18 314.0 185.5 185.7
19 329.7 184.7 185.0
20 343.0 184.2 184.2
21 358.7 199.2 183.7
22 371.7 182.7 182.7
23 387.5 181.7 182.0
24 400.7 181.0 181.2
25 431.5 180.2 196.5
26 443.7 195.5 196.0
27 459.0 178.7 196.2
28 470.7 177.7 194.2
29 470.0 177.0 193.5
30 481.2 176.2 176.5
31 496.2 175.5 175.7
32 507.2 174.7 191.0 #
# Power of two boundary.
With 128-bit vectors, improvements are expected for the first two
test cases only. For the other two, there is overhead but below noise.
Improvements should be better observable with prediction order of 8
and less, or on hardware with larger vector sizes.
The same optimisation strategy should be applicable to LPC32
(and work-in-progress LPC33), but is left as a future exercise.
---
libavcodec/riscv/flacdsp_init.c | 2 +-
libavcodec/riscv/flacdsp_rvv.S | 12 ++++++++++--
2 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/libavcodec/riscv/flacdsp_init.c b/libavcodec/riscv/flacdsp_init.c
index 4f1652dbe7..735aec0691 100644
--- a/libavcodec/riscv/flacdsp_init.c
+++ b/libavcodec/riscv/flacdsp_init.c
@@ -71,7 +71,7 @@ av_cold void ff_flacdsp_init_riscv(FLACDSPContext *c, enum AVSampleFormat fmt,
if ((flags & AV_CPU_FLAG_RVV_I32) && (flags & AV_CPU_FLAG_RVB_ADDR)) {
int vlenb = ff_get_rv_vlenb();
- if (vlenb >= 16)
+ if ((flags & AV_CPU_FLAG_RVB_BASIC) && vlenb >= 16)
c->lpc16 = ff_flac_lpc16_rvv;
# if (__riscv_xlen >= 64)
diff --git a/libavcodec/riscv/flacdsp_rvv.S b/libavcodec/riscv/flacdsp_rvv.S
index 6287faa260..45608dfd47 100644
--- a/libavcodec/riscv/flacdsp_rvv.S
+++ b/libavcodec/riscv/flacdsp_rvv.S
@@ -20,8 +20,16 @@
#include "libavutil/riscv/asm.S"
-func ff_flac_lpc16_rvv, zve32x
- vsetvli zero, a2, e32, m8, ta, ma
+func ff_flac_lpc16_rvv, zve32x, zbb
+ csrr t0, vlenb
+ addi t2, a2, -1
+ clz t0, t0
+ clz t2, t2
+ addi t0, t0, VTYPE_E32 | VTYPE_M8 | VTYPE_TA | VTYPE_MA
+ li t1, VTYPE_E32 | VTYPE_M1 | VTYPE_TA | VTYPE_MA
+ sub t0, t0, t2 // t0 += log2(next_power_of_two(len) / vlenb) + 1
+ max t0, t0, t1
+ vsetvl zero, a2, t0
vle32.v v8, (a1)
sub a4, a4, a2
vle32.v v16, (a0)
--
2.43.0
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
^ permalink raw reply [flat|nested] 2+ messages in thread
* [FFmpeg-devel] [PATCH 3/3] lavc/flacdsp: optimise RVV vector type for lpc32
2024-05-15 17:47 [FFmpeg-devel] [PATCHv2 2/2] lavc/flacdsp: optimise RVV vector type for lpc16 Rémi Denis-Courmont
@ 2024-05-15 20:16 ` Rémi Denis-Courmont
0 siblings, 0 replies; 2+ messages in thread
From: Rémi Denis-Courmont @ 2024-05-15 20:16 UTC (permalink / raw)
To: ffmpeg-devel
This is pretty much the same as for lpc16, though it only improves half
as large prediction orders. With 128-bit vectors, this gives:
C V old V new
1 69.2 181.5 95.5
2 107.7 180.7 95.2
3 145.5 180.0 103.5
4 183.0 179.2 102.7
5 220.7 178.5 128.0
6 257.7 194.0 127.5
7 294.5 193.7 126.7
8 331.0 193.0 126.5
Larger prediction orders see no significant changes at that size.
The code is pretty ugly, so clean-up suggestions are most welcome.
---
libavcodec/riscv/flacdsp_init.c | 15 ++++++++-------
libavcodec/riscv/flacdsp_rvv.S | 25 ++++++++++++++++++++-----
2 files changed, 28 insertions(+), 12 deletions(-)
diff --git a/libavcodec/riscv/flacdsp_init.c b/libavcodec/riscv/flacdsp_init.c
index 735aec0691..830ae36534 100644
--- a/libavcodec/riscv/flacdsp_init.c
+++ b/libavcodec/riscv/flacdsp_init.c
@@ -71,17 +71,18 @@ av_cold void ff_flacdsp_init_riscv(FLACDSPContext *c, enum AVSampleFormat fmt,
if ((flags & AV_CPU_FLAG_RVV_I32) && (flags & AV_CPU_FLAG_RVB_ADDR)) {
int vlenb = ff_get_rv_vlenb();
- if ((flags & AV_CPU_FLAG_RVB_BASIC) && vlenb >= 16)
+ if ((flags & AV_CPU_FLAG_RVB_BASIC) && vlenb >= 16) {
c->lpc16 = ff_flac_lpc16_rvv;
# if (__riscv_xlen >= 64)
- if (flags & AV_CPU_FLAG_RVV_I64) {
- if (vlenb > 16)
- c->lpc32 = ff_flac_lpc32_rvv_simple;
- else
- c->lpc32 = ff_flac_lpc32_rvv;
- }
+ if (flags & AV_CPU_FLAG_RVV_I64) {
+ if (vlenb > 16)
+ c->lpc32 = ff_flac_lpc32_rvv_simple;
+ else
+ c->lpc32 = ff_flac_lpc32_rvv;
+ }
# endif
+ }
c->wasted32 = ff_flac_wasted32_rvv;
diff --git a/libavcodec/riscv/flacdsp_rvv.S b/libavcodec/riscv/flacdsp_rvv.S
index 7d83909335..b292c15c8c 100644
--- a/libavcodec/riscv/flacdsp_rvv.S
+++ b/libavcodec/riscv/flacdsp_rvv.S
@@ -20,6 +20,12 @@
#include "libavutil/riscv/asm.S"
+ .macro vnarrow rd, rs
+ xori \rd, \rs, 4
+ addi \rd, \rd, -9
+ xori \rd, \rd, 4
+ .endm
+
func ff_flac_lpc16_rvv, zve32x, zbb
csrr t0, vlenb
addi t2, a2, -1
@@ -83,22 +89,31 @@ func ff_flac_lpc32_rvv, zve64x
ret
endfunc
-func ff_flac_lpc32_rvv_simple, zve64x
- vsetivli zero, 1, e64, m1, ta, ma
+func ff_flac_lpc32_rvv_simple, zve64x, zbb
+ csrr t0, vlenb
+ addi t2, a2, -1
+ clz t0, t0
+ clz t2, t2
+ addi t0, t0, (VTYPE_E64 | VTYPE_M8 | VTYPE_TA | VTYPE_MA) + 1
+ li t1, VTYPE_E64 | VTYPE_M1 | VTYPE_TA | VTYPE_MA
+ sub t0, t0, t2 // t0 += log2(next_power_of_two(len) / vlenb) - 1
+ max t3, t0, t1
+ vnarrow t2, t3
+ vsetvl zero, a2, t3 // e64
vmv.s.x v0, zero
- vsetvli zero, a2, e32, m4, ta, ma
+ vsetvl zero, zero, t2 // e32
vle32.v v8, (a1)
sub a4, a4, a2
vle32.v v16, (a0)
sh2add a0, a2, a0
1:
vwmul.vv v24, v8, v16
- vsetvli zero, zero, e64, m8, ta, ma
+ vsetvl zero, zero, t3 // e64
vredsum.vs v24, v24, v0
lw t0, (a0)
addi a4, a4, -1
vmv.x.s t1, v24
- vsetvli zero, zero, e32, m4, ta, ma
+ vsetvl zero, zero, t2 // e32
sra t1, t1, a3
add t0, t0, t1
vslide1down.vx v16, v16, t0
--
2.43.0
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2024-05-15 20:16 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-05-15 17:47 [FFmpeg-devel] [PATCHv2 2/2] lavc/flacdsp: optimise RVV vector type for lpc16 Rémi Denis-Courmont
2024-05-15 20:16 ` [FFmpeg-devel] [PATCH 3/3] lavc/flacdsp: optimise RVV vector type for lpc32 Rémi Denis-Courmont
Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
This inbox may be cloned and mirrored by anyone:
git clone --mirror https://master.gitmailbox.com/ffmpegdev/0 ffmpegdev/git/0.git
# If you have public-inbox 1.1+ installed, you may
# initialize and index your mirror using the following commands:
public-inbox-init -V2 ffmpegdev ffmpegdev/ https://master.gitmailbox.com/ffmpegdev \
ffmpegdev@gitmailbox.com
public-inbox-index ffmpegdev
Example config snippet for mirrors.
AGPL code for this site: git clone https://public-inbox.org/public-inbox.git