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 00AD543981 for ; Thu, 4 Aug 2022 08:00:38 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 1912F68B8C9; Thu, 4 Aug 2022 11:00:36 +0300 (EEST) Received: from mail8.parnet.fi (mail8.parnet.fi [77.234.108.134]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id BF0BE68B741 for ; Thu, 4 Aug 2022 11:00:29 +0300 (EEST) Received: from mail9.parnet.fi (mail9.parnet.fi [77.234.108.21]) by mail8.parnet.fi with ESMTP id 27480MqM018136-27480MqN018136; Thu, 4 Aug 2022 11:00:22 +0300 Received: from foo.martin.st (host-97-187.parnet.fi [77.234.97.187]) by mail9.parnet.fi (Postfix) with ESMTPS id 28FEBA1468; Thu, 4 Aug 2022 11:00:22 +0300 (EEST) Date: Thu, 4 Aug 2022 11:00:22 +0300 (EEST) From: =?ISO-8859-15?Q?Martin_Storsj=F6?= To: Hubert Mazur In-Reply-To: <20220725111541.44618-1-hum@semihalf.com> Message-ID: References: <20220715080228.686736-3-hum@semihalf.com> <20220725111541.44618-1-hum@semihalf.com> MIME-Version: 1.0 X-FE-Policy-ID: 3:14:2:SYSTEM Subject: Re: [FFmpeg-devel] [PATCH] lavc/aarch64: Add neon implementation for sse4 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 Cc: gjb@semihalf.com, upstream@semihalf.com, jswinney@amazon.com, ffmpeg-devel@ffmpeg.org, mw@semihalf.com, spop@amazon.com 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 Mon, 25 Jul 2022, Hubert Mazur wrote: > Provide neon implementation for sse4 function. > > Performance comparison tests are shown below. > - sse_2_c: 74.0 > - sse_2_neon: 24.0 > > Benchmarks and tests are run with checkasm tool on AWS Graviton 3. > > Signed-off-by: Hubert Mazur > --- > libavcodec/aarch64/me_cmp_init_aarch64.c | 3 ++ > libavcodec/aarch64/me_cmp_neon.S | 65 ++++++++++++++++++++++++ > 2 files changed, 68 insertions(+) > > diff --git a/libavcodec/aarch64/me_cmp_init_aarch64.c b/libavcodec/aarch64/me_cmp_init_aarch64.c > index 3ff5767bd0..72a2062e7e 100644 > --- a/libavcodec/aarch64/me_cmp_init_aarch64.c > +++ b/libavcodec/aarch64/me_cmp_init_aarch64.c > @@ -32,6 +32,8 @@ int ff_pix_abs16_x2_neon(MpegEncContext *v, uint8_t *pix1, uint8_t *pix2, > > int sse16_neon(MpegEncContext *v, uint8_t *pix1, uint8_t *pix2, > ptrdiff_t stride, int h); > +int sse4_neon(MpegEncContext *v, uint8_t *pix1, uint8_t *pix2, > + ptrdiff_t stride, int h); > > av_cold void ff_me_cmp_init_aarch64(MECmpContext *c, AVCodecContext *avctx) > { > @@ -44,5 +46,6 @@ av_cold void ff_me_cmp_init_aarch64(MECmpContext *c, AVCodecContext *avctx) > > c->sad[0] = ff_pix_abs16_neon; > c->sse[0] = sse16_neon; > + c->sse[2] = sse4_neon; > } > } > diff --git a/libavcodec/aarch64/me_cmp_neon.S b/libavcodec/aarch64/me_cmp_neon.S > index 98c912b608..3336d88848 100644 > --- a/libavcodec/aarch64/me_cmp_neon.S > +++ b/libavcodec/aarch64/me_cmp_neon.S > @@ -352,3 +352,68 @@ function sse16_neon, export=1 > ret > > endfunc > + > +function sse4_neon, export=1 > + // x0 - unused > + // x1 - pix1 > + // x2 - pix2 > + // x3 - stride > + // w4 - h > + > + movi d18, #0 > + movi d17, #0 In the current implementation, it doesn't seem like d17 needs to be initialized here > + cmp w4, #4 > + b.le 2f > + > +// make 4 iterations at once > +1: > + > + // res = abs(pix1[0] - pix2[0]) > + // res * res > + > + ld1 {v0.s}[0], [x1], x3 // Load pix1, first iteration > + ld1 {v1.s}[0], [x2], x3 // Load pix2, first iteration > + uabdl v30.8h, v0.8b, v1.8b // Absolute difference, first iteration Right now, half of the values calculated by uabdl are unused; you could try loading two iterations into v0.s[0] and v0.s[1] so that the full .8b register gets used. Doing that would reduce the number of uabdl instructions from 4 to 2 - but it might make it harder to interleave instructions efficiently. So after all, maybe it's not worth if, it we can make the loads more efficiently interleaved this way? Again, also here, it'd be good to interleave things more efficiently, e.g. like this: ld1 first ld1 first ld1 second ld1 second uabdl first ld1 third ld1 third uabdl second umull first ld1 fourth ld1 fourth uabdl third umlal second uabdl fourth umlal third umlal fourth > + ld1 {v2.s}[0], [x1], x3 // Load pix1, second iteration > + ld1 {v3.s}[0], [x2], x3 // Load pix2, second iteration > + umull v16.4s, v30.4h, v30.4h // Multiply vectors, first iteration > + uabdl v29.8h, v2.8b, v3.8b // Absolute difference, second iteration > + ld1 {v4.s}[0], [x1], x3 // Load pix1, third iteration > + ld1 {v5.s}[0], [x2], x3 // Load pix2, third iteration > + umlal v16.4s, v29.4h, v29.4h // Multiply and accumulate, second iteration > + uabdl v28.8h, v4.8b, v5.8b // Absolute difference, third iteration > + ld1 {v6.s}[0], [x1], x3 // Load pix1, fourth iteration > + ld1 {v7.s}[0], [x2], x3 // Load pix2, fourth iteration > + umlal v16.4s, v28.4h, v28.4h // Multiply and accumulate, third iteration > + uabdl v27.8h, v6.8b, v7.8b // Absolue difference, fourth iteration > + umlal v16.4s, v27.4h, v27.4h // Multiply and accumulate, fourth iteration > + > + uaddlv d17, v16.4s // Add vector > + add d18, d18, d17 As usual, don't do any *add*v within the loop, defer it as far as possible. Here you're accumulating in 32 bit elements, so it will surely fit the results from the whole algorithm. Also, if you get rid of the uaddlv here, you can also accumulate into two separate .4s registers that you only add at the end; that allows two umlal instructions to possibly execute in parallel without waiting for each other (provided that the cpu has enough execution units for that). // 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".