[Mesa-dev] [PATCH] nir/search: Save/restore the variables_seen bitmask when matching

Jason Ekstrand jason at jlekstrand.net
Fri May 8 16:01:53 PDT 2015


On Fri, May 8, 2015 at 3:32 PM, Ian Romanick <idr at freedesktop.org> wrote:
> On 05/08/2015 03:31 PM, Ian Romanick wrote:
>> On 05/08/2015 03:25 PM, Jason Ekstrand wrote:
>>> On Fri, May 8, 2015 at 3:20 PM, Ian Romanick <idr at freedesktop.org> wrote:
>>>> On 05/08/2015 11:55 AM, Jason Ekstrand wrote:
>>>>> On Fri, May 8, 2015 at 11:53 AM, Jason Ekstrand <jason at jlekstrand.net> wrote:
>>>>>> total instructions in shared programs: 7152330 -> 7137006 (-0.21%)
>>>>>> instructions in affected programs:     1330548 -> 1315224 (-1.15%)
>>>>>> helped:                                5797
>>>>>> HURT:                                  76
>>>>>
>>>>> I'm doing some looking into the hurt programs.  It seems as if there
>>>>> are some very strange interatctions between flrp and ffma.  I'm still
>>>>> working out exactly how to fix it up.
>>>>
>>>> Yes, I noticed this too.  Did you see my reply to Ken earlier today?
>>>> The problem I noticed /seems/ restricted to cases where the would-be
>>>> interpolant is scalar but the other values are vector.
>>>
>>> It would surprise me a lot of that mattered.  At the point where we do
>>> opt_algebraic in NIR, we've already scalarized things.  That said,
>>> there is a *lot* going on in an optimization loop so anything's
>>> possible.
>>
>> If I take the shader_runner test that I included in the e-mail to Ken
>> and s/float alpha/vec3 alpha/ I get LRPs.  I made some obvious tweaks to
>> opt_algebraic to handle the mix of scalar and vector, and something like
>> 150 shaders were helped.

Ok, that's weird.  I really have no idea why that would make a
difference.  Unless, of course, it affects the optimizations that GLSL
IR is able to do which then, in turn, affects NIR.  That would make
some sense.

>> I spent about an hour digging into it, and I came up dry.  I have tried
>> adding some rules to nir_opt_algebraic.py to convert the fmul/ffma to
>> flrp, and I couldn't get a break point at the nir_opt_ffma to trigger.
>> I was going to ask about it at the office on Monday, but it came up on
>> the list first.
>
> FWIW, those rules were:
>
>    (('ffma', b, c, ('fmul', a, ('fadd', 1.0, ('fneg', c)))), ('flrp', a, b, c), '!options->lower_flrp'),
>    (('ffma', c, b, ('fmul', a, ('fadd', 1.0, ('fneg', c)))), ('flrp', a, b, c), '!options->lower_flrp'),

Did you add them to optimizations or late_optimizations?  The late
ones get run after opt_ffma and the others don't.

I poked around for an hour or two today with similar optimizations (I
actually had 6) but I wasn't able to get it to do any better.
--Jason


More information about the mesa-dev mailing list