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 EF69A43A3E for ; Wed, 6 Jul 2022 08:21:33 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 78EE068BA37; Wed, 6 Jul 2022 11:21:29 +0300 (EEST) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-oln040092064049.outbound.protection.outlook.com [40.92.64.49]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 1479568B9F9 for ; Wed, 6 Jul 2022 11:21:22 +0300 (EEST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=OaBGZpIgQjvwRrW696nMIkvf3dMMWqHtHW/PJKeo5GjHSjhEgbD2Jc+3uFOvqf6UnHBQLYkMA0uNz+n/yAnORAJADCKU+KHxGn8BCZcDp2/AVMn0Nzqnn4eaX1udLIJaYw6QFgeKqRDWre78HyE75imlip1XvSxX32L4YS6cAPEadvBzPZyvnDjbQR7pnd2z1KZQdkkY2pKYuFPIvRx0sun8mDK8svrAJoHGYrF4xVhanNZfWJocxuNITiZaOgZhZBDVTyZkctFpSxfwxfFei5tPaeB5chI5w8S3sTS2ttXB5nKLVfLrfKpCfOwFtDPFFjr9RloTN8D2kYlhjr4i2Q== 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=reKcpoRK8SxG/CcRQGOHhlbtFfUDwpLHadpdDdrwODw=; b=cmuoQD3WUf5m7SqsuxdlB8Jnwyxx/mVghG+Ah/XSxXvuKIXH57Kzvg7TWkLAZcxAzULJYXMez6Stin42qZHAoiayHRWR0ofZhjWuumKYrDIooIqbGjUw1hK4O0kM53864Uzel5vPlzJoOI9u6Ax/h3hN51EmYU+VEYOMeZPjZsXVIMLYNEpDF7ZFdpgrQoQxfC/Yzma6RVwJZpMI2WVVKFz0J+lJWqARJs2a9wBjJHcRYgojTsQ8eJmsVphx7znhK+vMiEEDAptH4EyMjsXQv8m1dtWtm0HWTNktTIiNWahyfaxtaHuvZ/YMEeFUiz2ZY/aSI1a+Igv0lZvvErx7rg== 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=reKcpoRK8SxG/CcRQGOHhlbtFfUDwpLHadpdDdrwODw=; b=d4qsxAHmrPG6kdA+lft80EE4RVQrISmxCERhjiSoopUYA0xLWMW0BrYLd+1jvAtUGZLGBmF6qvEKJPk7S9Lc7ScA6020VhHstRuSbNpZgnBUWZstYasca7S84giA4A7P0hDO2gIZvhZmerM9j3BeksMiwjCTFNTGrYx2uQYSRhtGGR0xYlmfOMzkpR7STxWO9Hio/QYqYZpX/iZSxbhauXmfG46fr7CtStLb2nJsOiYr7jXxCXqcnJxF08SzFl7ZU/cdtTQduFGOBc+6Z8yi/eN9nf4cT7f2mwoVTjVlxOhJVSarGzM9U94G+ZYinduLMqMf80a6VpyIjHWN3dy+Mg== Received: from DB6PR0101MB2214.eurprd01.prod.exchangelabs.com (2603:10a6:4:42::27) by VI1PR0102MB3167.eurprd01.prod.exchangelabs.com (2603:10a6:803:6::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5395.15; Wed, 6 Jul 2022 08:21:20 +0000 Received: from DB6PR0101MB2214.eurprd01.prod.exchangelabs.com ([fe80::60b9:9f29:40cc:f01c]) by DB6PR0101MB2214.eurprd01.prod.exchangelabs.com ([fe80::60b9:9f29:40cc:f01c%10]) with mapi id 15.20.5395.021; Wed, 6 Jul 2022 08:21:20 +0000 Message-ID: Date: Wed, 6 Jul 2022 10:21:18 +0200 Content-Language: en-US To: ffmpeg-devel@ffmpeg.org References: <20220701212511.GY396728@pb2> <20220705222411.GM396728@pb2> From: Andreas Rheinhardt In-Reply-To: <20220705222411.GM396728@pb2> X-TMN: [RW8UHPYOKgNOVsZlToqO7qgT8McnGhYL] X-ClientProxiedBy: AM6PR02CA0029.eurprd02.prod.outlook.com (2603:10a6:20b:6e::42) To DB6PR0101MB2214.eurprd01.prod.exchangelabs.com (2603:10a6:4:42::27) X-Microsoft-Original-Message-ID: <2ebb618c-0ba3-33bc-2926-202336582ac9@outlook.com> MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 4b896eda-6d85-48ac-936c-08da5f288151 X-MS-TrafficTypeDiagnostic: VI1PR0102MB3167:EE_ X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: mpsSoY10+sdbJYEOluqa+VsCWO0icOuvYaep7RztWVQP3W7DzGqc0RuZqP8JJXoSJA/zxLvLbXG60RCrTCsH6aNvgYS/LLmm+2ntGd4cC6UITj1shqW1VA1jXMFijtxHnh7Sth5TADghkLEEMIq+fgZyBwWZr1YYwRSstn428oBJFG6DjsZrHEEfF5DCqQ7KypDKa/gWjVSVTfZwMzRTsLb6xP1LoNHsKlcV8IECuuCq//wAt1DREMQKj12UFYnZCiWEJh/vH6zuN45lMbUmRNsS3ev8ng8D/l8l10hzao0H8FdSjJPiGrve8CZK2mFOLaP4JK7e391jADGpivTtdgVb7ZYYy7xSwZ57qFsadywtDWIJe6wU28EDq274ugOWEGxdMtAAPEVteNJUF9OfC+4FdGzjeETi7vszxvhl7ZI67d3bDHHMYIb6IRyDqhnkzD2UZ7kYDJKVjxdSALyuLxT37ezAS/a9HMaW2ykkeIK/gbIYI78XSeMjNdyqZv1CfbandenNZdb5ULRdm1ezoJ6xbzVYGK1wl3rE6rT4YVcc1R+/eTwYY3W3BMHgzJebsfFAOdxz/t9QvsNWOP6MEhqD7xaWsZETtOFcxhCtFDnxTKvf+A0qMa00WL9aXG4lqjNlmMbBXpTqvyczUDrcBg== X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?RnBuUFRHR1lNOFE5NWtmM3U4VlVVVWJ2WnVWY1dyNlNFOFRGNStzZ204QjJJ?= =?utf-8?B?b0ZJNEE2UEt3VlNPT0o1ZXdnSEhqb2IyVnV0NUtFZitsdGZYZGlIblJ4cHR6?= =?utf-8?B?YThNU09DUm96NFNGUXhRZThxc0ZJRTBxQXNnRGZHWUJnMXhUMlk4dmpGWjhH?= =?utf-8?B?Mm5WZno0REYvRTZHKzlzUDVtS0cxMW1sTVJPV0w3YmxYYkpKZmoyRUNzMjJu?= =?utf-8?B?UUJxQlBZazZEL0h4Mm9zVStSTStYR1Y0RjBPSk0rNEdGTGdpbmtVS2hveC90?= =?utf-8?B?cDFYTVNldS9QK2cxcHducFNjeVRFQXVxTFduRGRrT1dnUHIrbUtlb0hhVkla?= =?utf-8?B?dTF6dnNKdHlHTGVpdFFGY2Q0dWRLbzRXZmRrQ21IRnNPeEswUXJTUkJ0ZTRu?= =?utf-8?B?VHEvZGNFWlpETXJVQjRLZkhiaGxsR210UC9ZamlPUEhVVjk3ODVPOW0yY3Rx?= =?utf-8?B?L2xVNE5yS0R3bm1MV2gvZG1TcmMzTlBuVWJWRFFRR2R5eDgvbzRDZzBGM0dw?= =?utf-8?B?aDg2Y3dScC81QVVYU1ZLQ3AyVDhRWndoYmt3NnNwdjI1VHFjZW10TC9sMG5I?= =?utf-8?B?ZHlvdW9YekxadzlsWFk3UXZtM1dHUkh5WURFNUpnYndUSWJHL2d3Q1Fmc1Na?= =?utf-8?B?TXlpOXc4WlFxRDRlTTc5bXcvTVhaclFtaDg3RmdNa3hKQU1Gbk5NdGdvN04v?= =?utf-8?B?ejdISldyYnVPTmNYTDc2c0tRN1R1RlRkS25NdGNBVFJHMzhwUUVyOUJjRU4x?= =?utf-8?B?VWkyZGIveUZnMU1YWlVOSHNZNUdJOWxRWkJLdzU4bDQ1Q1lVWG5GMlJJWlhy?= =?utf-8?B?dHp2eWhiU1kvNUVLNVArZVpvUjYyMGs5YTVLNVpucW42eUs3MVZ2cHMwM09i?= =?utf-8?B?TlY3dGNvMDAwRDcrZWhIRk96SDlsRnN2b21RMExWNEtYR00rNXByZzYyVzhH?= =?utf-8?B?NXpmRVhZVFliMXVQbFpyaUJCTWIyRCtYZ1RUeTJEREt6YXJQdHNVbkNvVURx?= =?utf-8?B?MVpaTmRVNk1YOW1JY0pPYU1ueERibEVXdXhteDN0YkRLUTNwdVVCc0QwNkRk?= =?utf-8?B?RTZJcDFRV2xNRVRrQ01tM1c3dVBXVzhzTWpXMHpocWVkVVZzSE9MK1JqY0Uz?= =?utf-8?B?MXI5TUxaWjJvNXlmM1poK3BIYWxNNytkOXBCNnEvVXpNN2JEY3VrU3kyd21G?= =?utf-8?B?eHdKZldBU0diWEhlSDY0L0diRUEvQmpkNTAzMktzUW16ZDQ1cjJoUGpNR2JL?= =?utf-8?B?cFBPSkFvOFpHUnBoeUNqMW1xaGxodWUyQngwNWtSUlpZT1dnc3JTUmZWc21x?= =?utf-8?B?eVJuYWpid3V4cVFNbUFSSjFCMExxREo2TWhjNS90RW9DSWlVeHZxU3JnOVln?= =?utf-8?B?WU1yVjh4M1grSWpRRHVTZ1UzYTNvVStTUHhaT2Zxc0tzcXFyZ0htUlU0azB6?= =?utf-8?B?Ti9SN0pmUVZqU0ZOak9SSkNLVkVxdGVJcTlTbzA4MDRMQU4veWtib1BNKzZo?= =?utf-8?B?UDRYWElISzJmckJ0ckgzdzlpZU9ZdUZ5emZmb2sxdEJSaCtQVjgyaVloenZr?= =?utf-8?B?MFQzbmt2dDFHMjRKb2h3b1lsZmxvMDF4cDlXdWM4M0RFNG1KVEZ0ajF5WHpr?= =?utf-8?B?cUZna084TE42ZXdrTWNCS1BmeGpkSUsxUjNrUXdFeEpnVFVRSHZiazhJSEYr?= =?utf-8?B?MVlXdU5EUE9yYmhPdWNxMWFqUHlvM3BDWm8yMWRZaUlxYWI3dWZPNFZLRnM4?= =?utf-8?Q?Lcmmr/yluqTyaaVoV8=3D?= X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4b896eda-6d85-48ac-936c-08da5f288151 X-MS-Exchange-CrossTenant-AuthSource: DB6PR0101MB2214.eurprd01.prod.exchangelabs.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Jul 2022 08:21:20.2947 (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: VI1PR0102MB3167 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: 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 > _______________________________________________ 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".