mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Nicolas Dufresne <nicolas.dufresne@collabora.com>
To: Fei Shao <fshao@chromium.org>,
	AngeloGioacchino Del Regno
	<angelogioacchino.delregno@collabora.com>,
	Hans Verkuil <hverkuil-cisco@xs4all.nl>
Cc: Yunfei Dong <yunfei.dong@mediatek.com>,
	Andrew-CT Chen <andrew-ct.chen@mediatek.com>,
	Dan Carpenter <dan.carpenter@linaro.org>,
	 Matthias Brugger <matthias.bgg@gmail.com>,
	Mauro Carvalho Chehab <mchehab@kernel.org>,
	Tiffany Lin <tiffany.lin@mediatek.com>,
	Xiaoyong Lu <xiaoyong.lu@mediatek.com>,
	 linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org,  linux-media@vger.kernel.org,
	linux-mediatek@lists.infradead.org
Subject: Re: [PATCH] media: mediatek: vcodec: Reduce msg queue trans buffer size
Date: Fri, 31 May 2024 08:47:02 -0400	[thread overview]
Message-ID: <9f73dffc48394e6304263ac2293a2b18864ae3dd.camel@collabora.com> (raw)
In-Reply-To: <20240521095536.3869399-1-fshao@chromium.org>

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

> 
> Signed-off-by: Fei Shao <fshao@chromium.org>
> 
> CC: Yunfei Dong <yunfei.dong@mediatek.com>
> 
> ---
> I consulted Yunfei and he confirmed that these are the sizes they are
> using today.
> 
>  .../media/platform/mediatek/vcodec/decoder/vdec_msg_queue.c   | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/media/platform/mediatek/vcodec/decoder/vdec_msg_queue.c b/drivers/media/platform/mediatek/vcodec/decoder/vdec_msg_queue.c
> index f283c4703dc6..e36741179a97 100644
> --- a/drivers/media/platform/mediatek/vcodec/decoder/vdec_msg_queue.c
> +++ b/drivers/media/platform/mediatek/vcodec/decoder/vdec_msg_queue.c
> @@ -29,9 +29,9 @@
>  static int vde_msg_queue_get_trans_size(int width, int height)
>  {
>  	if (width > 1920 || height > 1088)
> -		return 30 * SZ_1M;
> +		return 8 * SZ_1M;
>  	else
> -		return 6 * SZ_1M;
> +		return 5 * SZ_1M;
>  }
>  
>  void vdec_msg_queue_init_ctx(struct vdec_msg_queue_ctx *ctx, int hardware_index)


  reply	other threads:[~2024-05-31 12:47 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-21  9:54 Fei Shao
2024-05-31 12:47 ` Nicolas Dufresne [this message]
2024-06-07 11:20   ` Fei Shao
2024-08-22 14:24     ` Sebastian Fricke
2024-09-11  6:29       ` Fei Shao

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=9f73dffc48394e6304263ac2293a2b18864ae3dd.camel@collabora.com \
    --to=nicolas.dufresne@collabora.com \
    --cc=andrew-ct.chen@mediatek.com \
    --cc=angelogioacchino.delregno@collabora.com \
    --cc=dan.carpenter@linaro.org \
    --cc=fshao@chromium.org \
    --cc=hverkuil-cisco@xs4all.nl \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=linux-mediatek@lists.infradead.org \
    --cc=matthias.bgg@gmail.com \
    --cc=mchehab@kernel.org \
    --cc=tiffany.lin@mediatek.com \
    --cc=xiaoyong.lu@mediatek.com \
    --cc=yunfei.dong@mediatek.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®