Linux ARM-MSM sub-architecture
 help / color / mirror / Atom feed
From: Dikshita Agarwal <quic_dikshita@quicinc.com>
To: Bryan O'Donoghue <bryan.odonoghue@linaro.org>,
	<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 17:56:16 +0530	[thread overview]
Message-ID: <95c9ab98-cebd-2ec2-bdb2-2f63bedb3f86@quicinc.com> (raw)
In-Reply-To: <ac44e16c-36af-471a-b47b-bb26ccd9f018@linaro.org>



On 3/6/2025 6:35 AM, Bryan O'Donoghue wrote:
> 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 ?
> 
Bin buffers are intermediate buffers which are used by different sub
hardware blocks within video IP. The calculation of these buffers are
hardware mandated. While we can't explain/justify every factor, these are
based on hardware constraints and validated with firmware requirements,
Software is just coding it up the way hardware specification defines it.
>> +    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.
I believe the MACROS here defines the parameters used in calculation,
beyond this, its again how internal buffers (used by hardware) are
calculated by hardware and defined in the hardware specification.

Thanks,
Dikshita
> 
> ---
> bod

  reply	other threads:[~2025-03-06 12:26 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
2025-03-06 12:26     ` Dikshita Agarwal [this message]
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=95c9ab98-cebd-2ec2-bdb2-2f63bedb3f86@quicinc.com \
    --to=quic_dikshita@quicinc.com \
    --cc=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_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