[FFmpeg-devel] [PATCH 35/42] avcodec/threadprogress: Add new API for frame-threaded progress

[Michael Niedermayer]

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.
> 
> 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?
> 
> 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.
> 
> Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt at outlook.com>
> ---
>  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 operation 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) >= n)
        ^                    ~~~~~~~~~~~~~~
/usr/lib/llvm-6.0/lib/clang/6.0.0/include/stdatomic.h:135:30: note: expanded from macro 'atomic_load_explicit'
#define atomic_load_explicit __c11_atomic_load
                             ^
src/libavcodec/pthread_frame.c:1116:12: error: address argument to atomic operation 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: expanded 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' failed
make: *** [libavcodec/pthread_frame.o] Error 1
make: Target 'all' not remade because of errors.


[...]
-- 
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20230920/8dc49968/attachment.sig>