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. >> >> > 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
signature.asc
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
