[Mesa-dev] [PATCH 01/22] glsl: Reorder optimization-passes

[Matt Turner]

On Sat, Jan 17, 2015 at 10:33 AM, Matt Turner <mattst88 at gmail.com> wrote:
> On Sat, Jan 17, 2015 at 8:31 AM, Thomas Helland
> <thomashelland90 at gmail.com> wrote:
>> 2015-01-03 22:48 GMT+01:00 Matt Turner <mattst88 at gmail.com>:
>>> On Sat, Jan 3, 2015 at 11:18 AM, Thomas Helland
>>> <thomashelland90 at gmail.com> wrote:
>>>> This allows opt_algebraic to resolve open-coded
>>>> saturates into ir_unop_saturate before we potentially
>>>> mess it up by removing the min or max in min/max-pruning.
>>>>
>>>> Since we are now emitting more free saturates on i965
>>>> this gives us some decrease in instruction count.
>>>>
>>>> total instructions in shared programs: 1317459 -> 1317065 (-0.03%)
>>>> instructions in affected programs:     4084 -> 3690 (-9.65%)
>>>> GAINED:                                0
>>>> LOST:                                  0
>>>
>>> You're definitely onto something here. On our collection of shaders:
>>>
>>> total instructions in shared programs: 5876617 -> 5875919 (-0.01%)
>>> instructions in affected programs:     9443 -> 8745 (-7.39%)
>>>
>>> with some fragment shaders hurt in Natural Selection 2 and Kerbal Space program.
>>>
>>> I'll investigate these.
>>
>> Hi Matt,
>>
>> Don't want to be a nuisance (if that is even the right word?
>> English is not my native tongue), but did you find the
>> time to look at these regressions?
>
> Nuisance is indeed the right word, but you are not being one. :)
>
> I'll definitely look into this. Sorry that I haven't had a chance yet.

I've looked at three hurt shaders now:

kerbal-space-program/556 adds a useless max(x, 0) on top of a sat(),
which will obviously be handled by a later patch in this series.

In natural-selection-2/757 (and presumably 13093 and 13096), two
consecutive assignments' RHS contained (x * (y * z)) and (w * (y * z))
allowing the i965 backend to CSE the y*z. After this patch for some
reason we get ((x * y) * z) and ((w * y) * z) which means we gain one
multiply instruction. Not concerned about that.

unity/42 and 62 (which are now available to you in the open
shader-db!) are also regressed. I looked at 42, but it's really hard
to tell what's going on. In fact, parts of it look like they should be
improved (we recognize lrp in a few new places). They're actually
still hurt after the series through patch 19 (I haven't tested the
later ones). They'd be interesting for you to look at.

Actually, looking at the results for just this patch, I see a bunch of
CSGO & Dota2 shaders around 30 instructions that are cut by about 15%
that I cannot explain. The change in IR doesn't look legal. It might
be exposing a bug elsewhere. I'll have to take a look. :(