[FFmpeg-devel] [PATCH] Revert "lavc/sbrdsp: R-V V neg_odd_64"

[FFmpeg-devel] [PATCH] Revert "lavc/sbrdsp: R-V V neg_odd_64"

[Rémi Denis-Courmont]

While this function can easily be written with vectors, it just fails to
get any performance improvement.

For reference, this is a simpler loop-free implementation that does get
better performance than the current one depending on hardware, but still
more or less the same metrics as the C code:

 func ff_sbr_neg_odd_64_rvv, zve64x
         li      a1, 32
         addi    a0, a0, 7
         li      t0, 8
         vsetvli zero, a1, e8, m2, ta, ma
         li      t1, 0x80
         vlse8.v v8, (a0), t0
         vxor.vx v8, v8, t1
         vsse8.v v8, (a0), t0
         ret
 endfunc

This reverts commit d06fd18f8f4c6a81ef94cbb600620d83ad51269d.
---
 libavcodec/riscv/sbrdsp_init.c |  5 -----
 libavcodec/riscv/sbrdsp_rvv.S  | 17 -----------------
 2 files changed, 22 deletions(-)

diff --git a/libavcodec/riscv/sbrdsp_init.c b/libavcodec/riscv/sbrdsp_init.c
index f937c47e22..d3bafa961e 100644
--- a/libavcodec/riscv/sbrdsp_init.c
+++ b/libavcodec/riscv/sbrdsp_init.c
@@ -26,7 +26,6 @@
 
 void ff_sbr_sum64x5_rvv(float *z);
 float ff_sbr_sum_square_rvv(float (*x)[2], int n);
-void ff_sbr_neg_odd_64_rvv(float *x);
 void ff_sbr_autocorrelate_rvv(const float x[40][2], float phi[3][2][2]);
 void ff_sbr_hf_gen_rvv(float (*X_high)[2], const float (*X_low)[2],
                        const float alpha0[2], const float alpha1[2],
@@ -64,9 +63,5 @@ av_cold void ff_sbrdsp_init_riscv(SBRDSPContext *c)
         }
         c->autocorrelate = ff_sbr_autocorrelate_rvv;
     }
-#if __riscv_xlen >= 64
-    if ((flags & AV_CPU_FLAG_RVV_I64) && (flags & AV_CPU_FLAG_RVB_ADDR))
-        c->neg_odd_64 = ff_sbr_neg_odd_64_rvv;
-#endif
 #endif
 }
diff --git a/libavcodec/riscv/sbrdsp_rvv.S b/libavcodec/riscv/sbrdsp_rvv.S
index 918c37882f..aba9a28108 100644
--- a/libavcodec/riscv/sbrdsp_rvv.S
+++ b/libavcodec/riscv/sbrdsp_rvv.S
@@ -68,23 +68,6 @@ NOHWF   fmv.x.w  a0, fa0
         ret
 endfunc
 
-#if __riscv_xlen >= 64
-func ff_sbr_neg_odd_64_rvv, zve64x
-        li      a1, 32
-        li      t1, 1 << 63
-1:
-        vsetvli t0, a1, e64, m8, ta, ma
-        vle64.v v8, (a0)
-        sub     a1, a1, t0
-        vxor.vx v8, v8, t1
-        vse64.v v8, (a0)
-        sh3add  a0, t0, a0
-        bnez    t0, 1b
-
-        ret
-endfunc
-#endif
-
 func ff_sbr_autocorrelate_rvv, zve32f
         vsetvli t0, zero, e32, m4, ta, ma
         vmv.v.x v0, zero
-- 
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".

Re: [FFmpeg-devel] [PATCH] Revert "lavc/sbrdsp: R-V V neg_odd_64"

[Lynne via ffmpeg-devel]

