[FFmpeg-devel] [PATCH] lavc/vc1dsp: R-V V mspel_pixels

[Rémi Denis-Courmont]

Le lauantaina 4. toukokuuta 2024, 13.01.05 EEST uk7b at foxmail.com a écrit :
> From: sunyuechi <sunyuechi at iscas.ac.cn>
> 
> vc1dsp.avg_vc1_mspel_pixels_tab[0][0]_c: 869.7
> vc1dsp.avg_vc1_mspel_pixels_tab[0][0]_rvv_i32: 148.7
> vc1dsp.avg_vc1_mspel_pixels_tab[1][0]_c: 220.5
> vc1dsp.avg_vc1_mspel_pixels_tab[1][0]_rvv_i64: 56.2
> vc1dsp.put_vc1_mspel_pixels_tab[0][0]_c: 523.7
> vc1dsp.put_vc1_mspel_pixels_tab[0][0]_rvv_i32: 82.0
> vc1dsp.put_vc1_mspel_pixels_tab[1][0]_c: 138.5
> vc1dsp.put_vc1_mspel_pixels_tab[1][0]_rvv_i64: 23.7
> ---
>  libavcodec/riscv/vc1dsp_init.c |  8 +++++
>  libavcodec/riscv/vc1dsp_rvv.S  | 66 ++++++++++++++++++++++++++++++++++
>  2 files changed, 74 insertions(+)
> 
> diff --git a/libavcodec/riscv/vc1dsp_init.c b/libavcodec/riscv/vc1dsp_init.c
> index e47b644f80..610c43a1a3 100644
> --- a/libavcodec/riscv/vc1dsp_init.c
> +++ b/libavcodec/riscv/vc1dsp_init.c
> @@ -29,6 +29,10 @@ void ff_vc1_inv_trans_8x8_dc_rvv(uint8_t *dest, ptrdiff_t
> stride, int16_t *block void ff_vc1_inv_trans_4x8_dc_rvv(uint8_t *dest,
> ptrdiff_t stride, int16_t *block); void ff_vc1_inv_trans_8x4_dc_rvv(uint8_t
> *dest, ptrdiff_t stride, int16_t *block); void
> ff_vc1_inv_trans_4x4_dc_rvv(uint8_t *dest, ptrdiff_t stride, int16_t
> *block); +void ff_put_pixels16x16_rvv(uint8_t *dst, const uint8_t *src,
> ptrdiff_t line_size, int rnd); +void ff_put_pixels8x8_rvv(uint8_t *dst,
> const uint8_t *src, ptrdiff_t line_size, int rnd); +void
> ff_avg_pixels16x16_rvv(uint8_t *dst, const uint8_t *src, ptrdiff_t
> line_size, int rnd); +void ff_avg_pixels8x8_rvv(uint8_t *dst, const uint8_t
> *src, ptrdiff_t line_size, int rnd);
> 
>  av_cold void ff_vc1dsp_init_riscv(VC1DSPContext *dsp)
>  {
> @@ -38,9 +42,13 @@ av_cold void ff_vc1dsp_init_riscv(VC1DSPContext *dsp)
>      if (flags & AV_CPU_FLAG_RVV_I32 && ff_get_rv_vlenb() >= 16) {
>          dsp->vc1_inv_trans_4x8_dc = ff_vc1_inv_trans_4x8_dc_rvv;
>          dsp->vc1_inv_trans_4x4_dc = ff_vc1_inv_trans_4x4_dc_rvv;
> +        dsp->put_vc1_mspel_pixels_tab[0][0] = ff_put_pixels16x16_rvv;
> +        dsp->avg_vc1_mspel_pixels_tab[0][0] = ff_avg_pixels16x16_rvv;
>          if (flags & AV_CPU_FLAG_RVV_I64) {
>              dsp->vc1_inv_trans_8x8_dc = ff_vc1_inv_trans_8x8_dc_rvv;
>              dsp->vc1_inv_trans_8x4_dc = ff_vc1_inv_trans_8x4_dc_rvv;
> +            dsp->put_vc1_mspel_pixels_tab[1][0] = ff_put_pixels8x8_rvv;
> +            dsp->avg_vc1_mspel_pixels_tab[1][0] = ff_avg_pixels8x8_rvv;
>          }
>      }
>  #endif
> diff --git a/libavcodec/riscv/vc1dsp_rvv.S b/libavcodec/riscv/vc1dsp_rvv.S
> index 4a00945ead..48244f91aa 100644
> --- a/libavcodec/riscv/vc1dsp_rvv.S
> +++ b/libavcodec/riscv/vc1dsp_rvv.S
> @@ -111,3 +111,69 @@ func ff_vc1_inv_trans_4x4_dc_rvv, zve32x
>          vsse32.v      v0, (a0), a1
>          ret
>  endfunc
> +
> +func ff_put_pixels16x16_rvv, zve32x
> +        vsetivli      zero, 16, e8, m1, ta, ma
> +        .irp n 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30
> +        vle8.v        v\n, (a1)
> +        add           a1, a1, a2
> +        .endr
> +        vle8.v        v31, (a1)

Is it not faster to compute the address ahead of time, e.g.:

add t1, a2, a1
vle8.v vN, (a1)
sh1add a1, a2, a1
vle8.v vN+1, (t1)

...and so on? Even on a reordering core, you can't eliminate stall on data 
dependency if there is nothing else to be done.

(Ditto below and in other patches.)

> +        .irp n 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30
> +        vse8.v        v\n, (a0)
> +        add           a0, a0, a2
> +        .endr
> +        vse8.v        v31, (a0)
> +
> +        ret
> +endfunc
> +
> +func ff_put_pixels8x8_rvv, zve64x
> +        vsetivli      zero, 8, e8, mf2, ta, ma
> +        vlse64.v      v8, (a1), a2
> +        vsse64.v      v8, (a0), a2

Copying 64-bit quantities should not need RVV at all. Maybe the C version 
needs to be improved instead, but if that is not possible, then an RVI version 
may be more portable and work just as well.

> +
> +        ret
> +endfunc
> +
> +func ff_avg_pixels16x16_rvv, zve32x
> +        csrwi         vxrm, 0
> +        vsetivli      zero, 16, e8, m1, ta, ma
> +        li            t0, 128
> +
> +        .irp n 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30
> +        vle8.v        v\n, (a1)
> +        add           a1, a1, a2
> +        .endr
> +        vle8.v        v31, (a1)
> +        .irp n 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14
> +        vle8.v        v\n, (a0)
> +        add           a0, a0, a2
> +        .endr
> +        vle8.v        v15, (a0)
> +        vsetvli       zero, t0, e8, m8, ta, ma
> +        vaaddu.vv     v0, v0, v16
> +        vaaddu.vv     v8, v8, v24
> +        vsetivli      zero, 16, e8, m1, ta, ma
> +        .irp n  15, 14, 13, 12, 11, 10, 9, 8, 7, 6, 5, 4, 3, 2, 1
> +        vse8.v        v\n, (a0)
> +        sub           a0, a0, a2
> +        .endr
> +        vse8.v        v0, (a0)
> +
> +        ret
> +endfunc
> +
> +func ff_avg_pixels8x8_rvv, zve64x
> +        csrwi         vxrm, 0
> +        li            t0, 64
> +        vsetivli      zero, 8, e8, mf2, ta, ma

Does MF2 actually improve perfs over M1 here?

> +        vlse64.v      v16, (a1), a2
> +        vlse64.v      v8, (a0), a2
> +        vsetvli       zero, t0, e8, m4, ta, ma
> +        vaaddu.vv     v16, v16, v8
> +        vsetivli      zero, 8, e8, mf2, ta, ma
> +        vsse64.v      v16, (a0), a2
> +
> +        ret
> +endfunc


-- 
レミ・デニ-クールモン
http://www.remlab.net/