On Thursday, January 15, 2015 07:12:20 AM Jason Ekstrand wrote: > On Jan 15, 2015 12:27 AM, "Eero Tamminen" <eero.t.tammi...@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 <matts...@gmail.com> wrote: > >>> > >>> On Wed, Jan 14, 2015 at 1:29 PM, Matt Turner <matts...@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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev