[Mesa-dev] [PATCH] i965: Use NIR by default for vertex shaders on GEN8+

[Jason Ekstrand]

On Thu, May 7, 2015 at 8:49 PM, Jason Ekstrand <jason at jlekstrand.net> wrote:
> On Thu, May 7, 2015 at 6:17 PM, Matt Turner <mattst88 at gmail.com> wrote:
>> On Thu, May 7, 2015 at 4:50 PM, Jason Ekstrand <jason at jlekstrand.net> wrote:
>>> GLSL IR vs. NIR shader-db results for SIMD8 vertex shaders on Broadwell:
>>>
>>>    total instructions in shared programs: 2724483 -> 2711790 (-0.47%)
>>>    instructions in affected programs:     1860859 -> 1848166 (-0.68%)
>>>    helped:                                4387
>>>    HURT:                                  4758
>>>    GAINED:                                1499
>>>
>>> The gained programs are ARB vertext programs that were previously going
>>> through the vec4 backend.  Now that we have prog_to_nir, ARB vertex
>>> programs can go through the scalar backend so they show up as "gained" in
>>> the shader-db results.
>>
>> Again, I'm kind of confused and disappointed that we're just okay with
>> hurting 4700 programs without more analysis. I guess I'll go do
>> that...
>>
>> I'm concerned -- lots of shaders like left-4-dead-2/low/3699 go from
>> 297 -> 161 instructions. More concerning, the number of send
>> instructions drop from 36 to 12, and a loop that was 111 instructions
>> long suddenly becomes
>>
>>    START B1 <-B0 <-B2
>> cmp.ge.f0(8)    null            g42<8,8,1>D     g7<0,1,0>D
>> (+f0) break(8)  JIP: 24         UIP: 24
>>    END B1 ->B3 ->B2
>>    START B2 <-B1
>> add(8)          g42<1>D         g42<8,8,1>D     1D
>> while(8)        JIP: -32
>>    END B2 ->B1
>>
>> That deserves a lot more investigation. I'll take a gamble and say
>> something is broken.
>
> I did a little looking at that shader and it looks like NIR dead-coded
> the contents of a for loop and, as a result, a bunch of stuff was
> promoted to push constants, hence fewer sampler messages.  I didn't
> find anything broken but, then again, that's hard to do without being
> able to verifiably run the shader.  I'll try and look at the places
> where we end up with more instructions.
> --Jason

Looking at the assembly even closer, it looks like NIR did 100% the
right thing.  The shader had a for loop that computes a bunch of
values that either don't get used at all or are over-written before
they are used.  (I didn't check every value written in the loop but I
did check a good half-dozen or so.)  NIR, probably thanks to SSA,
realized that these values were never used for anything, and
dead-coded the entire contents of the for loop.  The result was that
the 12 (yes, 12) pull constant loads inside the loop went away and the
9 after the loop were promoted to push constants.  Unfortunately, NIR
isn't yet smart enough to remove the loop entirely but an empty loop
isn't nearly as expensive as sampler invocations so I'm not too
worried about it.

I'll try and take a look at some of the hurt programs tomorrow.
--Jason