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 B86F24772B for ; Wed, 20 Sep 2023 19:44:37 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 5588468C8CB; Wed, 20 Sep 2023 22:44:35 +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 2A8EC68C6F8 for ; Wed, 20 Sep 2023 22:44:29 +0300 (EEST) Received: by mail.gandi.net (Postfix) with ESMTPSA id 006F1240002 for ; Wed, 20 Sep 2023 19:44:27 +0000 (UTC) Date: Wed, 20 Sep 2023 21:44:26 +0200 From: Michael Niedermayer To: FFmpeg development discussions and patches Message-ID: <20230920194426.GM8640@pb2> References: MIME-Version: 1.0 In-Reply-To: X-GND-Sasl: michael@niedermayer.cc Subject: Re: [FFmpeg-devel] [PATCH 35/42] avcodec/threadprogress: Add new API for frame-threaded progress 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="===============4267005570283695953==" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: --===============4267005570283695953== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="N/EvDld9rH7KvG42" Content-Disposition: inline --N/EvDld9rH7KvG42 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Sep 19, 2023 at 09:57:27PM +0200, Andreas Rheinhardt wrote: > The API is very similar by the ProgressFrame API, with the exception > that it no longer has an included AVFrame. Instead one can wait > on anything via a ThreadProgress. One just has to ensure that > the lifetime of the object containing the ThreadProgress is long > enough (the corresponding problem for ProgressFrames is solved > by allocating the progress and giving each thread a reference > to it). This will typically be solved by putting a ThreadProgress > in a refcounted structure that is shared between threads. > It will be put to the test in the following commits. >=20 > An alternative to the check for whether the owner exists > (meaning "do we use frame-threading?") would be to initialize > the progress to INT_MAX in case frame threading is not in use. > This would probably be preferable on arches where atomic reads > are cheap (like x86), but are there ones where it is not? >=20 > One could also (guarded by e.g. an ASSERT_LEVEL check) actually > track the progress for non-framethreading, too, in order to > track errors even in single-threaded mode. >=20 > Signed-off-by: Andreas Rheinhardt > --- > libavcodec/pthread_frame.c | 50 +++++++++++++++++++++++++++++++++++++ > libavcodec/threadprogress.h | 37 +++++++++++++++++++++++++++ > 2 files changed, 87 insertions(+) > create mode 100644 libavcodec/threadprogress.h Seems to break build here with shared libs / clang CC libavcodec/pthread_frame.o src/libavcodec/pthread_frame.c:1108:9: error: address argument to atomic op= eration must be a pointer to non-const _Atomic type ('const atomic_int *' (= aka 'const _Atomic(int) *') invalid) atomic_load_explicit(&pro->progress, memory_order_acquire) >=3D n) ^ ~~~~~~~~~~~~~~ /usr/lib/llvm-6.0/lib/clang/6.0.0/include/stdatomic.h:135:30: note: expande= d from macro 'atomic_load_explicit' #define atomic_load_explicit __c11_atomic_load ^ src/libavcodec/pthread_frame.c:1116:12: error: address argument to atomic o= peration must be a pointer to non-const _Atomic type ('const atomic_int *' = (aka 'const _Atomic(int) *') invalid) while (atomic_load_explicit(&pro->progress, memory_order_relaxed) < n) ^ ~~~~~~~~~~~~~~ /usr/lib/llvm-6.0/lib/clang/6.0.0/include/stdatomic.h:135:30: note: expande= d from macro 'atomic_load_explicit' #define atomic_load_explicit __c11_atomic_load ^ 2 errors generated. src/ffbuild/common.mak:81: recipe for target 'libavcodec/pthread_frame.o' f= ailed make: *** [libavcodec/pthread_frame.o] Error 1 make: Target 'all' not remade because of errors. [...] --=20 Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Old school: Use the lowest level language in which you can solve the problem conveniently. New school: Use the highest level language in which the latest supercomputer can solve the problem without the user falling asleep waiting. --N/EvDld9rH7KvG42 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EABEIAB0WIQSf8hKLFH72cwut8TNhHseHBAsPqwUCZQtLlgAKCRBhHseHBAsP q89cAKCXxkclKmynYTS5YtajCEvDGyCQSACglVySnJKdDSI14NhOQOIFeza6Vbk= =+yWC -----END PGP SIGNATURE----- --N/EvDld9rH7KvG42-- --===============4267005570283695953== 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". --===============4267005570283695953==--