[-- Attachment #1.1.1.1: Type: text/plain, Size: 2757 bytes --]

On 13/05/2024 18:43, Rémi Denis-Courmont wrote:
> While this function can easily be written with vectors, it just fails to
> get any performance improvement.
> 
> For reference, this is a simpler loop-free implementation that does get
> better performance than the current one depending on hardware, but still
> more or less the same metrics as the C code:
> 
>   func ff_sbr_neg_odd_64_rvv, zve64x
>           li      a1, 32
>           addi    a0, a0, 7
>           li      t0, 8
>           vsetvli zero, a1, e8, m2, ta, ma
>           li      t1, 0x80
>           vlse8.v v8, (a0), t0
>           vxor.vx v8, v8, t1
>           vsse8.v v8, (a0), t0
>           ret
>   endfunc
> 
> This reverts commit d06fd18f8f4c6a81ef94cbb600620d83ad51269d.
> ---
>   libavcodec/riscv/sbrdsp_init.c |  5 -----
>   libavcodec/riscv/sbrdsp_rvv.S  | 17 -----------------
>   2 files changed, 22 deletions(-)
> 
> diff --git a/libavcodec/riscv/sbrdsp_init.c b/libavcodec/riscv/sbrdsp_init.c
> index f937c47e22..d3bafa961e 100644
> --- a/libavcodec/riscv/sbrdsp_init.c
> +++ b/libavcodec/riscv/sbrdsp_init.c
> @@ -26,7 +26,6 @@
>   
>   void ff_sbr_sum64x5_rvv(float *z);
>   float ff_sbr_sum_square_rvv(float (*x)[2], int n);
> -void ff_sbr_neg_odd_64_rvv(float *x);
>   void ff_sbr_autocorrelate_rvv(const float x[40][2], float phi[3][2][2]);
>   void ff_sbr_hf_gen_rvv(float (*X_high)[2], const float (*X_low)[2],
>                          const float alpha0[2], const float alpha1[2],
> @@ -64,9 +63,5 @@ av_cold void ff_sbrdsp_init_riscv(SBRDSPContext *c)
>           }
>           c->autocorrelate = ff_sbr_autocorrelate_rvv;
>       }
> -#if __riscv_xlen >= 64
> -    if ((flags & AV_CPU_FLAG_RVV_I64) && (flags & AV_CPU_FLAG_RVB_ADDR))
> -        c->neg_odd_64 = ff_sbr_neg_odd_64_rvv;
> -#endif
>   #endif
>   }
> diff --git a/libavcodec/riscv/sbrdsp_rvv.S b/libavcodec/riscv/sbrdsp_rvv.S
> index 918c37882f..aba9a28108 100644
> --- a/libavcodec/riscv/sbrdsp_rvv.S
> +++ b/libavcodec/riscv/sbrdsp_rvv.S
> @@ -68,23 +68,6 @@ NOHWF   fmv.x.w  a0, fa0
>           ret
>   endfunc
>   
> -#if __riscv_xlen >= 64
> -func ff_sbr_neg_odd_64_rvv, zve64x
> -        li      a1, 32
> -        li      t1, 1 << 63
> -1:
> -        vsetvli t0, a1, e64, m8, ta, ma
> -        vle64.v v8, (a0)
> -        sub     a1, a1, t0
> -        vxor.vx v8, v8, t1
> -        vse64.v v8, (a0)
> -        sh3add  a0, t0, a0
> -        bnez    t0, 1b
> -
> -        ret
> -endfunc
> -#endif
> -
>   func ff_sbr_autocorrelate_rvv, zve32f
>           vsetvli t0, zero, e32, m4, ta, ma
>           vmv.v.x v0, zero

Do you think a 256bit implementation be able to overcome the overhead 
and end up being faster?

