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 1E13643C18 for ; Sat, 23 Jul 2022 05:44:55 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id B16EB68B6EC; Sat, 23 Jul 2022 08:44:51 +0300 (EEST) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05olkn2097.outbound.protection.outlook.com [40.92.90.97]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 2AFCC68B2D8 for ; Sat, 23 Jul 2022 08:44:45 +0300 (EEST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=WYaSgJi2qd3vEiwEMDiA53eI6hP/PkR+qFpngehqSILIdyLBHKFjwC2seNDaey6+GV1qlbsxqkkU3C6V9dnjkbF05rwlKwsBVXd0lDJsSlTu/cDyEkrlauUeDApw1EDAAfvnOLhBE2Bu+OnbURQr2ut4YJ17wjv9h+6WabjaWkycjPMriUR5ONkHek1Ju9pfNHigxKPTNJZ3pzYswQPf5jpKTEXpMkaIoyEICPR+n/AIOe/w/JclwITtft5BaZq44czpbc5bvu+v9XeEGljN0mFbAOqIe38ufbs/75uWzizR1qVIrwe1oQPVcimOkB6eeUIR+HvUoPkozFdxx9W7wg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=g2sQnDRNRyVyc0NEMOozNpuTN0ysXK8dFSsH6oq1Q2A=; b=Nem5SAzPc5leq0IvoH0sYH5EgtiLDh5pptCAwYUkpcIoiwo/9VJNqkz2EWn+sW9MAnl1q1AItJo4VjWVxHVLrE3sxvFA9Uz2F1/vA7opPOPCd7AYoHufLsZTxW4n2P2v+7RnJYh9BegNBrs+YyKpBAfuPUVOXTgjtUymmwTmW5+mV+PXra1nSq8gKbfNkS+M861R96yJIsXh0H5WBx9tiHmCyvcnb/nO6D2hxYybFSD0LXBf558a8JGGzoYZkJ4tkHmEj1CEiEvnAhi+FT4UJKaJX17NEnoGFyJLLNZAEhvr3SNzL8nmLKvLqdmQjK1/InKLEPTs9KaWqKJUj03GHg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=g2sQnDRNRyVyc0NEMOozNpuTN0ysXK8dFSsH6oq1Q2A=; b=udE2lqHKHE2Qk5mdlvhvE0eW/mMwA/dxL1Voieul/IEzFfDBFebAm2+uT/VziwunrCbvIklYvJpYfjA+YcGMmFn+rXP8sQHeASMtjKeBft93g520UtPUPYKFY06hjtan9ahJpd7Q7WB5g/XCvalWeDSL+ZZKR2sWci7RPeBAFh8wIaCA81/h8y5uce2XwOo2EZGXaC5FmbAD6RL1GgwmacSQjDf/l/YCFb8o95vU08VQKsudi2oNzS88BGzGZaM5jMn/s9LI2cP8e9R762t+OvxHqRG3Ze0eaA3fAmfHrX/RKHvIERzAEI9jYb1JR7edO5cnEqz4+c8NwXvu020J+g== Received: from DB6PR0101MB2214.eurprd01.prod.exchangelabs.com (2603:10a6:4:42::27) by DU0PR01MB9240.eurprd01.prod.exchangelabs.com (2603:10a6:10:35f::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5458.20; Sat, 23 Jul 2022 05:44:42 +0000 Received: from DB6PR0101MB2214.eurprd01.prod.exchangelabs.com ([fe80::210e:b627:bcc9:8c46]) by DB6PR0101MB2214.eurprd01.prod.exchangelabs.com ([fe80::210e:b627:bcc9:8c46%11]) with mapi id 15.20.5458.020; Sat, 23 Jul 2022 05:44:42 +0000 Message-ID: Date: Sat, 23 Jul 2022 07:44:40 +0200 From: Andreas Rheinhardt To: ffmpeg-devel@ffmpeg.org References: <20220701212511.GY396728@pb2> <20220705222411.GM396728@pb2> Content-Language: en-US In-Reply-To: X-TMN: [r9g/TZuRHkSwX4eLc5h/XUbRZjLsmoAq] X-ClientProxiedBy: FR0P281CA0111.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:a8::12) To DB6PR0101MB2214.eurprd01.prod.exchangelabs.com (2603:10a6:4:42::27) X-Microsoft-Original-Message-ID: <769ae8fc-05c5-8451-f608-7e09b066a346@outlook.com> MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 3e7b03c2-e281-4bca-c05f-08da6c6e70a6 X-MS-TrafficTypeDiagnostic: DU0PR01MB9240:EE_ X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: tLmUj1EbLgw8C7FsTzZsvoKkCA5YVrv+ziaoGbpSlhprwvc5k53ZNy49h1tyrzNCgt4/bRoFSHciBWh6oKvQzmo3RDcEBPIjtl80FAOlIWOY8wrj4qIG9YlKmYvhfzK/S/j+hauof1TcuzVlMsrUxYOftdeClq9RFeFq5XPV0YbPUBTEi1XI1qu6QZpsnxTfwi1+BbGq5pVgQq027syuARkD1uYbY0PERkZU372EraCdNLl4tdmBCrFYCnrCgQBZUoRxG56fHRkH2fr+ZDjqfk04WWtTJu9tG20DHePZbJIWRXo/lJfI744xYA7vrUhmb+MxtsIiCLsJ+l+4Jbb/iNJ8kvxULxBd5pktnd69R0TG7V7HjqIjcxYFVe/SKNBhQI4sDO9svRaKfzFiLaE0Vvz4OJzE9LAcB4/FCy7wTJnB2bvma8IC/tgRzrCxDMm/b9fTTpWNwMewZ4rn4jjQNS7YOgzxVTOprjGi33N4UnAUJCAaKAK6mDK+HMznzkdRbwY9iOMuA6tz9mEeelJaFp0cXnC0IHmBmB5NOCNXG0rgpTeCkCswHSHViXUKJUuxWLBWVpUaJ9Ip0f3tBU9+2C/b5l9Oto5PG1IK0SxYN66uYZemUT+gsCXjTWOYAGEA8ZxktBMXIVYh5sWSqno5FJIzjWdnXtlMJAwPFrOqVHjAKAAwVktbMDfKfPpVhnF1 X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?OGNUNzQxaXJ0Q3NSenlMU2ViUWJhalUwV3o2R0VZYlI3Uk5SSzRrQkN4S0FP?= =?utf-8?B?SE9oZXBxaVpsZ1N4NU5WREVxVVJrNDExVnU3c2xrczRJakpyRFltMTluRHMz?= =?utf-8?B?Vnpxc2dqazlIRmNLaGYzKzh5WU9tNlp6N2xkTDhOczlQb0QzZ0NzRkMzdjBB?= =?utf-8?B?Y1h0eC85T2Z4N21STlVuanl3VVBlQnFYOXB6b3gzb2loMnk0Zy9XcDAydkJa?= =?utf-8?B?MVRySi9uc3VEa0JRaXljK2xuZlF3UFMveXJpQU5FOVhKQ1l3SmpVcVAvZnB0?= =?utf-8?B?alJqckNZVnZ3YW1qK01DYmcyWHIyZy9BNURmN3lkMDBOK05vMVZvU1Q4R1R6?= =?utf-8?B?amhzbU5DeWFRLzJDdVczVWlkTTRITi9Vb0M4aUt6dnFxTjdqUHhNeCsyb3U1?= =?utf-8?B?ckpzYnUzUE81RU9oNDlhWjVVT2NoZk9TR1M3NDc1UDVXazdqaCtEdVpZeGJl?= =?utf-8?B?Q0tBS3M2b3EvVEREZE02WGpjOVhyVnRBd1FoRVEvZXptZHdIalFOa0dObDd4?= =?utf-8?B?WHo4S2JNb3FweE9IN3NRcmdzODRFRGNKaEtkTjZlckgvTU9FbGZEYXY4NVZH?= =?utf-8?B?UVR5Y1Y5K0RZOFAvMEk0dkg2NVZqUHpaN2hSNGxlcloyUHZGOWZsTWx2dHYr?= =?utf-8?B?eXpmeXVaenlkcDVuNHZDWW9oY01EelJOdWpHbTBtL3piZ2Joci9TcFNNVExX?= =?utf-8?B?bTN6Q2YyRThRZmFRdUFhSlBwQjJmS1NCSzd3Q25KZDd5T1UzQ1BrOWo5ZVlm?= =?utf-8?B?V3FQeGVPUE10WStQUmVoMjVqc3BCY0orZ0c0TGtzcUlSMm9Fa0pOYU85T0gy?= =?utf-8?B?NENRRVUxS09YUkc1cTdDVnp1dkpPTkl1S3NQUkM3Qkw1SjJLQXJvdEdmZUE5?= =?utf-8?B?M1g0c1RCVDROdnVmYytpeERyMmpDaWxldnlXMHJFVEV1TUlSTDNJeDJzdUhD?= =?utf-8?B?bDFOYlU3YWxzR0xDc2hyT2E1clpwZTQxdVROc0ZYeWEzZGV1SVE4NzZSOFph?= =?utf-8?B?ZXVjL2xXOE9sNW1mbEttbUsvb29meWM2TVJKaHBCY0NaNlN2RU45eS9OcHdt?= =?utf-8?B?b1FlNUdBeWc0Mi9KcTNjUEJuajZSZDFWL05rT2FmWUVBaDFqM1M0d1ZhZ3pZ?= =?utf-8?B?V2o2ZzFtcnJQZ1UrcGQyeUpzc3lBNnlFUXFhL3ZWMWdBVTdoNDlRQkVmU0pa?= =?utf-8?B?U3VBV3l3MW5uZWdyOGFNaUE0MFlKd2l6WGVQMVpkUEFMN3lXYlRYL1psWUFt?= =?utf-8?B?WEh5Umw4aW9JRUR2OWNyaENQZUFqSWtFdHhTVnd1RnUySG4zeFdSM1ZVenlp?= =?utf-8?B?YXZRbllYZC9JbVJkN2RoMkE3dXVQSnFxUnA4RGRiRTNROXk1dnhZM2EwM3dU?= =?utf-8?B?Z3ZnK1pIYU9ZWWNOTGxVK1hKRVJZRjVObWRRR29QZXhYMVArY1Z5TnNhczhK?= =?utf-8?B?N0lXYTJKMUk2WmhjTUxXeURQQ3ZhclpYSFNsZUpMcFJCVThhUTZINnpvT0xD?= =?utf-8?B?QTlDU3ZxY2ltYWg0aFYyN2tvOU5aMSsxVDAzRnlac2NDaVp2eVppMnczMXFZ?= =?utf-8?B?cllmKzZnNCtEU2xWRXZHdzRpTjN2V240eWoxRWo3YnFTRUNwcWxEK1hzdk90?= =?utf-8?B?OXNjdFkvb1NSbmpqbVMwTnR5UEZWTW9KU0o2bEdrc1djdnJhZDM0TUxvaTdE?= =?utf-8?B?NHlBR3BDQTgrdHlQc1BLbE9XNENhUGlIRUY2TEpTUVpaUUxEK0N5M2V6YWw4?= =?utf-8?Q?e8YdFn0yzxUzjRpW0k=3D?= X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3e7b03c2-e281-4bca-c05f-08da6c6e70a6 X-MS-Exchange-CrossTenant-AuthSource: DB6PR0101MB2214.eurprd01.prod.exchangelabs.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Jul 2022 05:44:42.1181 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DU0PR01MB9240 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: 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 >>>>> --- >>>>> 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? - 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-request@ffmpeg.org with subject "unsubscribe".