[Mesa-dev] [PATCH 1/5] i965/icl: Fix L3 configurations

[Anuj Phogat]

On Fri, Nov 16, 2018 at 2:52 PM Francisco Jerez <currojerez at riseup.net> wrote:
>
> Anuj Phogat <anuj.phogat at gmail.com> writes:
>
> > On Fri, Nov 16, 2018 at 6:21 AM Eero Tamminen <eero.t.tamminen at intel.com> wrote:
> >>
> >> Hi,
> >>
> >> On 16.11.2018 10.33, Francisco Jerez wrote:
> >> > Kenneth Graunke <kenneth at whitecape.org> writes:
> >> [...]
> >> >> Perhaps we'll get both configs working, and then will want to be able
> >> >> to select between them.  I question whether the additional URB is truly
> >> >> that valuable - how large are the actual gains? - considering that we
> >> >> have to stall in order to reconfigure everything anyway...
> >>
> >> It's more about value of additional space for caching textures.
> >>
> >> One can calculate required max URB space when GS/TS isn't used, whereas
> >> textures can fill all available cache.  For example, if draw does just a
> >> single quad, L3 is better utilized with minimal URB space and leaving
> >> rest for texture caching.
> >>
> > Right. URB (16) and ALL (80) config is the one with minimum URB allocation.
> > But, it's not working probably because of a hardware bug. Inferring from above
> > comments by ken and Eero, If we ever get it working, we should always be using
> > just that one config and that's the config which h/w documentation recommends
> > as well. Correct me if that's not what you meant.
>
> I don't think anybody said that.  There is a use-case for the 32/64
> configuration even after we get thee other configuration working, that's
> why the hardware even gives you the choice.
>
> > In that case, I would prefer to bypass all this code and do it in
> > brw_upload_initial_gpu_state().
> >
>
> There is no real benefit from that.  It would be more complexity than
> using the exact same codepath for all platforms.  It won't improve
> runtime performance measurably.  And it will close the door to several
> performance optimizations which are still valuable on ICL.
>
ok. I don't see an agreement on the changes proposed by Ken. So, I propose
to go ahead with current way of uploading l3 config on ICL and make further
changes on top of it when we have more information. I think programming the
right config is more important atm.

> >>
> >> > That just means that the update frequency needs to be low enough for the
> >> > stall overhead to be negligible -- E.g. at batch buffer boundaries or
> >> > wherever we're getting stalled anyway.
> >>
> >>
> >>         - Eero
> >> _______________________________________________
> >> mesa-dev mailing list
> >> mesa-dev at lists.freedesktop.org
> >> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
> > _______________________________________________
> > mesa-dev mailing list
> > mesa-dev at lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev