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 1299F45B39 for ; Fri, 17 Mar 2023 18:43:05 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id E75E968C236; Fri, 17 Mar 2023 20:43:02 +0200 (EET) Received: from mail0.khirnov.net (red.khirnov.net [176.97.15.12]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id AAD3868C228 for ; Fri, 17 Mar 2023 20:42:56 +0200 (EET) Received: from localhost (localhost [IPv6:::1]) by mail0.khirnov.net (Postfix) with ESMTP id 6F1A62404EA; Fri, 17 Mar 2023 19:42:56 +0100 (CET) Received: from mail0.khirnov.net ([IPv6:::1]) by localhost (mail0.khirnov.net [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id eH0Jhtgt6mTH; Fri, 17 Mar 2023 19:42:55 +0100 (CET) Received: from lain.khirnov.net (lain.khirnov.net [IPv6:2001:67c:1138:4306::3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "lain.khirnov.net", Issuer "smtp.khirnov.net SMTP CA" (verified OK)) by mail0.khirnov.net (Postfix) with ESMTPS id A8744240178; Fri, 17 Mar 2023 19:42:55 +0100 (CET) Received: by lain.khirnov.net (Postfix, from userid 1000) id 8C15B1601B2; Fri, 17 Mar 2023 19:42:55 +0100 (CET) From: Anton Khirnov To: FFmpeg development discussions and patches In-Reply-To: =?utf-8?q?=3CAS8P250MB0744735E972FB28A7F9DBF2B8FBE9=40AS8P250MB?= =?utf-8?q?0744=2EEURP250=2EPROD=2EOUTLOOK=2ECOM=3E?= References: =?utf-8?q?=3CAS8P250MB0744735E972FB28A7F9DBF2B8FBE9=40AS8P250MB0?= =?utf-8?q?744=2EEURP250=2EPROD=2EOUTLOOK=2ECOM=3E?= Mail-Followup-To: FFmpeg development discussions and patches , Andreas Rheinhardt Date: Fri, 17 Mar 2023 19:42:55 +0100 Message-ID: <167907857554.27013.13946921713761966315@lain.khirnov.net> User-Agent: alot/0.8.1 MIME-Version: 1.0 Subject: Re: [FFmpeg-devel] [PATCH] avcodec/decode: Reset MMX state for receive_frame decoders, too 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: Andreas Rheinhardt 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: Quoting Andreas Rheinhardt (2023-03-14 03:53:40) > FFmpeg's assembly code currently does not abide by the > plattform-specific ABIs wrt its handling of the X86 MMX flag: > Resetting the MMX state is deferred to avoid doing it multiple times > instead of ensuring that the CPU is in floating point state > upon return from any function. > > Furthermore, resetting said state is sometimes done generically, > namely for all the decoders using the ordinary decode callback; > yet this is not done for the decoders using the receive_frame API. > > This led to problems when MJPEG (and the MJPEG-based decoders) > were switched to the receive_frame API in commit > e9a2a8777317d91af658f774c68442ac4aa726ec, because ff_mjpeg_decode_sos() > only resets the MMX state on success, not on failure. > Such issues are probably still possible with SMVJPEG, which still > uses the receive_frame API. See issue #10210. > > This commit therefore also resets the MMX state for > the receive_frame API to avoid any more surprises of this sort. > > Signed-off-by: Andreas Rheinhardt > --- > Of course, I am in favour of actually abiding by the ABI, > even if it would cost performance; notice that there are > currently scenarios where emms_c() is called unnecessarily > (it is called generically and therefore even for codecs > that don't need it; furthermore, for some codecs it depends upon > the CPU flags used whether MMX code is in use, so it is unnecessary > for newer CPUs). Ideally we'd kill off all MMX code and forget about such issues, but that's presumably way easier said than done. > > libavcodec/decode.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/libavcodec/decode.c b/libavcodec/decode.c > index d1ba7f167f..22a0f8eb25 100644 > --- a/libavcodec/decode.c > +++ b/libavcodec/decode.c > @@ -547,6 +547,7 @@ static int decode_receive_frame_internal(AVCodecContext *avctx, AVFrame *frame) > > if (codec->cb_type == FF_CODEC_CB_TYPE_RECEIVE_FRAME) { > ret = codec->cb.receive_frame(avctx, frame); > + emms_c(); Should be ok. -- Anton Khirnov _______________________________________________ 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".