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 60F644351C for ; Sat, 16 Jul 2022 13:20:19 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 7D07968B8A0; Sat, 16 Jul 2022 16:20:17 +0300 (EEST) Received: from relay8-d.mail.gandi.net (relay8-d.mail.gandi.net [217.70.183.201]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 6656868B85B for ; Sat, 16 Jul 2022 16:20:11 +0300 (EEST) Received: (Authenticated sender: michael@niedermayer.cc) by mail.gandi.net (Postfix) with ESMTPSA id C03A81BF208 for ; Sat, 16 Jul 2022 13:20:10 +0000 (UTC) Date: Sat, 16 Jul 2022 15:20:10 +0200 From: Michael Niedermayer To: FFmpeg development discussions and patches Message-ID: <20220716132010.GJ2088045@pb2> References: <20220713204854.3114817-1-martin@martin.st> <20220713204854.3114817-5-martin@martin.st> <8E07A574-9F34-48B1-98BC-95A5B676A458@amazon.com> <3a7cff5-7691-e8cd-55c6-28f7f63cda27@martin.st> <20220715211948.GF2088045@pb2> <37f78b5-e37b-b71d-f8b6-236e47b3b9c@martin.st> <20220716112336.GH2088045@pb2> MIME-Version: 1.0 In-Reply-To: Subject: Re: [FFmpeg-devel] [PATCH 5/5] aarch64: me_cmp: Don't do uaddlv once per iteration 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: multipart/mixed; boundary="===============0993444463336297328==" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: --===============0993444463336297328== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="sT9gWZPUZYhvPS56" Content-Disposition: inline --sT9gWZPUZYhvPS56 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jul 16, 2022 at 03:30:23PM +0300, Martin Storsj=F6 wrote: > On Sat, 16 Jul 2022, Michael Niedermayer wrote: >=20 > > On Sat, Jul 16, 2022 at 12:25:37AM +0300, Martin Storsj=F6 wrote: > > > On Fri, 15 Jul 2022, Michael Niedermayer wrote: > > >=20 > > > > On Fri, Jul 15, 2022 at 10:56:03PM +0300, Martin Storsj=F6 wrote: > > > > > On Fri, 15 Jul 2022, Swinney, Jonathan wrote: > > > > >=20 > > > > > > If the max height is just 16, then this should be fine. I assum= ed that h > > > > > > could have a much higher value (>1024), but if that is not the = case, > > > > > > then this is a useful optimization. > > > > >=20 > > > > > At least according to the me_cmp.h header, which says: > > > > >=20 > > > > > /* Motion estimation: > > > > > * h is limited to { width / 2, width, 2 * width }, > > > > > * but never larger than 16 and never smaller than 2. > > > > > * Although currently h < 4 is not used as functions with > > > > > * width < 8 are neither used nor implemented. */ > > > >=20 > > > > These rules where written with support for encoding of all > > > > standard formats in mind at the time that was written. > > > > today it may make sense to extend these rules to cover the > > > > things which where created since then > > >=20 > > > Right, but if that suddenly changes, such a change also must expect t= hat it > > > might need updates to all assembly implementations that implement that > > > interface currently. Right now, both the defacto case (any callers in= the > > > codebase) and the explicit documentation says that it can't be called= with > > > parameters outside of that range. > >=20 > > What i meant was that newly added functions should be more flexible than > > these old rules. That is 2 sets of rules > > 1. What a caller ATM can do and expect to work (thats whats written the= re) > > 2. What an implementor of new functions should make sure is supported >=20 > With 2., do you mean if adding a new function into the same struct, or if > implementing the existing pix_abs[0][..] functions? i would say both >=20 > If you mean new implementations of the existing function interface, you s= ay > they "should be more flexible". How flexible must they be? Is it ok to > assume h<=3D256 for the w=3D16 functions? i think thats fine >=20 > Gradually increasing the requirements for existing function interfaces li= ke > you suggest is really problematic. why ? iam really just saying "when you add new code, dont base it on old limitations" And i suggest this because its much easier to do when a function is added t= han when later one wants to use it=20 When i originally wrote this list of restrictions it didnt list what our code actually used but tried to look ahead to what we would need when we write encoders for all standard formats at that time. We never wrote a h264 encoder but this API was designed to support it. >=20 > If we want to require more of the functions, we should document it, and > extend the checkasm test to test that new requirement - which also extends > the requirement to the existing functions. If we don't have a checkasm te= st > for the required behaviour, we can pretty much assume it's broken, even in > new implementations. yes [...] --=20 Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No snowflake in an avalanche ever feels responsible. -- Voltaire --sT9gWZPUZYhvPS56 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EABEIAB0WIQSf8hKLFH72cwut8TNhHseHBAsPqwUCYtK7BgAKCRBhHseHBAsP q5KkAJ4ufSh5KSsZjf4coH0zRQD87m9aJgCeNqb7Dt/NJzzEoWdj1RT3ESvSG/E= =Ah9O -----END PGP SIGNATURE----- --sT9gWZPUZYhvPS56-- --===============0993444463336297328== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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". --===============0993444463336297328==--