On Fri, Nov 16, 2018 at 2:52 PM Francisco Jerez <curroje...@riseup.net> wrote: > > Anuj Phogat <anuj.pho...@gmail.com> writes: > > > On Fri, Nov 16, 2018 at 6:21 AM Eero Tamminen <eero.t.tammi...@intel.com> > > wrote: > >> > >> Hi, > >> > >> On 16.11.2018 10.33, Francisco Jerez wrote: > >> > Kenneth Graunke <kenn...@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@lists.freedesktop.org > >> https://lists.freedesktop.org/mailman/listinfo/mesa-dev > > _______________________________________________ > > mesa-dev mailing list > > mesa-dev@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/mesa-dev _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
