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 DD5D8495CA for ; Thu, 13 Jun 2024 21:19:29 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id EE7CE68D9A1; Fri, 14 Jun 2024 00:19:27 +0300 (EEST) Received: from relay1-d.mail.gandi.net (relay1-d.mail.gandi.net [217.70.183.193]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 8D1AD68D8F8 for ; Fri, 14 Jun 2024 00:19:20 +0300 (EEST) Received: by mail.gandi.net (Postfix) with ESMTPSA id E5E85240002 for ; Thu, 13 Jun 2024 21:19:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=niedermayer.cc; s=gm1; t=1718313560; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=kAopcEp0xbvJ7ojM2ch0rErX70ohSkHWTexToHtM0aA=; b=H8LcNKzmAIm99ondwys/4zqtAlrEaMKrXQc+buIUtgrF1Z87Yj1AnovOX2GAFZRKQdTND1 iRh/lX+ccm4MjuO+soQhy9YcqbXaBTupG67D7Ylh8pZFnImBPmEltvW1wwy/CjkStjCzPD p2Ykp/scqXATjFbp1c2J5143h+zzcGNwQMIteEJY53UJMdCmHA6nP18UAX/tK5eiPGMTSR Zo/wHNS0LdciV+W0RwFQqI4Z0+oSd+MQuM5XIBsdUUY3Q7kzkuGBOv54ZAAB1aSf8GAv7U G38IYqlvD3U+PMYCuRQcczVf0DeZEY2uxbKkpObdqFfjMXht9yNTnNLeCy+McA== Date: Thu, 13 Jun 2024 23:19:18 +0200 From: Michael Niedermayer To: FFmpeg development discussions and patches Message-ID: <20240613211918.GI2821752@pb2> References: <20240613073654.GB2821752@pb2> MIME-Version: 1.0 In-Reply-To: X-GND-Sasl: michael@niedermayer.cc Subject: Re: [FFmpeg-devel] [PATCH 33/57] avcodec/mpv_reconstruct_mb_template: Don't unnecessarily copy data 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="===============1903122735026296247==" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: --===============1903122735026296247== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="uPiOk/BpLtGBqCov" Content-Disposition: inline --uPiOk/BpLtGBqCov Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jun 13, 2024 at 10:50:36AM +0200, Andreas Rheinhardt wrote: > Michael Niedermayer: > > On Wed, Jun 12, 2024 at 03:48:29PM +0200, Andreas Rheinhardt wrote: > >> There is no reason to use a temporary buffer as destination > >> for the new macroblock before copying it into its proper place. > >> > >> (History: 3994623df2efd2749631c3492184dd8d4ffa9d1b changed > >> the precursor of ff_mpv_reconstruct_mb() to always decode > >> to the first row of macroblocks for B pictures when > >> a draw_horiz_band callback is set (they are exported to the caller > >> via said callback and each row overwrites the previously decoded > >> row; this was probably intended as a cache-optimization). > >> Later b68ab2609c67d07b6f12ed65125d76bf9a054479 changed this > >> to the current form in which a scratchpad buffer is used when > >> decoding B-pictures without draw_horiz_band callback, followed > >> by copying the block from the scratchpad buffer to the actual > >> destination. I do not know what the aim of this was. When thinking > >> of it as a cache optimization, it makes sense to not use it > >> when the aforementioned draw_horiz_band optimization is in effect, > >> because then the destination row can be presumed to be hot > >> already. But then it makes no sense to restrict this optimization > >> to B-frames.) > >=20 > > IIRC > > The B frames where directly placed in GPU memory, which is slow to read > > from, so building up MC + IDCT (which could read depending on caches) > > was avoided by a a scratchpad but its really long ago so i might rememb= er > > this only partly > >=20 >=20 > The code here is not executed for hardware acceleration at all. For the > ordinary case, this copy incurs overhead; furthermore it increases > complexity (and for these reasons no other codec has similar code). So > I'd like to remove it (with an amended commit message that says that > this was done due to concerns about reading from GPU memory). Do you > object to this? i dont object, i was trying to explain why this was there. This predates modern hw acceleration. The memory in AVFrame.data[] for a normal pixel format can be mapped to GPU memory. FFmpeg itself probably did not set it up this way but some applications did do this with get_buffer() callbacks VERY long ago IIRC to avoid having to copy the image later when the application belived the image would not be read from. (like a B fr= ame in MPEG-2 times) thx [...] --=20 Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The day soldiers stop bringing you their problems is the day you have stopp= ed=20 leading them. They have either lost confidence that you can help or conclud= ed=20 you do not care. Either case is a failure of leadership. - Colin Powell --uPiOk/BpLtGBqCov Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EABEKAB0WIQSf8hKLFH72cwut8TNhHseHBAsPqwUCZmtiVQAKCRBhHseHBAsP q/PPAJ4qFABKrcNWsjsugQNpsNMo3AddLACfY2kJDV96Wiv9AOr121SsDiKCWNg= =AnM4 -----END PGP SIGNATURE----- --uPiOk/BpLtGBqCov-- --===============1903122735026296247== 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". --===============1903122735026296247==--