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

[Francisco Jerez]

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.

>>
>> > 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20181116/584a32a2/attachment.sig>