<div dir="ltr"><div dir="ltr">Hi Jacopo,</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, May 12, 2021 at 4:45 PM Jacopo Mondi <<a href="mailto:jacopo@jmondi.org">jacopo@jmondi.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Hiro, everyone<br>
<br>
On Wed, May 12, 2021 at 09:16:17AM +0200, Jacopo Mondi wrote:<br>
> Hi Hiro,<br>
>    Yes sorry<br>
><br>
> On Wed, May 12, 2021 at 01:23:14PM +0900, Hirokazu Honda wrote:<br>
> > >> > > > +     unsigned int ifWidth = utils::alignUp(in.width, IF_ALIGN_W);<br>
> > >> > > > +     unsigned int ifHeight = utils::alignUp(in.height, IF_ALIGN_H);<br>
> > >> > > > +     unsigned int minIfWidth = in.width - IF_CROP_MAX_W;<br>
> > >> > > > +     unsigned int minIfHeight = in.height - IF_CROP_MAX_H;<br>
> > >> > ><br>
> > >> ><br>
> > >> > Should we std::max(0u, in.width - IF_CROP_MAX_W)?<br>
> > >><br>
> > >> I would be careful and not use 0, but probably 2 and 4 as it seems to be<br>
> > >> the<br>
> > >> vertical and horizontal alignments the ImgU requires<br>
> > >><br>
> > >> > If in.width < IF_CROP_MAX_W, an overflow happens and minIfWidth becomes<br>
> > >> > very large.<br>
> > >> > Ditto to height.<br>
> > >><br>
> > >> Laurent had the same question, and we received patch in the past that<br>
> > >> was probably related to an issue like this one, if the input size is<br>
> > >> smaller than 540 (as IF_CROP_MAX_H=540).<br>
> > >> <a href="https://patchwork.libcamera.org/patch/11620/" rel="noreferrer" target="_blank">https://patchwork.libcamera.org/patch/11620/</a><br>
> > >><br>
> > >> I've opened (yet) a new issue on the python script this code is based<br>
> > >> on to have Intel's opinion on which is the min IF crop size<br>
> > >> <a href="https://github.com/intel/intel-ipu3-pipecfg/issues/3" rel="noreferrer" target="_blank">https://github.com/intel/intel-ipu3-pipecfg/issues/3</a><br>
> > >><br>
> > >><br>
> > > The variable in the python script is (signed) integer.<br>
> > > So overflow doesn't happen.<br>
> > > The code may work even if width < IF_CROP_MAX_W (I don't check the code<br>
> > > any more than it)?<br>
> > > On the other hand, our code doesn't work because the following while-loop<br>
> > > doesn't loop..?<br>
> > > I see your point. It is the best to set the minimum allowed value after we<br>
> > > get their feedback.<br>
> > > But, hmm, shall we set it to IF_ALIGN_W as the temporary workaround to the<br>
> > > overflow with todo comment?<br>
> > > Well, since the code of causing the overflow is in top-of-tree, I don't<br>
> > > mind merging this.<br>
> > ><br>
> > ><br>
> ><br>
> > Ping. Can you respond to this before you merge this patch?<br>
> ><br>
><br>
> I've taken your suggestion in<br>
><br>
> I now have got in my wip v3 version:<br>
><br>
> +       unsigned int minIfWidth = std::min(IF_ALIGN_W,<br>
> +                                          in.width - IF_CROP_MAX_W);<br>
> +       unsigned int minIfHeight = std::min(IF_ALIGN_H,<br>
> +                                           in.height - IF_CROP_MAX_H);<br>
><br>
> I will send it out anyway before merging.<br>
><br>
<br>
Run some more testing. With the above change, the number of<br>
resolutions that are actually tested quickly becomes not manageable at<br>
run time.<br>
<br>
Just starting the HAL takes 5 seconds per each camera and the number<br>
of tested configurations goes up to HALF A MILLION (for each<br>
resolutions combination we test at HAL startup time).<br>
<br>
The overflow helps skipping a lot of configurations, with a maximum of<br>
30.000 or so. Which is anyway awful but acceptable as the HAL startup<br>
delay is barely noticeable.<br>
<br>
I'm not sure how to move forward, if we just skip heights <<br>
IF_CROP_MAX_H (which is 540) to avoid the overflow, we would rule out<br>
sensors that produces images smaller than 540. This happens today<br>
already so it won't technically be a regression, it's just bad.<br>
<br></blockquote><div><br></div><div>Wow... it is pretty bad.</div><div>IMHO, we can go ahead temporarily with the overflow leaving a todo comment and let's file a bug about it as this is not a regression introduced by this.</div><div>We may want to discuss in the issue tracker.</div><div><br></div><div>-Hiro</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> ><br>
> > > -Hiro<br>
> > ><br>
> > > I'm thinking of fixing this issue, and the other ones reported during<br>
> > >> review of this series (and reflected as issues on the script's github)<br>
> > >> on top.<br>
> > >><br>
> > >> I'm overly-concerned with the idea of deviating from the script. I've<br>
> > >> received several comments on how things could have been done better,<br>
> > >> but I'm pushing back as I want this code to be as similar as possible<br>
> > >> to the intel's script, otherwise every 4 months when (I have to)<br>
> > >> compare the two implementation my brain will melt even more than<br>
> > >> usual.<br>
> > >><br>
> > >> Result: the code is of awful quality as the script is.<br>
> > >><br>
> > >> I re-state the requirement from Intel to provide documentation on<br>
> > >> how the ImgU sizes have to be computed instead of a buggy script<br>
> > >> (which I apreciate a lot don't get me wrong, I'm sure the author has<br>
> > >> put some of his free time to implement that as I'm quite sure nobody<br>
> > >> in there apreciate spending more company time on IPU3, but the result<br>
> > >> is a best effort implementation nobody is proud of).<br>
> > >><br>
> > >> Even better if they could do directly in libcamera... a man can<br>
> > >> dream... So far we received close to 0 attention from them and surely<br>
> > >> we have no leverage from here to convince them of the contrary :)<br>
> > >> Maybe you could push a little to have them consider us a little<br>
> > >> bit more ?<br>
> > >><br>
> > >> Thanks<br>
> > >>    j<br>
> > >><br>
> > >> ><br>
> > >> ><br>
> > >> > > >       while (ifWidth >= minIfWidth) {<br>
> > >> > > > -             Size iif{ ifWidth, ifHeight };<br>
> > >> > > > -             calculateBDS(pipe, iif, gdc, sf);<br>
> > >> > > > +             while (ifHeight >= minIfHeight) {<br>
> > >> > > > +                     Size iif{ ifWidth, ifHeight };<br>
> > >> > > > +                     calculateBDS(pipe, iif, gdc, sf);<br>
> > >> > > > +                     ifHeight -= IF_ALIGN_H;<br>
> > >> > > > +             }<br>
> > >> > > ><br>
> > >> > > >               ifWidth -= IF_ALIGN_W;<br>
> > >> > > >       }<br>
> > >> > > ><br>
> > >> > > > +     /* Repeat search by scaling width first. */<br>
> > >> > > > +     ifWidth = utils::alignUp(in.width, IF_ALIGN_W);<br>
> > >> > > > +     ifHeight = utils::alignUp(in.height, IF_ALIGN_H);<br>
> > >> > > > +     minIfWidth = in.width - IF_CROP_MAX_W;<br>
> > >> > > > +     minIfHeight = in.height - IF_CROP_MAX_H;<br>
> > >> > > > +     while (ifHeight >= minIfHeight) {<br>
> > >> > > > +             /*<br>
> > >> > > > +              * \todo This procedure is probably broken:<br>
> > >> > > > +              *<br>
> > >> <a href="https://github.com/intel/intel-ipu3-pipecfg/issues/2" rel="noreferrer" target="_blank">https://github.com/intel/intel-ipu3-pipecfg/issues/2</a><br>
> > >> > > > +              */<br>
> > >> > > > +             while (ifWidth >= minIfWidth) {<br>
> > >> > > > +                     Size iif{ ifWidth, ifHeight };<br>
> > >> > > > +                     calculateBDS(pipe, iif, gdc, sf);<br>
> > >> > > > +                     ifWidth -= IF_ALIGN_W;<br>
> > >> > > > +             }<br>
> > >> > > > +<br>
> > >> > > > +             ifHeight -= IF_ALIGN_H;<br>
> > >> > > > +     }<br>
> > >> > > > +<br>
> > >> > > >       if (pipeConfigs.size() == 0) {<br>
> > >> > > >               LOG(IPU3, Error) << "Failed to calculate pipe<br>
> > >> > > configuration";<br>
> > >> > > >               return {};<br>
> > >> > > > --<br>
> > >> > > > 2.31.1<br>
> > >> > > ><br>
> > >> > > > _______________________________________________<br>
> > >> > > > libcamera-devel mailing list<br>
> > >> > > > <a href="mailto:libcamera-devel@lists.libcamera.org" target="_blank">libcamera-devel@lists.libcamera.org</a><br>
> > >> > > > <a href="https://lists.libcamera.org/listinfo/libcamera-devel" rel="noreferrer" target="_blank">https://lists.libcamera.org/listinfo/libcamera-devel</a><br>
> > >> > ><br>
> > >> > > --<br>
> > >> > > Regards,<br>
> > >> > > Niklas Söderlund<br>
> > >> > > _______________________________________________<br>
> > >> > > libcamera-devel mailing list<br>
> > >> > > <a href="mailto:libcamera-devel@lists.libcamera.org" target="_blank">libcamera-devel@lists.libcamera.org</a><br>
> > >> > > <a href="https://lists.libcamera.org/listinfo/libcamera-devel" rel="noreferrer" target="_blank">https://lists.libcamera.org/listinfo/libcamera-devel</a><br>
> > >> > ><br>
> > >><br>
> > ><br>
> _______________________________________________<br>
> libcamera-devel mailing list<br>
> <a href="mailto:libcamera-devel@lists.libcamera.org" target="_blank">libcamera-devel@lists.libcamera.org</a><br>
> <a href="https://lists.libcamera.org/listinfo/libcamera-devel" rel="noreferrer" target="_blank">https://lists.libcamera.org/listinfo/libcamera-devel</a><br>
</blockquote></div></div>