[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240822142403.qz3ia26at3rxob2v@basti-XPS-13-9310>
Date: Thu, 22 Aug 2024 16:24:03 +0200
From: Sebastian Fricke <sebastian.fricke@...labora.com>
To: Fei Shao <fshao@...omium.org>
Cc: Nicolas Dufresne <nicolas.dufresne@...labora.com>,
AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>,
Hans Verkuil <hverkuil-cisco@...all.nl>,
Yunfei Dong <yunfei.dong@...iatek.com>,
Andrew-CT Chen <andrew-ct.chen@...iatek.com>,
Dan Carpenter <dan.carpenter@...aro.org>,
Matthias Brugger <matthias.bgg@...il.com>,
Mauro Carvalho Chehab <mchehab@...nel.org>,
Tiffany Lin <tiffany.lin@...iatek.com>,
Xiaoyong Lu <xiaoyong.lu@...iatek.com>,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
linux-media@...r.kernel.org, linux-mediatek@...ts.infradead.org
Subject: Re: [PATCH] media: mediatek: vcodec: Reduce msg queue trans buffer
size
Hey Fei,
On 07.06.2024 19:20, Fei Shao wrote:
>On Fri, May 31, 2024 at 8:47 PM Nicolas Dufresne
><nicolas.dufresne@...labora.com> wrote:
>>
>> Le mardi 21 mai 2024 à 17:54 +0800, Fei Shao a écrit :
>> > In the MediaTek HW vcodec pipeline, the `trans` buffer is used to
>> > transfer the data decoded by the lat decoder to the core decoder.
>> >
>> > In the beginning, 6MB and 30MB were allocated for the trans buffer to
>> > handle FHD and higher-resolution contents respectively, but it turns out
>> > that's more than enough in practice and there's room for improvement.
>> >
>> > The buffer sizes were reduced to 5MB / 8MB respectively and the decoders
>> > have been validated to work normally on the MediaTek Android products.
>> > It's time to adopt that change in the upstream MediaTek vcodec driver.
>> >
>> > Reduce the msg queue trans buffer size to 5MB / 8MB respectively to
>> > optimize the memory usage per decoder instance and improve the overall
>> > system performance.
>>
>> I don't disagree with the change, but it feels like this is has hack over a
>> hack. We have an entropy decoder (LAT) metadata buffer, which of course is
>> resolution dependent, for which we hardcore two sizes.
>>
>> Any chance Mediatek can document this blob, or at least document the proper
>> relation between the size and the resolution ? This way we could dynamically
>> size the buffer for the chosen resolution and trust it to remain big enough for
>> a long time. Removing the non scientific claim of "have been validated", which
>> is producible for anyone hitting issue with that change in the future.
>>
>> Nicolas
>>
>
>Sorry for the delayed reply. I totally agree with your point, but last
>time I was told these are what they are using internally so I guess
>it's not there... or it could be me that didn't ask the right question
>(we want to do this with finer granularity or dynamically).
>If we don't get an answer here, I can also bring this up to MediaTek
>next time and see if they can provide more details.
>
>Regards,
>Fei
So are you going to send a new version for this?
Regards,
Sebastian Fricke
Consultant Software Engineer
Collabora Ltd
Platinum Building, St John's Innovation Park, Cambridge CB4 0DS, UK
Registered in England & Wales no 5513718.
Powered by blists - more mailing lists