Re: [FFmpeg-devel] [PATCH v4] avcodec/aarch64/hevc: add luma deblock NEON

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

On Tue, 27 Feb 2024, J. Dekker wrote:

> Benched using single-threaded full decode on an Ampere Altra.
>
> Bpp Before  After  Speedup
> 8   73,3s   65,2s  1.124x
> 10  114,2s  104,0s 1.098x
> 12  125,8s  115,7s 1.087x
>
> Signed-off-by: J. Dekker <jdek@itanimul.li>
> ---
>
> Slightly improved 12bit version.
>
> libavcodec/aarch64/hevcdsp_deblock_neon.S | 417 ++++++++++++++++++++++
> libavcodec/aarch64/hevcdsp_init_aarch64.c |  18 +
> 2 files changed, 435 insertions(+)
>
> diff --git a/libavcodec/aarch64/hevcdsp_deblock_neon.S b/libavcodec/aarch64/hevcdsp_deblock_neon.S
> index 8227f65649..581056a91e 100644
> --- a/libavcodec/aarch64/hevcdsp_deblock_neon.S
> +++ b/libavcodec/aarch64/hevcdsp_deblock_neon.S
> @@ -181,3 +181,420 @@ hevc_h_loop_filter_chroma 12
> hevc_v_loop_filter_chroma 8
> hevc_v_loop_filter_chroma 10
> hevc_v_loop_filter_chroma 12
> +
> +.macro hevc_loop_filter_luma_body bitdepth
> +function hevc_loop_filter_luma_body_\bitdepth\()_neon, export=0
> +.if \bitdepth > 8
> +        lsl             w2, w2, #(\bitdepth - 8) // beta <<= BIT_DEPTH - 8
> +.else
> +        uxtl            v0.8h, v0.8b
> +        uxtl            v1.8h, v1.8b
> +        uxtl            v2.8h, v2.8b
> +        uxtl            v3.8h, v3.8b
> +        uxtl            v4.8h, v4.8b
> +        uxtl            v5.8h, v5.8b
> +        uxtl            v6.8h, v6.8b
> +        uxtl            v7.8h, v7.8b
> +.endif
> +        ldr             w7, [x3] // tc[0]
> +        ldr             w8, [x3, #4] // tc[1]
> +        dup             v18.4h, w7
> +        dup             v19.4h, w8
> +        trn1            v18.2d, v18.2d, v19.2d
> +.if \bitdepth > 8
> +        shl             v18.8h, v18.8h, #(\bitdepth - 8)
> +.endif
> +        dup             v27.8h, w2 // beta
> +        // tc25
> +        shl             v19.8h, v18.8h, #2 // * 4
> +        add             v19.8h, v19.8h, v18.8h // (tc * 5)
> +        srshr           v19.8h, v19.8h, #1 // (tc * 5 + 1) >> 1
> +        sshr            v17.8h, v27.8h, #2 // beta2
> +
> +        ////// beta_2 check
> +        // dp0  = abs(P2  - 2 * P1  + P0)
> +        add             v22.8h, v3.8h, v1.8h
> +        shl             v23.8h, v2.8h, #1
> +        sabd            v30.8h, v22.8h, v23.8h
> +        // dq0  = abs(Q2  - 2 * Q1  + Q0)
> +        add             v21.8h, v6.8h, v4.8h
> +        shl             v26.8h, v5.8h, #1
> +        sabd            v31.8h, v21.8h, v26.8h
> +        // d0   = dp0 + dq0
> +        add             v20.8h, v30.8h, v31.8h
> +        shl             v25.8h, v20.8h, #1
> +        // (d0 << 1) < beta_2
> +        cmgt            v23.8h, v17.8h, v25.8h
> +
> +        ////// beta check
> +        // d0 + d3 < beta
> +        mov             x9, #0xFFFF00000000FFFF
> +        dup             v24.2d, x9
> +        and             v25.16b, v24.16b, v20.16b
> +        addp            v25.8h, v25.8h, v25.8h // 1+0 0+1 1+0 0+1
> +        addp            v25.4h, v25.4h, v25.4h // 1+0+0+1 1+0+0+1
> +        cmgt            v25.4h, v27.4h, v25.4h // lower/upper mask in h[0/1]
> +        mov             w9, v25.s[0]

I don't quite understand what this sequence does and/or how our data is 
laid out in our registers - we have d0 on input in v20, where's d3? An 
doesn't the "and" throw away half of the input elements here?

I see some similar patterns with the masking and handling below as well - 
I get a feeling that I don't quite understand the algorithm here, and/or 
the data layout.

> +.if \bitdepth > 8
> +        ld1             {v0.8h}, [x0], x1
> +        ld1             {v1.8h}, [x0], x1
> +        ld1             {v2.8h}, [x0], x1
> +        ld1             {v3.8h}, [x0], x1
> +        ld1             {v4.8h}, [x0], x1
> +        ld1             {v5.8h}, [x0], x1
> +        ld1             {v6.8h}, [x0], x1
> +        ld1             {v7.8h}, [x0]
> +        mov             w14, #((1 << \bitdepth) - 1)

For loads like these, we can generally save a bit by using two alternating 
registers for loading, with a double stride - see e.g. the vp9 loop 
filter implementations. But that's a micro optimization.

Other than that, this mostly looks reasaonble.

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