[Mesa-dev] shader-db statistics generation (was: [PATCH 3/4] i965/fs: Optimize (gl_FrontFacing ? x : y)...)

[Kenneth Graunke]

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:
> >
> > Hi,
> >
> > On 01/15/2015 03:04 AM, Matt Turner wrote:
> >>
> >> On Wed, Jan 14, 2015 at 1:52 PM, Matt Turner <mattst88 at gmail.com> wrote:
> >>>
> >>> On Wed, Jan 14, 2015 at 1:29 PM, Matt Turner <mattst88 at gmail.com> wrote:
> >>>>
> >>>> glsl: Optimize certain if-statements to just casts from the condition
> >>>
> >>>
> >>> Cherry-picked to master, the shader-db results are
> >>>
> >>> total instructions in shared programs: 5965630 -> 5952789 (-0.22%)
> >>> instructions in affected programs:     737228 -> 724387 (-1.74%)
> >>> GAINED:                                5
> >>> LOST:                                  16
> >>>
> >>> and we hurt 20 programs: 12 vec4 programs significantly (>68%) and 8
> >>> SIMD8/16 programs by 1 instruction.
> >>
> >>
> >> It looks like the vec4 programs have loops that are now able to be
> >> unrolled, so those are actually improvements.
> >
> >
> > Out of curiosity, do you always look also at the cases where instructions
> were removed, or do you have some other way to verify that something didn't
> e.g. cause loop unrolling to fail?
> >
> > 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.

--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/20150116/c32ac526/attachment.sig>