[PATCH] media: mediatek: vcodec: Reduce msg queue trans buffer size

Sebastian Fricke sebastian.fricke at collabora.com
Thu Aug 22 07:24:03 PDT 2024


Hey Fei,

On 07.06.2024 19:20, Fei Shao wrote:
>On Fri, May 31, 2024 at 8:47 PM Nicolas Dufresne
><nicolas.dufresne at collabora.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.



More information about the Linux-mediatek mailing list