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 1D68D41254 for ; Sun, 25 Sep 2022 20:45:22 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 4885068B900; Sun, 25 Sep 2022 23:45:20 +0300 (EEST) Received: from w4.tutanota.de (w4.tutanota.de [81.3.6.165]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 6FD2C68B1E1 for ; Sun, 25 Sep 2022 23:45:13 +0300 (EEST) Received: from w3.tutanota.de (unknown [192.168.1.164]) by w4.tutanota.de (Postfix) with ESMTP id 1B92D1060154 for ; Sun, 25 Sep 2022 20:45:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1664138712; s=s1; d=lynne.ee; h=From:From:To:To:Subject:Subject:Content-Description:Content-ID:Content-Type:Content-Type:Content-Transfer-Encoding:Content-Transfer-Encoding:Cc:Date:Date:In-Reply-To:In-Reply-To:MIME-Version:MIME-Version:Message-ID:Message-ID:Reply-To:References:References:Sender; bh=rpZM1xqsbmMWuGlsxmgONLO8ckHotiRx/HLTH4nyaYQ=; b=ov95JKB6Snh4IHx3mAn5JukXGsMUbjh1hNsL0fygd47n9VEWxZqACW5fwQgpd5J1 7hAepl/OpQBMmg5ZUrj2nxyvx8qe4ZPZ1a/i4xohvYZsr7icW/0sYh85QQhk14bQy0p dCz5p4WjtrC2WtfJY+uPYElm5miMzQSR+Y7cDiNd9QUbju/ClfibqO2pkH0YZenflA6 jVTMpA9OCxcb5IsVjpEBl6NXqmk/ybKYivSQ9got4UtKmKG4sKPdiicbxKdZbw3/pT/ r87N6A/BOHJhtaXU9PSJi8MhW7xychEL3x3csPEjYmxwQ+xxU4d7HX45zO64d9eoBAl aUU7Nom9YA== Date: Sun, 25 Sep 2022 22:45:12 +0200 (CEST) From: Lynne To: FFmpeg development discussions and patches Message-ID: In-Reply-To: References: <37cff64-511b-518d-769-f02c1fc7e49f@martin.st> <38345618-1535-1c53-6c28-52d0796e217@martin.st> MIME-Version: 1.0 Subject: Re: [FFmpeg-devel] [PATCH 1/6] opus: convert encoder and decoder to lavu/tx 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-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: Sep 25, 2022, 21:55 by martin@martin.st: > On Sat, 24 Sep 2022, Lynne wrote: > >>> What about ac3dsp then - that one seems like it's fairly optimized for arm? >>> >> >> Haven't touched them, they're still being used. Unfortunately, for AC3, >> the full MDCT optimizations in lavc do make a difference and the overall >> decoder becomes 15% slower with this patch on for aarch64 with lavu/tx's >> asm disabled and 7% slower with lavu/tx's asm enabled. >> > > Hmm, that's a shame... > >> I do plan to write an aarch64 MDCT NEON SIMD code in a month or so, unless someone is faster, which should make the decoder at least 10% faster with lavu/tx. >> > > Would you consider holding off of converting the ac3 decoder until this point, to avoid unnecessary temporary performance regressions at least for the architectures that are covered by the new lavu/tx framework? > >> If you'd like to help out, I've documented the C factorizations used in >> docs/transforms.md. >> > > Sorry, I don't think I have time at the moment to take on writing new code from scratch for this... > > I could maybe consider porting the aarch64 assembly to arm32; if it's not register starved, it's usually quite straightforward to do such rewrites (there's either half the number of SIMD registers compared to aarch64, or the same number but half the length) > For the basis transforms (double 4, double 8 and 8, single 16), there's no starvation. For the 32pt transform, it's a bit starved, but nothing you couldn't work out. For the 64pt and up, absolutely all registers are used to the point of needing to stash vector regs across gprs. If all registers are written back to memory (no register sharing between transform sizes), it becomes as starved as the 32pt. It's obvious to see where the starvation happens (only 32pt -> 64pt) and how to fix it, but it's still work to convert code. Take a look at it and see if you can spot something that would make it difficult? > The reason why I'm asking about arm32, is because ffmpeg has got a bunch of users who have spent a fair amount of effort on reaching specific performance levels for some codecs, both for raspberry pi 1 (which doesn't have neon but only vfp) and for the newer ones with neon. I don't remember exactly which codecs are relevant for these users - I doubt opus is, but ac3 and dca are, iirc. > We do maintain old versions for years after a release. And we recently-ish had a major bump, and very recently 5.1. I think there's enough time to bring them back up and make them faster still before stuck users become quite outdated, what about you? Maybe someone who's interested could notice and help out? > I'm CCing Ben Avison who has contributed a lot of optimizations in this area. > Thanks. _______________________________________________ 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".