Michael Niedermayer:
> 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 done.
>>>>>>>>>
>>>>>>>>> Yet the preceding patches changed this, making it possible
>>>>>>>>> to avoid allocating redundant HEVCContexts.
>>>>>>>>>
>>>>>>>>> Signed-off-by: Andreas Rheinhardt <andreas.rheinha...@outlook.com>
>>>>>>>>> ---
>>>>>>>>> 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(AVCodecContext *avctxt, void *hevc_lclist,
>>>>>>>>> {
>>>>>>>>> HEVCLocalContext *lc =
>>>>>>>>> ((HEVCLocalContext**)hevc_lclist)[self_id];
>>>>>>>>> const HEVCContext *const s = lc->parent;
>>>>>>>>> - HEVCContext *s1 = avctxt->priv_data;
>>>>>>>>> - int ctb_size = 1<< s1->ps.sps->log2_ctb_size;
>>>>>>>>> + int ctb_size = 1 << s->ps.sps->log2_ctb_size;
>>>>>>>>> int more_data = 1;
>>>>>>>>> int ctb_row = job;
>>>>>>>>> - int ctb_addr_rs = s1->sh.slice_ctb_addr_rs + ctb_row *
>>>>>>>>> ((s1->ps.sps->width + ctb_size - 1) >> s1->ps.sps->log2_ctb_size);
>>>>>>>>> - int ctb_addr_ts = s1->ps.pps->ctb_addr_rs_to_ts[ctb_addr_rs];
>>>>>>>>> - int thread = ctb_row % s1->threads_number;
>>>>>>>>> + int ctb_addr_rs = 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 = s->ps.pps->ctb_addr_rs_to_ts[ctb_addr_rs];
>>>>>>>>> + int thread = ctb_row % s->threads_number;
>>>>>>>>> int ret;
>>>>>>>>>
>>>>>>>>> if(ctb_row) {
>>>>>>>>> @@ -2572,7 +2571,7 @@ static int hls_decode_entry_wpp(AVCodecContext
>>>>>>>>> *avctxt, void *hevc_lclist,
>>>>>>>>>
>>>>>>>>> ff_thread_await_progress2(s->avctx, ctb_row, thread,
>>>>>>>>> SHIFT_CTB_WPP);
>>>>>>>>>
>>>>>>>>> - if (atomic_load(&s1->wpp_err)) {
>>>>>>>>> + if (atomic_load(&s->wpp_err)) {
>>>>>>>>> ff_thread_report_progress2(s->avctx, ctb_row , thread,
>>>>>>>>> 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 atomic
>>>>>>>> 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 const in
>>>>>>> 7.17.7.2:
>>>>>>>
>>>>>>> C atomic_load(volatile A *object);
>>>>>>>
>>>>>>> Upon reflection this makes sense, because if atomics are implemented via
>>>>>>> mutexes, even a read may involve a preceding write. So I'll cast const
>>>>>>> away here, too, and add a comment. (It works when casting const away,
>>>>>>> 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 have
>>>>> 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 implicit
>>>>>> cast
>>>>>> it produces a warning
>>>>>>
>>>>
>>>> Did the above explanation satisfy you? Or do you want something else?
>>>
>>> sure, ok
>>>
>>> [...]
>>>
>>
>> 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/cf441e559b8d4bf2c05c29483ccf49e82fc6b863
>> 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
> maintaince over
>
Compiling (in particular being on the lookout for new warnings) and a
simple fate should be enough.
- Andreas
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
