[Mesa-dev] shader-db statistics generation

[Eero Tamminen]

Hi,

On 01/16/2015 11:43 PM, Kenneth Graunke wrote:
> On Thursday, January 15, 2015 07:12:20 AM Jason Ekstrand wrote:
>> On Jan 15, 2015 12:27 AM, "Eero Tamminen" <eero.t.tamminen at intel.com> wrote:
...
>>> Any ideas how the loop unrolling could be reliably be taken into account
>> automatically in these statistics?
>>>
>>> Maybe with some extra output from compiler which outputs loop counter and
>> marks loop start and end so that statistics generator can:
>>> - count number of loops that could / could not be be unrolled
>>> - multiply number of instructions inside loops by loop counter,
>>>    if the counter is a static value
>>>
>>>
>>>          - Eero
>>
>> It already dumps out the number of loops in the final code. It would be
>> easy to add some code to the results parser to identify that number
>> changing.
>
> Abdiel actually did that a while back - there's code on the "loops" branch
> of the public shader-db.  We never came up with a decent way to classify
> loop changes as "helped" or "hurt".
>
> Figuring out the number of loop invocations sounds like a good idea, but
> is generally hard.  I suppose we could at least find the common
> for (i = 0; i < n; i++) pattern...pretty easy to recognize that at least.

Because it's possible that different loops get and don't get unrolled,
compiler could index loops and outputting at end list of indexes for
loops that couldn't be unrolled.  Statistics code can then compare those
lists for differences.

If some of the earlier unrolled loops doesn't anymore get unrolled,
manual inspection is needed.  If only additional unrolling happens,
I guess we can for now assume it to be better [1].  If exactly same
loops are unrolled, then comparing instruction counts is OKish.

However, there should be statistics also about memory fetches
(for textures, spilled registers etc).  Depending on case, those
(and their scheduling) can often be more important than just
ALU operations.

[1] Next problem comes when backend gets logic for rejecting loop
unrolling based on I-cache utilization etc.  Information about those
decisions need then to be included to the output & statistics too.


	- Eero