[-- Attachment #1.1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 637 bytes --]

[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
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".

Re: [FFmpeg-devel] [PATCH] Revert "lavc/sbrdsp: R-V V neg_odd_64"

[Rémi Denis-Courmont]

Le 13 mai 2024 20:06:34 GMT+03:00, Lynne via ffmpeg-devel <ffmpeg-devel@ffmpeg.org> a écrit :
>On 13/05/2024 18:43, Rémi Denis-Courmont wrote:
>> While this function can easily be written with vectors, it just fails to
>> get any performance improvement.
>> 
>> For reference, this is a simpler loop-free implementation that does get
>> better performance than the current one depending on hardware, but still
>> more or less the same metrics as the C code:
>> 
>>   func ff_sbr_neg_odd_64_rvv, zve64x
>>           li      a1, 32
>>           addi    a0, a0, 7
>>           li      t0, 8
>>           vsetvli zero, a1, e8, m2, ta, ma
>>           li      t1, 0x80
>>           vlse8.v v8, (a0), t0
>>           vxor.vx v8, v8, t1
>>           vsse8.v v8, (a0), t0
>>           ret
>>   endfunc
>> 
>> This reverts commit d06fd18f8f4c6a81ef94cbb600620d83ad51269d.
>> ---
>>   libavcodec/riscv/sbrdsp_init.c |  5 -----
>>   libavcodec/riscv/sbrdsp_rvv.S  | 17 -----------------
>>   2 files changed, 22 deletions(-)
>> 
>> diff --git a/libavcodec/riscv/sbrdsp_init.c b/libavcodec/riscv/sbrdsp_init.c
>> index f937c47e22..d3bafa961e 100644
>> --- a/libavcodec/riscv/sbrdsp_init.c
>> +++ b/libavcodec/riscv/sbrdsp_init.c
>> @@ -26,7 +26,6 @@
>>     void ff_sbr_sum64x5_rvv(float *z);
>>   float ff_sbr_sum_square_rvv(float (*x)[2], int n);
>> -void ff_sbr_neg_odd_64_rvv(float *x);
>>   void ff_sbr_autocorrelate_rvv(const float x[40][2], float phi[3][2][2]);
>>   void ff_sbr_hf_gen_rvv(float (*X_high)[2], const float (*X_low)[2],
>>                          const float alpha0[2], const float alpha1[2],
>> @@ -64,9 +63,5 @@ av_cold void ff_sbrdsp_init_riscv(SBRDSPContext *c)
>>           }
>>           c->autocorrelate = ff_sbr_autocorrelate_rvv;
>>       }
>> -#if __riscv_xlen >= 64
>> -    if ((flags & AV_CPU_FLAG_RVV_I64) && (flags & AV_CPU_FLAG_RVB_ADDR))
>> -        c->neg_odd_64 = ff_sbr_neg_odd_64_rvv;
>> -#endif
>>   #endif
>>   }
>> diff --git a/libavcodec/riscv/sbrdsp_rvv.S b/libavcodec/riscv/sbrdsp_rvv.S
>> index 918c37882f..aba9a28108 100644
>> --- a/libavcodec/riscv/sbrdsp_rvv.S
>> +++ b/libavcodec/riscv/sbrdsp_rvv.S
>> @@ -68,23 +68,6 @@ NOHWF   fmv.x.w  a0, fa0
>>           ret
>>   endfunc
>>   -#if __riscv_xlen >= 64
>> -func ff_sbr_neg_odd_64_rvv, zve64x
>> -        li      a1, 32
>> -        li      t1, 1 << 63
>> -1:
>> -        vsetvli t0, a1, e64, m8, ta, ma
>> -        vle64.v v8, (a0)
>> -        sub     a1, a1, t0
>> -        vxor.vx v8, v8, t1
>> -        vse64.v v8, (a0)
>> -        sh3add  a0, t0, a0
>> -        bnez    t0, 1b
>> -
>> -        ret
>> -endfunc
>> -#endif
>> -
>>   func ff_sbr_autocorrelate_rvv, zve32f
>>           vsetvli t0, zero, e32, m4, ta, ma
>>           vmv.v.x v0, zero
>
>Do you think a 256bit implementation be able to overcome the overhead and end up being faster?

Based on Sunyeuchi's tests, it gets worse with larger vectors.

I guess the C code is just bound by memory bandwidth, since the "calculations" are so trivial, and thus we can't really beat C here.
_______________________________________________
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".