[Mesa-dev] shader-db statistics generation

[Kenneth Graunke]

On Monday, January 19, 2015 11:06:44 AM Eero Tamminen wrote:
> 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.

That's true, having the compiler print statistics would be sensible.

> 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.

Yeah, I'd definitely like to add statistics along these lines.

> [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.

While that sounds like a good idea in theory, I've never seen it actually
be a problem in practice.  I suspect it will be difficult to find a
non-contrived case that benefits sufficiently to justify the complexity.

--Ken
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20150119/e4bd87c4/attachment.sig>