From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org [79.124.17.100]) by master.gitmailbox.com (Postfix) with ESMTP id E9C5842181 for ; Thu, 28 Apr 2022 19:51:06 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id E446968B321; Thu, 28 Apr 2022 22:51:02 +0300 (EEST) Received: from mail8.parnet.fi (mail8.parnet.fi [77.234.108.134]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 3322D68B369 for ; Thu, 28 Apr 2022 22:50:56 +0300 (EEST) Received: from mail9.parnet.fi (mail9.parnet.fi [77.234.108.21]) by mail8.parnet.fi with ESMTP id 23SJoskH007787-23SJoskI007787 for ; Thu, 28 Apr 2022 22:50:54 +0300 Received: from foo.martin.st (host-97-187.parnet.fi [77.234.97.187]) by mail9.parnet.fi (Postfix) with ESMTPS id AE473A142C for ; Thu, 28 Apr 2022 22:50:54 +0300 (EEST) Date: Thu, 28 Apr 2022 22:50:53 +0300 (EEST) From: =?ISO-8859-15?Q?Martin_Storsj=F6?= To: FFmpeg development discussions and patches In-Reply-To: <20220428134211.4786-3-jdek@itanimul.li> Message-ID: <5625a69f-a280-df32-7e1d-304511bd055@martin.st> References: <20220428134211.4786-1-jdek@itanimul.li> <20220428134211.4786-3-jdek@itanimul.li> MIME-Version: 1.0 X-FE-Policy-ID: 3:14:2:SYSTEM Subject: Re: [FFmpeg-devel] [PATCH 3/3] lavc/aarch64: add hevc sao edge 8x8 X-BeenThere: ffmpeg-devel@ffmpeg.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: FFmpeg development discussions and patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: FFmpeg development discussions and patches Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: On Thu, 28 Apr 2022, J. Dekker wrote: > bench on AWS Graviton: > > hevc_sao_edge_8x8_8_c: 516.0 > hevc_sao_edge_8x8_8_neon: 81.0 > > Signed-off-by: J. Dekker > --- > libavcodec/aarch64/hevcdsp_init_aarch64.c | 3 ++ > libavcodec/aarch64/hevcdsp_sao_neon.S | 51 +++++++++++++++++++++++ > 2 files changed, 54 insertions(+) > > diff --git a/libavcodec/aarch64/hevcdsp_init_aarch64.c b/libavcodec/aarch64/hevcdsp_init_aarch64.c > index df521bb083..2002530266 100644 > --- a/libavcodec/aarch64/hevcdsp_init_aarch64.c > +++ b/libavcodec/aarch64/hevcdsp_init_aarch64.c > @@ -59,6 +59,8 @@ void ff_hevc_sao_band_filter_8x8_8_neon(uint8_t *_dst, uint8_t *_src, > int width, int height); > void ff_hevc_sao_edge_filter_16x16_8_neon(uint8_t *dst, uint8_t *src, ptrdiff_t stride_dst, > int16_t *sao_offset_val, int eo, int width, int height); > +void ff_hevc_sao_edge_filter_8x8_8_neon(uint8_t *dst, uint8_t *src, ptrdiff_t stride_dst, > + int16_t *sao_offset_val, int eo, int width, int height); > > av_cold void ff_hevc_dsp_init_aarch64(HEVCDSPContext *c, const int bit_depth) > { > @@ -80,6 +82,7 @@ av_cold void ff_hevc_dsp_init_aarch64(HEVCDSPContext *c, const int bit_depth) > c->sao_band_filter[2] = > c->sao_band_filter[3] = > c->sao_band_filter[4] = ff_hevc_sao_band_filter_8x8_8_neon; > + c->sao_edge_filter[0] = ff_hevc_sao_edge_filter_8x8_8_neon; > c->sao_edge_filter[1] = > c->sao_edge_filter[2] = > c->sao_edge_filter[3] = > diff --git a/libavcodec/aarch64/hevcdsp_sao_neon.S b/libavcodec/aarch64/hevcdsp_sao_neon.S > index 0315c479df..efd8112af4 100644 > --- a/libavcodec/aarch64/hevcdsp_sao_neon.S > +++ b/libavcodec/aarch64/hevcdsp_sao_neon.S > @@ -140,3 +140,54 @@ function ff_hevc_sao_edge_filter_16x16_8_neon, export=1 > // no lines to filter > ret > endfunc > + > +// ff_hevc_sao_edge_filter_8x8_8_neon(char *dst, char *src, ptrdiff stride_dst, > +// int16 *sao_offset_val, int eo, int width, int height) > +function ff_hevc_sao_edge_filter_8x8_8_neon, export=1 > + adr x7, .Lsao_edge_pos > + ldr w4, [x7, w4, uxtw #2] > + ld1 {v3.8h}, [x3] > + mov v3.h[7], v3.h[0] > + mov v3.h[0], v3.h[1] > + mov v3.h[1], v3.h[2] > + mov v3.h[2], v3.h[7] > + uzp2 v1.16b, v3.16b, v3.16b > + uzp1 v0.16b, v3.16b, v3.16b > + movi v2.16b, #2 > + add x16, x0, x2 > + lsl x2, x2, #1 > + mov x15, #192 > + mov x8, x1 > + sub x9, x1, x4 > + add x10, x1, x4 > + lsr w17, w6, #1 Compared with the previously applied (and reverted) patch, here, you previously had "mov x17, #4". I guess that'd mean the function only ever produced 8 output rows, while it now uses the real height parameter? Was this change a no-op (height is always 8?) or was this another hidden bug in the previous implementation? > +1: ld1 {v3.d}[0], [ x8], x15 > + ld1 {v4.d}[0], [ x9], x15 > + ld1 {v5.d}[0], [x10], x15 > + ld1 {v3.d}[1], [ x8], x15 > + ld1 {v4.d}[1], [ x9], x15 > + ld1 {v5.d}[1], [x10], x15 > + cmhi v16.16b, v4.16b, v3.16b > + cmhi v17.16b, v3.16b, v4.16b > + cmhi v18.16b, v5.16b, v3.16b > + cmhi v19.16b, v3.16b, v5.16b > + sub v20.16b, v16.16b, v17.16b > + sub v21.16b, v18.16b, v19.16b > + add v20.16b, v20.16b, v21.16b > + add v20.16b, v20.16b, v2.16b > + tbl v16.16b, {v0.16b}, v20.16b > + tbl v17.16b, {v1.16b}, v20.16b > + uxtl v20.8h, v3.8b > + uxtl2 v21.8h, v3.16b > + zip1 v18.16b, v16.16b, v17.16b > + zip2 v19.16b, v16.16b, v17.16b > + sqadd v20.8h, v18.8h, v20.8h > + sqadd v21.8h, v19.8h, v21.8h > + sqxtun v6.8b, v20.8h > + sqxtun v7.8b, v21.8h > + st1 {v6.8b}, [ x0], x2 > + st1 {v7.8b}, [x16], x2 > + subs x17, x17, #1 This could be "subs w6, w6, #2" and you wouldn't need the lsr instruction at all. And you could place the subs before the two st1 instructions to reduce latency between them a little. (The same thing goes for moving subs further away from the branch that uses its outcome in the previous patch too.) But as this is just a reapply of a previously committed and reverted patch, I guess it's fine this way too... The patchset otherwise looks good to me, modulo the question about the difference to the previous patchset above. // 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".