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 30A5542797 for ; Wed, 30 Mar 2022 13:04:07 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 4A12E68B20A; Wed, 30 Mar 2022 16:04:05 +0300 (EEST) Received: from mail8.parnet.fi (mail8.parnet.fi [77.234.108.134]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 1C30368AEFE for ; Wed, 30 Mar 2022 16:03:58 +0300 (EEST) Received: from mail9.parnet.fi (mail9.parnet.fi [77.234.108.21]) by mail8.parnet.fi with ESMTP id 22UD3vfC027810-22UD3vfD027810; Wed, 30 Mar 2022 16:03:57 +0300 Received: from foo.martin.st (host-97-187.parnet.fi [77.234.97.187]) by mail9.parnet.fi (Postfix) with ESMTPS id D21F6A1430; Wed, 30 Mar 2022 16:03:57 +0300 (EEST) Date: Wed, 30 Mar 2022 16:03:57 +0300 (EEST) From: =?ISO-8859-15?Q?Martin_Storsj=F6?= To: FFmpeg development discussions and patches In-Reply-To: <20220325185257.513933-7-bavison@riscosopen.org> Message-ID: <1386c64e-486f-9ff5-7e4e-cb95b57a86e6@martin.st> References: <20220317185819.466470-1-bavison@riscosopen.org> <20220325185257.513933-1-bavison@riscosopen.org> <20220325185257.513933-7-bavison@riscosopen.org> MIME-Version: 1.0 X-FE-Policy-ID: 3:14:2:SYSTEM Subject: Re: [FFmpeg-devel] [PATCH 06/10] avcodec/vc1: Arm 32-bit NEON deblocking filter fast paths 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: Ben Avison 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 Fri, 25 Mar 2022, Ben Avison wrote: > checkasm benchmarks on 1.5 GHz Cortex-A72 are as follows. Note that the C > version can still outperform the NEON version in specific cases. The balance > between different code paths is stream-dependent, but in practice the best > case happens about 5% of the time, the worst case happens about 40% of the > time, and the complexity of the remaining cases fall somewhere in between. > Therefore, taking the average of the best and worst case timings is > probably a conservative estimate of the degree by which the NEON code > improves performance. > > vc1dsp.vc1_h_loop_filter4_bestcase_c: 19.0 > vc1dsp.vc1_h_loop_filter4_bestcase_neon: 48.5 > vc1dsp.vc1_h_loop_filter4_worstcase_c: 144.7 > vc1dsp.vc1_h_loop_filter4_worstcase_neon: 76.2 > vc1dsp.vc1_h_loop_filter8_bestcase_c: 41.0 > vc1dsp.vc1_h_loop_filter8_bestcase_neon: 75.0 > vc1dsp.vc1_h_loop_filter8_worstcase_c: 294.0 > vc1dsp.vc1_h_loop_filter8_worstcase_neon: 102.7 > vc1dsp.vc1_h_loop_filter16_bestcase_c: 54.7 > vc1dsp.vc1_h_loop_filter16_bestcase_neon: 130.0 > vc1dsp.vc1_h_loop_filter16_worstcase_c: 569.7 > vc1dsp.vc1_h_loop_filter16_worstcase_neon: 186.7 > vc1dsp.vc1_v_loop_filter4_bestcase_c: 20.2 > vc1dsp.vc1_v_loop_filter4_bestcase_neon: 47.2 > vc1dsp.vc1_v_loop_filter4_worstcase_c: 164.2 > vc1dsp.vc1_v_loop_filter4_worstcase_neon: 68.5 > vc1dsp.vc1_v_loop_filter8_bestcase_c: 43.5 > vc1dsp.vc1_v_loop_filter8_bestcase_neon: 55.2 > vc1dsp.vc1_v_loop_filter8_worstcase_c: 316.2 > vc1dsp.vc1_v_loop_filter8_worstcase_neon: 72.7 > vc1dsp.vc1_v_loop_filter16_bestcase_c: 62.2 > vc1dsp.vc1_v_loop_filter16_bestcase_neon: 103.7 > vc1dsp.vc1_v_loop_filter16_worstcase_c: 646.5 > vc1dsp.vc1_v_loop_filter16_worstcase_neon: 110.7 > > Signed-off-by: Ben Avison > --- > libavcodec/arm/vc1dsp_init_neon.c | 14 + > libavcodec/arm/vc1dsp_neon.S | 643 ++++++++++++++++++++++++++++++ > 2 files changed, 657 insertions(+) > +@ VC-1 in-loop deblocking filter for 8 pixel pairs at boundary of vertically-neighbouring blocks > +@ On entry: > +@ r0 -> top-left pel of lower block > +@ r1 = row stride, bytes > +@ r2 = PQUANT bitstream parameter > +function ff_vc1_v_loop_filter8_neon, export=1 > + sub r3, r0, r1, lsl #2 > + vldr d0, .Lcoeffs > + vld1.32 {d1}, [r0], r1 @ P5 > + vld1.32 {d2}, [r3], r1 @ P1 > + vld1.32 {d3}, [r3], r1 @ P2 > + vld1.32 {d4}, [r0], r1 @ P6 > + vld1.32 {d5}, [r3], r1 @ P3 > + vld1.32 {d6}, [r0], r1 @ P7 Oh btw - I presume these loads can be done with alignment? And same for some of the stores too? At least for some older cores, the alignment specifier helps a lot - so for 32 bit assembly, I try to add as much alignment specifiers as possible. // 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".