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

[Lynne via ffmpeg-devel <ffmpeg-devel@ffmpeg.org>]

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