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 431804266F for ; Sun, 24 Jul 2022 21:23:28 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 47D4B68B76C; Mon, 25 Jul 2022 00:23:25 +0300 (EEST) Received: from relay12.mail.gandi.net (relay12.mail.gandi.net [217.70.178.232]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 0EB3368B4AF for ; Mon, 25 Jul 2022 00:23:17 +0300 (EEST) Received: (Authenticated sender: michael@niedermayer.cc) by mail.gandi.net (Postfix) with ESMTPSA id 0292F200004 for ; Sun, 24 Jul 2022 21:23:16 +0000 (UTC) Date: Sun, 24 Jul 2022 23:23:14 +0200 From: Michael Niedermayer To: FFmpeg development discussions and patches Message-ID: <20220724212314.GT2088045@pb2> References: <20220701212511.GY396728@pb2> <20220705222411.GM396728@pb2> <20220723143802.GR2088045@pb2> MIME-Version: 1.0 In-Reply-To: Subject: Re: [FFmpeg-devel] [PATCH 14/18] avcodec/hevcdec: Don't allocate redundant HEVCContexts 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="===============4758115130647500124==" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: --===============4758115130647500124== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="wKbYzd8t8rt1PVqr" Content-Disposition: inline --wKbYzd8t8rt1PVqr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jul 23, 2022 at 11:42:23PM +0200, Andreas Rheinhardt wrote: > Michael Niedermayer: > > On Sat, Jul 23, 2022 at 07:44:40AM +0200, Andreas Rheinhardt wrote: > >> Andreas Rheinhardt: > >>> Michael Niedermayer: > >>>> On Sat, Jul 02, 2022 at 08:32:06AM +0200, Andreas Rheinhardt wrote: > >>>>> Michael Niedermayer: > >>>>>> On Fri, Jul 01, 2022 at 12:29:45AM +0200, Andreas Rheinhardt wrote: > >>>>>>> The HEVC decoder has both HEVCContext and HEVCLocalContext > >>>>>>> structures. The latter is supposed to be the structure > >>>>>>> containing the per-slicethread state. > >>>>>>> > >>>>>>> Yet up until now that is not how it is handled in practice: > >>>>>>> Each HEVCLocalContext has a unique HEVCContext allocated for it > >>>>>>> and each of these coincides except in exactly one field: The > >>>>>>> corresponding HEVCLocalContext. This makes it possible to pass > >>>>>>> the HEVCContext everywhere where logically a HEVCLocalContext > >>>>>>> should be used. And up until recently, this is how it has been do= ne. > >>>>>>> > >>>>>>> Yet the preceding patches changed this, making it possible > >>>>>>> to avoid allocating redundant HEVCContexts. > >>>>>>> > >>>>>>> Signed-off-by: Andreas Rheinhardt > >>>>>>> --- > >>>>>>> libavcodec/hevcdec.c | 40 ++++++++++++++++----------------------= -- > >>>>>>> libavcodec/hevcdec.h | 2 -- > >>>>>>> 2 files changed, 16 insertions(+), 26 deletions(-) > >>>>>>> > >>>>>>> diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c > >>>>>>> index 9d1241f293..048fcc76b4 100644 > >>>>>>> --- a/libavcodec/hevcdec.c > >>>>>>> +++ b/libavcodec/hevcdec.c > >>>>>>> @@ -2548,13 +2548,12 @@ static int hls_decode_entry_wpp(AVCodecCo= ntext *avctxt, void *hevc_lclist, > >>>>>>> { > >>>>>>> HEVCLocalContext *lc =3D ((HEVCLocalContext**)hevc_lclist)[s= elf_id]; > >>>>>>> const HEVCContext *const s =3D lc->parent; > >>>>>>> - HEVCContext *s1 =3D avctxt->priv_data; > >>>>>>> - int ctb_size =3D 1<< s1->ps.sps->log2_ctb_size; > >>>>>>> + int ctb_size =3D 1 << s->ps.sps->log2_ctb_size; > >>>>>>> int more_data =3D 1; > >>>>>>> int ctb_row =3D job; > >>>>>>> - int ctb_addr_rs =3D s1->sh.slice_ctb_addr_rs + ctb_row * ((s= 1->ps.sps->width + ctb_size - 1) >> s1->ps.sps->log2_ctb_size); > >>>>>>> - int ctb_addr_ts =3D s1->ps.pps->ctb_addr_rs_to_ts[ctb_addr_r= s]; > >>>>>>> - int thread =3D ctb_row % s1->threads_number; > >>>>>>> + int ctb_addr_rs =3D s->sh.slice_ctb_addr_rs + ctb_row * ((s-= >ps.sps->width + ctb_size - 1) >> s->ps.sps->log2_ctb_size); > >>>>>>> + int ctb_addr_ts =3D s->ps.pps->ctb_addr_rs_to_ts[ctb_addr_rs= ]; > >>>>>>> + int thread =3D ctb_row % s->threads_number; > >>>>>>> int ret; > >>>>>>> =20 > >>>>>>> if(ctb_row) { > >>>>>>> @@ -2572,7 +2571,7 @@ static int hls_decode_entry_wpp(AVCodecCont= ext *avctxt, void *hevc_lclist, > >>>>>>> =20 > >>>>>>> ff_thread_await_progress2(s->avctx, ctb_row, thread, SHI= FT_CTB_WPP); > >>>>>>> =20 > >>>>>>> - if (atomic_load(&s1->wpp_err)) { > >>>>>>> + if (atomic_load(&s->wpp_err)) { > >>>>>>> ff_thread_report_progress2(s->avctx, ctb_row , threa= d, SHIFT_CTB_WPP); > >>>>>> > >>>>>> the consts in "const HEVCContext *const " make clang version 6.0.0= -1ubuntu2 unhappy > >>>>>> (this was building shared libs) > >>>>>> > >>>>>> > >>>>>> CC libavcodec/hevcdec.o > >>>>>> src/libavcodec/hevcdec.c:2574:13: error: address argument to atomi= c operation must be a pointer to non-const _Atomic type ('const atomic_int = *' (aka 'const _Atomic(int) *') invalid) > >>>>>> if (atomic_load(&s->wpp_err)) { > >>>>>> ^ ~~~~~~~~~~~ > >>>>>> /usr/lib/llvm-6.0/lib/clang/6.0.0/include/stdatomic.h:134:29: note= : expanded from macro 'atomic_load' > >>>>>> #define atomic_load(object) __c11_atomic_load(object, __ATOMIC_SEQ= _CST) > >>>>>> ^ ~~~~~~ > >>>>>> 1 error generated. > >>>>>> src/ffbuild/common.mak:81: recipe for target 'libavcodec/hevcdec.o= ' failed > >>>>>> make: *** [libavcodec/hevcdec.o] Error 1 > >>>>>> > >>>>>> thx > >>>>>> > >>>>> > >>>>> Thanks for testing this. atomic_load is indeed declared without con= st in > >>>>> 7.17.7.2: > >>>>> > >>>>> C atomic_load(volatile A *object); > >>>>> > >>>>> Upon reflection this makes sense, because if atomics are implemente= d via > >>>>> mutexes, even a read may involve a preceding write. So I'll cast co= nst > >>>>> away here, too, and add a comment. (It works when casting const awa= y, > >>>>> doesn't it?) > >>>> > >>>> This doesnt feel "right". These pointers should not be coming from a= const > >>>> if they are written to > >>>> > >>> > >>> The HEVCContext is not const because the underlying object is const; = the > >>> HEVCContext is const when accessed from any part of the code that may= be > >>> run from slice threads, because if a slice thread modifies it, you ha= ve > >>> a data race in case any of the other slice threads reads this field or > >>> modifies it itself. But this is by definition not true for atomic > >>> operations, so casting const away for them is fine. > >>> > >>>> The compiler accepts it with an explicit cast though. With an implic= it cast > >>>> it produces a warning > >>>> > >> > >> Did the above explanation satisfy you? Or do you want something else? > >=20 > > sure, ok > >=20 > > [...] > >=20 >=20 > Good to hear. This patchset (namely patch 11/18: "avcodec/hevcpred: Pass > HEVCLocalContext when slice-threading") includes modifications to mips > code that I created blindly. Can you please test it? Here is a branch of > this rebased on top of current git master: > https://github.com/mkver/FFmpeg/commits/hevc_wpp > (Said branch actually contains a bit of further work which also modifies > mips code (in particular, > https://github.com/mkver/FFmpeg/commit/cf441e559b8d4bf2c05c29483ccf49e82f= c6b863 > does so); you may also test this.) what exact tests do we need ? simple fate ? any specific thread type count ? also note i can only test qemu mips not real hw. I stopped maintaining the MIPS hw and sofar noone volunteered to take its= =20 maintaince over thx --=20 Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The smallest minority on earth is the individual. Those who deny=20 individual rights cannot claim to be defenders of minorities. - Ayn Rand --wKbYzd8t8rt1PVqr Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EABEIAB0WIQSf8hKLFH72cwut8TNhHseHBAsPqwUCYt24PgAKCRBhHseHBAsP q2h+AKCCYqfz3oxWRlwC5WQl0AHw3nc3/wCfRNKSZdDrNSZgXpF6svbmC7Ejb+Y= =7aLx -----END PGP SIGNATURE----- --wKbYzd8t8rt1PVqr-- --===============4758115130647500124== 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". --===============4758115130647500124==--