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 209A140A6E for ; Mon, 27 Nov 2023 22:01:21 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 2326F68CF7E; Tue, 28 Nov 2023 00:01:19 +0200 (EET) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 1918368BB4C for ; Tue, 28 Nov 2023 00:01:12 +0200 (EET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=s31663417; t=1701122471; x=1701727271; i=eclipse7@gmx.net; bh=IWUZxVF7d3i+P9Adgb2agfFjUmQrdLVAy5uOxnYnDZs=; h=X-UI-Sender-Class:Date:From:To:Subject:References:In-Reply-To; b=s39uwpiLuRSOdKtEe42zXP071+rC1puBTw2Sr+/ZCXgBawHk0Gj7BkdJHTql1lWu LUYnEsbh9gdhZeBskEghcqOsM3QkzO9Lj8tHH/YftT6zIz7cwG/4KfoWclt7k8ClX sqy4GUoIOmdHlqXPoxCqG032Ng9M/QkC4Mq9mA6gR1+jtMwvofu7BB5NgsvAFlwuT 9+yXqXNhdxKxjOuFa8PLkQfNtpT0S4RCaAVXUvloR9iVeq+tiD5/PNVCF0WKmCPaR URjoU/YVOjrm8N8SM5TCUCVf+ua8Khmwm7+McER0oUWRSe3MXoTH1lppOkVqKTzAn bgHl8VoqVdDhAAjVKg== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from metallschleimette ([91.12.119.98]) by mail.gmx.net (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MAwXr-1r0u220jUn-00BNiM for ; Mon, 27 Nov 2023 23:01:11 +0100 Date: Mon, 27 Nov 2023 23:10:57 +0100 From: Alexander Strasser To: FFmpeg development discussions and patches Message-ID: References: <20231127123118.3622784-1-martin@martin.st> <12696030.Brfu6Qr6Id@basile.remlab.net> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <12696030.Brfu6Qr6Id@basile.remlab.net> X-Provags-ID: V03:K1:W2WNes7KKO5H4Y1NM6qMfSNtxsU6aZz/EcXjOcFUloYeNJLQ6Zn mGPim83598q91OCfkSxD4DJaumnIjMqqF0YmFiixEBLLA2Mu7OcTb/2xrDoJmT4P4Ic8izk gCLbqvS/KeOPtpqjidwinqkh6iyArpOXIG8V3OMzg/OhWLLGY+f82jMkVnYo8y0e+4mLh9I 2Ki8KBgm9Vx8tzb+m7LKg== X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:TxdErftQ2TM=;JyEjaZsPAV6naLERzeKvsiNxWAh x5uQyJfOhWmVzMejDOlJ7h4a4QUAnrZ3sjVuvKSZ8IHbyBwjQiVGAlEEjxfOXB3X0W8WRZnEd yFZ+qE+h8Snjp18AcwOIhYy5Ahq0HcuOIcL8GXBl3r5pB2hl8T9ev40+z1mRwoqnrExpUTVE6 XseII63fNpWAhkVOhfxxy+1bcklUbm4HljuH0ncuB0fRuhO+LMQojqEFKBCqsafZCOsZ0ysrg z/ndwj+dxi7cQD2gT7hT04a8oKavj616dg0tNjLJwbAeYmKUZ6JRzvdTUcZLamr88UbdEDZzG iEK1/scP4mRW3MZc+/40IjE+ftMCL+sxEqY/u1vnZfrUup0rBu0zoks3IIFV3JUGE649f/pZ3 0ronF4675YNrLejQW7wnpz12Ei0KvNSdrSRWz9BLSF/MZZCBBvZ3Plmn1PZPBeEe3JV3vLHCs LB8Qxw9Y0xJZpV3gv5YzdlVkKJJTtpSned0+VPjX+OwrLpZfjI9RoDcEYHFN3hJ2cE3v32cSq J4i8pGT4F/fkpTHwpecmHL7JLILDYZSh0RmE69DEDBfA6NCAzP1SJnWIesD3Ve3WhnliImP1m gP/Q81Qepz3jHIGCO/aW3WfciG/89c+9a06Fx0J1ufsmksn1JOAcriXuyOddxta629tQuvqNO 5XXNTBFFRBE5Gavh74h+CUEfDc825b2rin4dR9Dr6lLtbAQmQhYvJVzl/ABjnxaeS4sN+Rh0J eMzhDx2C52VMMJs6Ft5sqw3YwP+AOc9fUld8V8T8Ql83Y76o57aGUgJBDDNtUlHzs9FUd8m/a 7ICs7/S3j9lC7B/Avsk31WC5emL5J4omqIwK1i0GRMy6uFfpb5hH5c73GQsO7bO94nqGgNg6y N4jj4PXwfXWHwyZ7ZCqPKO3bqGU+TC7PbjtdsE0ECc7s1FGVlL8M9dqtT8juxN/8I5x4yyTjB Gh2TdA== Subject: Re: [FFmpeg-devel] [PATCH] fate.sh: Allow overriding what targets to make for running the tests 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: Hi Martin, patch looks technically good to me. On 2023-11-27 17:46 +0200, R=E9mi Denis-Courmont wrote: > Le maanantaina 27. marraskuuta 2023, 14.31.18 EET Martin Storsj=F6 a =E9c= rit : > > This can be useful if doing testing of uncommon CPU extensions by > > running tests with QEMU (by configuring with e.g. > > "target_exec=3Dqemu-aarch64"), by only running the checkasm tests, > > to get a reasonable test coverage without excessive test runtime. > > For the purpose of testing future or bleeding-edge CPU extensions on emul= ator, > you would normally want to be able to actually filter those in. That is m= ore of > a matter of patching checkasm than FATE. > > Considering the poor coverage of checkasm, I fear that this just gives the > wrong impression, not to say a false sense of security. It feels misleadi= ng to > encourage or support that paradigm into FATE, in light of that poor cover= age. > Afterall, if it's just about running checkasm, anybody can just run > `make tests/checkasm/checkasm && tests/checkasm/checkasm`. Agree, the practice should not be encouraged over cases where it is necessary to be practical, but having fate clients run the tests and submit the results seems still worthwhile to me. We shouldn't get a false sense of security and it can be a problem. Improving checkasm and qemu and maybe getting actual bleeding edge hardware into fate could help with that. Not saying it is easy or effortless... Still having tests run and some failures detected seems better than nothing to me. It would be only problematic if the false positives or negatives weigh out the cases where it is helpful. @Remi: Please take no offense. This does not look like a black and white issue to me , thus I wanted to voice what I thought when initially saw the patch and your response. Best regards, Alexander > Either way, this feels like a case of cart before horse. > > Also FWIW, RV broke due to misaligned accesses and illegal vector types t= hat > QEMU tolerated. That is rather an argument against QEMU than against this= MR > but still. _______________________________________________ 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".