Linux ARM-MSM sub-architecture
 help / color / mirror / Atom feed
From: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
To: Dikshita Agarwal <quic_dikshita@quicinc.com>,
	quic_vgarodia@quicinc.com, quic_abhinavk@quicinc.com,
	mchehab@kernel.org
Cc: hverkuil@xs4all.nl, linux-media@vger.kernel.org,
	linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH 04/12] media: iris: Add internal buffer calculation for HEVC and VP9 decoders
Date: Thu, 6 Mar 2025 01:05:50 +0000	[thread overview]
Message-ID: <ac44e16c-36af-471a-b47b-bb26ccd9f018@linaro.org> (raw)
In-Reply-To: <20250305104335.3629945-5-quic_dikshita@quicinc.com>

On 05/03/2025 10:43, Dikshita Agarwal wrote:
> Add internal buffer count and size calculations for HEVC and VP9
> decoders.
> 
> Signed-off-by: Dikshita Agarwal <quic_dikshita@quicinc.com>
> ---
>   .../media/platform/qcom/iris/iris_buffer.c    |   3 +
>   .../platform/qcom/iris/iris_vpu_buffer.c      | 397 +++++++++++++++++-
>   .../platform/qcom/iris/iris_vpu_buffer.h      |  46 +-
>   3 files changed, 432 insertions(+), 14 deletions(-)
> 
> diff --git a/drivers/media/platform/qcom/iris/iris_buffer.c b/drivers/media/platform/qcom/iris/iris_buffer.c
> index e5c5a564fcb8..8c9d5b7fe75c 100644
> --- a/drivers/media/platform/qcom/iris/iris_buffer.c
> +++ b/drivers/media/platform/qcom/iris/iris_buffer.c
> @@ -205,6 +205,9 @@ static u32 iris_bitstream_buffer_size(struct iris_inst *inst)
>   	if (num_mbs > NUM_MBS_4K) {
>   		div_factor = 4;
>   		base_res_mbs = caps->max_mbpf;
> +	} else {
> +		if (inst->codec == V4L2_PIX_FMT_VP9)
> +			div_factor = 1;
>   	}
>   
>   	/*
> diff --git a/drivers/media/platform/qcom/iris/iris_vpu_buffer.c b/drivers/media/platform/qcom/iris/iris_vpu_buffer.c
> index dce25e410d80..13ee93356bcb 100644
> --- a/drivers/media/platform/qcom/iris/iris_vpu_buffer.c
> +++ b/drivers/media/platform/qcom/iris/iris_vpu_buffer.c
> @@ -31,6 +31,42 @@ static u32 hfi_buffer_bin_h264d(u32 frame_width, u32 frame_height, u32 num_vpp_p
>   	return size_h264d_hw_bin_buffer(n_aligned_w, n_aligned_h, num_vpp_pipes);
>   }
>   
> +static u32 size_h265d_hw_bin_buffer(u32 frame_width, u32 frame_height, u32 num_vpp_pipes)
> +{
> +	u32 product = frame_width * frame_height;
> +	u32 size_yuv, size_bin_hdr, size_bin_res;
> +
> +	size_yuv = (product <= BIN_BUFFER_THRESHOLD) ?
> +		((BIN_BUFFER_THRESHOLD * 3) >> 1) : ((product * 3) >> 1);

When I read this code I have no way of knowing if it makes sense.

#define BIN_BUFFER_THRESHOLD		(1280 * 736)

((BIN_BUFFER_THRESHOLD * 3) >> 1)

How/why is that correct ?

> +	size_bin_hdr = size_yuv * H265_CABAC_HDR_RATIO_HD_TOT;
> +	size_bin_res = size_yuv * H265_CABAC_RES_RATIO_HD_TOT;
> +	size_bin_hdr = ALIGN(size_bin_hdr / num_vpp_pipes, DMA_ALIGNMENT) * num_vpp_pipes;
> +	size_bin_res = ALIGN(size_bin_res / num_vpp_pipes, DMA_ALIGNMENT) * num_vpp_pipes;
> +
> +	return size_bin_hdr + size_bin_res;
> +}
> +
> +static u32 hfi_buffer_bin_vp9d(u32 frame_width, u32 frame_height, u32 num_vpp_pipes)
> +{
> +	u32 _size_yuv = ALIGN(frame_width, 16) * ALIGN(frame_height, 16) * 3 / 2;
> +	u32 _size = ALIGN(((max_t(u32, _size_yuv, ((BIN_BUFFER_THRESHOLD * 3) >> 1)) *
> +			VPX_DECODER_FRAME_BIN_HDR_BUDGET / VPX_DECODER_FRAME_BIN_DENOMINATOR *
> +			VPX_DECODER_FRAME_CONCURENCY_LVL) / num_vpp_pipes), DMA_ALIGNMENT) +
> +			ALIGN(((max_t(u32, _size_yuv, ((BIN_BUFFER_THRESHOLD * 3) >> 1)) *
> +			VPX_DECODER_FRAME_BIN_RES_BUDGET / VPX_DECODER_FRAME_BIN_DENOMINATOR *
> +			VPX_DECODER_FRAME_CONCURENCY_LVL) / num_vpp_pipes), DMA_ALIGNMENT);

The size_yuv I guess just about makes sense but the _size component here 
is pretty hard to say whether or not this adds up.

Could you please add some comments to describe the calculations in these 
complex size/alignment clauses.

---
bod

  reply	other threads:[~2025-03-06  1:05 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-05 10:43 [RFC PATCH 00/12] Add support for HEVC and VP9 codecs in decoder Dikshita Agarwal
2025-03-05 10:43 ` [RFC PATCH 01/12] media: iris: Add HEVC and VP9 formats for decoder Dikshita Agarwal
2025-03-06  0:17   ` Bryan O'Donoghue
2025-03-06 11:55     ` Dikshita Agarwal
2025-03-05 10:43 ` [RFC PATCH 02/12] media: iris: Add platform capabilities for HEVC and VP9 decoders Dikshita Agarwal
2025-03-06  0:28   ` Bryan O'Donoghue
2025-03-06 12:07     ` Dikshita Agarwal
2025-03-05 10:43 ` [RFC PATCH 03/12] media: iris: Set mandatory properties " Dikshita Agarwal
2025-03-05 14:00   ` neil.armstrong
2025-03-06 12:10     ` Dikshita Agarwal
2025-03-06  0:52   ` Bryan O'Donoghue
2025-03-06 12:16     ` Dikshita Agarwal
2025-03-05 10:43 ` [RFC PATCH 04/12] media: iris: Add internal buffer calculation " Dikshita Agarwal
2025-03-06  1:05   ` Bryan O'Donoghue [this message]
2025-03-06 12:26     ` Dikshita Agarwal
2025-03-05 10:43 ` [RFC PATCH 05/12] media: iris: Skip destroying internal buffer if not dequeued Dikshita Agarwal
2025-03-05 20:44   ` Dmitry Baryshkov
2025-03-06 12:26     ` Dikshita Agarwal
2025-03-05 10:43 ` [RFC PATCH 06/12] media: iris: Update CAPTURE format info based on OUTPUT format Dikshita Agarwal
2025-03-05 20:45   ` Dmitry Baryshkov
2025-03-06 12:27     ` Dikshita Agarwal
2025-03-05 10:43 ` [RFC PATCH 07/12] media: iris: Add handling for corrupt and drop frames Dikshita Agarwal
2025-03-06  1:12   ` Bryan O'Donoghue
2025-03-05 10:43 ` [RFC PATCH 08/12] media: iris: Avoid updating frame size to firmware during reconfig Dikshita Agarwal
2025-03-06  1:26   ` Bryan O'Donoghue
2025-03-06 12:32     ` Dikshita Agarwal
2025-03-05 10:43 ` [RFC PATCH 09/12] media: iris: Avoid sending LAST flag multiple times Dikshita Agarwal
2025-03-05 10:43 ` [RFC PATCH 10/12] media: iris: Send V4L2_BUF_FLAG_ERROR for buffers with 0 filled length Dikshita Agarwal
2025-03-05 10:43 ` [RFC PATCH 11/12] media: iris: Fix handling of eos buffer during drain Dikshita Agarwal
2025-03-05 10:43 ` [RFC PATCH 12/12] media: iris: Add handling for no show frames Dikshita Agarwal
2025-03-05 14:22 ` [RFC PATCH 00/12] Add support for HEVC and VP9 codecs in decoder neil.armstrong
2025-03-06 12:34   ` Dikshita Agarwal

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=ac44e16c-36af-471a-b47b-bb26ccd9f018@linaro.org \
    --to=bryan.odonoghue@linaro.org \
    --cc=hverkuil@xs4all.nl \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=mchehab@kernel.org \
    --cc=quic_abhinavk@quicinc.com \
    --cc=quic_dikshita@quicinc.com \
    --cc=quic_vgarodia@quicinc.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