linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Tomasz Figa <tfiga@chromium.org>
To: Stanimir Varbanov <stanimir.varbanov@linaro.org>
Cc: mgottam@codeaurora.org, Hans Verkuil <hverkuil@xs4all.nl>,
	Mauro Carvalho Chehab <mchehab@kernel.org>,
	Linux Media Mailing List <linux-media@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-arm-msm <linux-arm-msm@vger.kernel.org>,
	Alexandre Courbot <acourbot@chromium.org>,
	vgarodia@codeaurora.org
Subject: Re: [PATCH] media: venus: amend buffer size for bitstream plane
Date: Tue, 13 Nov 2018 18:13:36 +0900	[thread overview]
Message-ID: <CAAFQd5DXWUCB7HvsLyVYU+h=2j6y1v3kcsTtHfNZYjfbHEgWGw@mail.gmail.com> (raw)
In-Reply-To: <86714c89-20ec-07c8-2569-65e78e8d584d@linaro.org>

On Tue, Nov 13, 2018 at 5:12 PM Stanimir Varbanov
<stanimir.varbanov@linaro.org> wrote:
>
> Hi Malathi,
>
> On 11/13/18 9:28 AM, mgottam@codeaurora.org wrote:
> > On 2018-11-12 18:04, Stanimir Varbanov wrote:
> >> Hi Tomasz,
> >>
> >> On 10/23/2018 05:50 AM, Tomasz Figa wrote:
> >>> Hi Malathi,
> >>>
> >>> On Tue, Oct 9, 2018 at 4:58 PM Malathi Gottam
> >>> <mgottam@codeaurora.org> wrote:
> >>>>
> >>>> For lower resolutions, incase of encoder, the compressed
> >>>> frame size is more than half of the corresponding input
> >>>> YUV. Keep the size as same as YUV considering worst case.
> >>>>
> >>>> Signed-off-by: Malathi Gottam <mgottam@codeaurora.org>
> >>>> ---
> >>>>  drivers/media/platform/qcom/venus/helpers.c | 2 +-
> >>>>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>>>
> >>>> diff --git a/drivers/media/platform/qcom/venus/helpers.c
> >>>> b/drivers/media/platform/qcom/venus/helpers.c
> >>>> index 2679adb..05c5423 100644
> >>>> --- a/drivers/media/platform/qcom/venus/helpers.c
> >>>> +++ b/drivers/media/platform/qcom/venus/helpers.c
> >>>> @@ -649,7 +649,7 @@ u32 venus_helper_get_framesz(u32 v4l2_fmt, u32
> >>>> width, u32 height)
> >>>>         }
> >>>>
> >>>>         if (compressed) {
> >>>> -               sz = ALIGN(height, 32) * ALIGN(width, 32) * 3 / 2 / 2;
> >>>> +               sz = ALIGN(height, 32) * ALIGN(width, 32) * 3 / 2;
> >>>>                 return ALIGN(sz, SZ_4K);
> >>>>         }
> >>>
> >>> Note that the driver should not enforce one particular buffer size for
> >>> bitstream buffers unless it's a workaround for broken firmware or
> >>> hardware. The userspace should be able to select the desired size.
> >>
> >> Good point! Yes, we have to extend set_fmt to allow bigger sizeimage for
> >> the compressed buffers (not only for encoder).
> >
> > So Stan you meant to say that we should allow s_fmt to accept client
> > specified size?
>
> yes but I do expect:
>
> new_sizeimage = max(user_sizeimage, venus_helper_get_framesz)
>
> and also user_sizeimage should be sanitized.
>
> > If so should we set the inst->input_buf_size here in venc_s_fmt?
> >
> > @@ -333,10 +333,10 @@static const struct venus_format *
> > venc_try_fmt_common(struct venus_inst *inst, struct v4l2_format *f)
> >
> >         pixmp->num_planes = fmt->num_planes;
> >         pixmp->flags = 0;
> > -
> > -       pfmt[0].sizeimage = venus_helper_get_framesz(pixmp->pixelformat,
> > -                                                    pixmp->width,
> > -                                                    pixmp->height);
> > +       if (!pfmt[0].sizeimage)
> > +               pfmt[0].sizeimage =
> > venus_helper_get_framesz(pixmp->pixelformat,
> > +                                                            pixmp->width,
> > +
> > pixmp->height);
>
> yes, but please make
>
> pfmt[0].sizeimage = max(pfmt[0].sizeimage, venus_helper_get_framesz)
>
> and IMO this should be only for CAPTURE queue i.e. inst->output_buf_size
>
> I'm still not sure do we need it for OUTPUT encoder queue.
>

This would be indeed only for the queues that operate on a coded
bitstream, i.e. both encoder CAPTURE and decoder OUTPUT.

For image formats, sizeimage should be calculated by the driver based
on the bytesperline and height. (Bytesperline may be fixed, if the
hardware doesn't support flexible strides, but if it does, it's
strongly recommended to use the bytesperline coming from the
application as the stride +/- any necessary sanity checks.)

Best regards,
Tomasz

  reply	other threads:[~2018-11-13  9:13 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-09  7:52 [PATCH] media: venus: amend buffer size for bitstream plane Malathi Gottam
2018-10-22  6:12 ` Alexandre Courbot
2018-10-23  2:50 ` Tomasz Figa
2018-11-12 12:34   ` Stanimir Varbanov
2018-11-13  7:28     ` mgottam
2018-11-13  8:12       ` Stanimir Varbanov
2018-11-13  9:13         ` Tomasz Figa [this message]
2018-11-13 10:46           ` Stanimir Varbanov
2018-11-14  3:51             ` Tomasz Figa
2018-11-16  4:34               ` mgottam
2018-11-16  6:02                 ` Tomasz Figa
2018-11-12 12:28 ` Stanimir Varbanov

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='CAAFQd5DXWUCB7HvsLyVYU+h=2j6y1v3kcsTtHfNZYjfbHEgWGw@mail.gmail.com' \
    --to=tfiga@chromium.org \
    --cc=acourbot@chromium.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=mgottam@codeaurora.org \
    --cc=stanimir.varbanov@linaro.org \
    --cc=vgarodia@codeaurora.org \
    /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;
as well as URLs for NNTP newsgroup(s).