Re: [FFmpeg-devel] [PATCH] aarch64/h26x: optimize sao_band_filter

["Martin Storsjö" <martin@martin.st>]

On Tue, 15 Apr 2025, Zhao Zhili wrote:

> From: Zhao Zhili <zhilizhao@tencent.com>
>
> int8_t[] is enough for offset_table of 8 bit streams.
>
> On rpi5:
>                             Before               After
> hevc_sao_band_8_8_c:          252.3 ( 1.00x)     252.3 ( 1.00x)
> hevc_sao_band_8_8_neon:        95.8 ( 2.63x)      61.0 ( 4.14x)
> hevc_sao_band_16_8_c:         875.2 ( 1.00x)     864.9 ( 1.00x)
> hevc_sao_band_16_8_neon:      317.5 ( 2.76x)     150.0 ( 5.76x)
> hevc_sao_band_32_8_c:        3853.5 ( 1.00x)    3871.6 ( 1.00x)
> hevc_sao_band_32_8_neon:     1222.3 ( 3.15x)     550.6 ( 7.03x)
> hevc_sao_band_48_8_c:        8203.6 ( 1.00x)    8182.6 ( 1.00x)
> hevc_sao_band_48_8_neon:     2685.7 ( 3.05x)    1185.8 ( 6.90x)
> hevc_sao_band_64_8_c:       14023.0 ( 1.00x)   14038.9 ( 1.00x)
> hevc_sao_band_64_8_neon:     4783.2 ( 2.93x)    2078.4 ( 6.75x)
> ---
> libavcodec/aarch64/h26x/dsp.h             |  4 +
> libavcodec/aarch64/h26x/sao_neon.S        | 93 ++++++++++++++---------
> libavcodec/aarch64/hevcdsp_init_aarch64.c |  4 +-
> libavcodec/aarch64/vvc/dsp_init.c         |  5 +-
> 4 files changed, 65 insertions(+), 41 deletions(-)
>
> diff --git a/libavcodec/aarch64/h26x/dsp.h b/libavcodec/aarch64/h26x/dsp.h
> index 0fefb4d70f..6ea6a8d36a 100644
> --- a/libavcodec/aarch64/h26x/dsp.h
> +++ b/libavcodec/aarch64/h26x/dsp.h
> @@ -28,6 +28,10 @@ void ff_h26x_sao_band_filter_8x8_8_neon(uint8_t *_dst, const uint8_t *_src,
>                                         ptrdiff_t stride_dst, ptrdiff_t stride_src,
>                                         const int16_t *sao_offset_val, int sao_left_class,
>                                         int width, int height);
> +void ff_h26x_sao_band_filter_16x16_8_neon(uint8_t *_dst, const uint8_t *_src,
> +                                        ptrdiff_t stride_dst, ptrdiff_t stride_src,
> +                                        const int16_t *sao_offset_val, int sao_left_class,
> +                                        int width, int height);
> void ff_hevc_sao_edge_filter_16x16_8_neon(uint8_t *dst, const uint8_t *src, ptrdiff_t stride_dst,
>                                           const int16_t *sao_offset_val, int eo, int width, int height);
> void ff_hevc_sao_edge_filter_8x8_8_neon(uint8_t *dst, const uint8_t *src, ptrdiff_t stride_dst,
> diff --git a/libavcodec/aarch64/h26x/sao_neon.S b/libavcodec/aarch64/h26x/sao_neon.S
> index c43820135e..60c026fe95 100644
> --- a/libavcodec/aarch64/h26x/sao_neon.S
> +++ b/libavcodec/aarch64/h26x/sao_neon.S
> @@ -35,48 +35,67 @@
> //                      int16_t *sao_offset_val, int sao_left_class,
> //                      int width, int height)
> function ff_h26x_sao_band_filter_8x8_8_neon, export=1
> -        stp             xzr, xzr, [sp, #-64]!
> +        stp             xzr, xzr, [sp, #-32]!
>         stp             xzr, xzr, [sp, #16]
> -        stp             xzr, xzr, [sp, #32]
> -        stp             xzr, xzr, [sp, #48]
>         mov             w8,  #4
> -0:      ldrsh           x9, [x4,  x8, lsl #1]      // sao_offset_val[k+1]
> -        subs            w8,  w8,  #1
> -        add             w10, w8,  w5               // k + sao_left_class
> +0:
> +        ldrsh           x9, [x4, x8, lsl #1]        // sao_offset_val[k+1]
> +        subs            w8, w8, #1
> +        add             w10, w8, w5                 // k + sao_left_class
>         and             w10, w10, #0x1F
> -        strh            w9, [sp, x10, lsl #1]
> +        strb            w9, [sp, x10]
>         bne             0b
> -        add             w6,  w6,  #7
> -        bic             w6,  w6,  #7
> -        ld1             {v16.16b-v19.16b}, [sp], #64
> -        sub             x2,  x2,  x6
> -        sub             x3,  x3,  x6
> -        movi            v20.8h,   #1
> -1:      mov             w8,  w6                    // beginning of line
> -2:      // Simple layout for accessing 16bit values
> -        // with 8bit LUT.
> -        //
> -        //   00  01  02  03  04  05  06  07
> -        // +----------------------------------->
> -        // |xDE#xAD|xCA#xFE|xBE#xEF|xFE#xED|....
> -        // +----------------------------------->
> -        //    i-0     i-1     i-2     i-3
> -        ld1             {v2.8b}, [x1], #8          // dst[x] = av_clip_pixel(src[x] + offset_table[src[x] >> shift]);
> -        subs            w8, w8,  #8
> -        uxtl            v0.8h,  v2.8b              // load src[x]
> -        ushr            v2.8h,  v0.8h, #3          // >> BIT_DEPTH - 3
> -        shl             v1.8h,  v2.8h, #1          // low (x2, accessing short)
> -        add             v3.8h,  v1.8h, v20.8h      // +1 access upper short
> -        sli             v1.8h,  v3.8h, #8          // shift insert index to upper byte
> -        tbx             v2.16b, {v16.16b-v19.16b}, v1.16b // table
> -        add             v1.8h,  v0.8h, v2.8h       // src[x] + table
> -        sqxtun          v4.8b,  v1.8h              // clip + narrow
> -        st1             {v4.8b}, [x0], #8          // store
> -        // done 8 pixels
> +        ldp             q16, q17, [sp], #32
> +1:
> +        ld1             {v2.8b}, [x1], x3
> +        subs            w7, w7, #1
> +        uxtl            v0.8h, v2.8b
> +        ushr            v3.8b, v2.8b, #3          // >> BIT_DEPTH - 3

Nitpick: The comment on this line seems to be misaligned with the other 
comments below - please check.

> +        tbx             v3.8b, {v16.16b-v17.16b}, v3.8b

Is there any specific reason for preferring tbx over tbl here? (I know the 
existing code used tbx.) Without having studied cycle tables, I would 
expect tbl to maybe be slightly simpler, but perhaps there's no difference 
(or tbx is faster)?


Other than these comments, this patch looks good to me, thanks - feel free 
to push.

// Martin

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