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

2015-05-16 Thread Matt Turner 
On Sat, May 16, 2015 at 1:07 PM, Jason Ekstrand  wrote:
> I found a variety of places where the user was doing, for instance, 2
> muls and 4 adds where the result of each mul is used twice.  The
> result is 6 instructions instead of just the 4 mad's.  It's entirely
> possible that, thanks to latancies, the 6 would actually be better,
> but that's why I did it that way.

So there's probably a threshold. Certainly one multiply used by six
adds is over that threshold.

I'll do some experiments.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

2015-05-16 Thread Jason Ekstrand 
On Sat, May 16, 2015 at 1:01 PM, Jason Ekstrand  wrote:
> On Sat, May 16, 2015 at 12:59 PM, Matt Turner  wrote:
>> On Sat, May 16, 2015 at 12:45 PM, Jason Ekstrand  
>> wrote:
>>> On Sat, May 16, 2015 at 12:12 PM, Matt Turner  wrote:
 On Fri, May 8, 2015 at 3:27 AM, Kenneth Graunke  
 wrote:
> Looking at a couple of the shaders that are still worse off...it looks
> like a ton of Source shaders used to do MUL/ADD with an attribute and
> two immediates, and now are doing MOV/MOV/MAD.

 I just looked, and thought that too for a minute, but it actually
 shouldn't be doing that. Take for instance:

 shaders/closed/steam/dota-2/498.shader_test VS SIMD8: 47 -> 53 (12.77%)

 It indeed replaces 6x MUL/ADD pairs with MOV/MAD (introducing 6 extra
 MOVs), but

 Without NIR we have

 mul(8)  g15<1>F g6<8,8,1>F  6F
 ...
 add(8)  g16<1>F g15<8,8,1>F 2.1F
 add(8)  g35<1>F g15<8,8,1>F 3.1F
 add(8)  g42<1>F g15<8,8,1>F 4.1F
 add(8)  g45<1>F g15<8,8,1>F 5.1F
 add(8)  g48<1>F g15<8,8,1>F 0.1F
 add(8)  g51<1>F g15<8,8,1>F 1.1F

 That is, one multiply is consumed by 6 adds.

 With NIR we have

 mov(1)  g22<1>F 2.1F
 mov(1)  g22.1<1>F   6F
 mad(8)  g16<1>F g22<0,1,0>.xF   g22.1<0,1,0>.xF g6<4,4,1>F
 mov(1)  g22.2<1>F   3.1F
 mad(8)  g23<1>F g22.2<0,1,0>.xF g22.1<0,1,0>.xF g6<4,4,1>F
 mov(1)  g22.3<1>F   4.1F
 mad(8)  g30<1>F g22.3<0,1,0>.xF g22.1<0,1,0>.xF g6<4,4,1>F
 mov(1)  g22.4<1>F   5.1F
 mad(8)  g33<1>F g22.4<0,1,0>.xF g22.1<0,1,0>.xF g6<4,4,1>F
 mov(1)  g22.5<1>F   0.1F
 mad(8)  g36<1>F g22.5<0,1,0>.xF g22.1<0,1,0>.xF g6<4,4,1>F
 mov(1)  g22.6<1>F   1.1F
 mad(8)  g39<1>F g22.6<0,1,0>.xF g22.1<0,1,0>.xF g6<4,4,1>F

 So we're doing the g6 * 6F operation 6 times! We see this in the NIR as 
 well:

 vec1 ssa_419 = ffma ssa_384, ssa_132, ssa_133
 vec1 ssa_423 = ffma ssa_384, ssa_132, ssa_135
 vec1 ssa_427 = ffma ssa_384, ssa_132, ssa_137
 vec1 ssa_428 = ffma ssa_384, ssa_132, ssa_139
 vec1 ssa_429 = ffma ssa_384, ssa_132, ssa_141
 vec1 ssa_430 = ffma ssa_384, ssa_132, ssa_144

 Whoops. Ideas for fixing that? I'm guessing that this accounts for
 nearly all of the remaining 1120 hurt programs.
>>>
>>> Ugh... We've been tacitly assuming that your constant combine stuff
>>> will magically make immediates not a problem.  In this case, they are
>>> a problem.  I guess we could do something different for 1 vs. 2
>>> immediates.
>>
>> That's not really the problem as far as I see. I mean, we could split
>> MADs that do x * imm + imm, but I would think NIR shouldn't be
>> combining these operations if the multiply is used in a bunch of
>> places.
>>
>> The current code in the ffma peephole in does... to quote the comment:
>>
>>   /* Only absorb a fmul into a ffma if the fmul is is only used in fadd
>>* operations.  This prevents us from being too aggressive with our
>>* fusing which can actually lead to more instructions.
>>*/
>>
>> Can't we pretty trivially modify that to count the number of uses as
>> well and only combine if it's used in one place?
>>
>> To be honest, before I looked in the code I thought that's what it was doing.
>
> If you want to know why I did it that way, just run shader-db. :-)

Ok, longer less snarky version:

I found a variety of places where the user was doing, for instance, 2
muls and 4 adds where the result of each mul is used twice.  The
result is 6 instructions instead of just the 4 mad's.  It's entirely
possible that, thanks to latancies, the 6 would actually be better,
but that's why I did it that way.
--Jason
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

2015-05-16 Thread Jason Ekstrand 
On Sat, May 16, 2015 at 12:59 PM, Matt Turner  wrote:
> On Sat, May 16, 2015 at 12:45 PM, Jason Ekstrand  wrote:
>> On Sat, May 16, 2015 at 12:12 PM, Matt Turner  wrote:
>>> On Fri, May 8, 2015 at 3:27 AM, Kenneth Graunke  
>>> wrote:
 Looking at a couple of the shaders that are still worse off...it looks
 like a ton of Source shaders used to do MUL/ADD with an attribute and
 two immediates, and now are doing MOV/MOV/MAD.
>>>
>>> I just looked, and thought that too for a minute, but it actually
>>> shouldn't be doing that. Take for instance:
>>>
>>> shaders/closed/steam/dota-2/498.shader_test VS SIMD8: 47 -> 53 (12.77%)
>>>
>>> It indeed replaces 6x MUL/ADD pairs with MOV/MAD (introducing 6 extra
>>> MOVs), but
>>>
>>> Without NIR we have
>>>
>>> mul(8)  g15<1>F g6<8,8,1>F  6F
>>> ...
>>> add(8)  g16<1>F g15<8,8,1>F 2.1F
>>> add(8)  g35<1>F g15<8,8,1>F 3.1F
>>> add(8)  g42<1>F g15<8,8,1>F 4.1F
>>> add(8)  g45<1>F g15<8,8,1>F 5.1F
>>> add(8)  g48<1>F g15<8,8,1>F 0.1F
>>> add(8)  g51<1>F g15<8,8,1>F 1.1F
>>>
>>> That is, one multiply is consumed by 6 adds.
>>>
>>> With NIR we have
>>>
>>> mov(1)  g22<1>F 2.1F
>>> mov(1)  g22.1<1>F   6F
>>> mad(8)  g16<1>F g22<0,1,0>.xF   g22.1<0,1,0>.xF g6<4,4,1>F
>>> mov(1)  g22.2<1>F   3.1F
>>> mad(8)  g23<1>F g22.2<0,1,0>.xF g22.1<0,1,0>.xF g6<4,4,1>F
>>> mov(1)  g22.3<1>F   4.1F
>>> mad(8)  g30<1>F g22.3<0,1,0>.xF g22.1<0,1,0>.xF g6<4,4,1>F
>>> mov(1)  g22.4<1>F   5.1F
>>> mad(8)  g33<1>F g22.4<0,1,0>.xF g22.1<0,1,0>.xF g6<4,4,1>F
>>> mov(1)  g22.5<1>F   0.1F
>>> mad(8)  g36<1>F g22.5<0,1,0>.xF g22.1<0,1,0>.xF g6<4,4,1>F
>>> mov(1)  g22.6<1>F   1.1F
>>> mad(8)  g39<1>F g22.6<0,1,0>.xF g22.1<0,1,0>.xF g6<4,4,1>F
>>>
>>> So we're doing the g6 * 6F operation 6 times! We see this in the NIR as 
>>> well:
>>>
>>> vec1 ssa_419 = ffma ssa_384, ssa_132, ssa_133
>>> vec1 ssa_423 = ffma ssa_384, ssa_132, ssa_135
>>> vec1 ssa_427 = ffma ssa_384, ssa_132, ssa_137
>>> vec1 ssa_428 = ffma ssa_384, ssa_132, ssa_139
>>> vec1 ssa_429 = ffma ssa_384, ssa_132, ssa_141
>>> vec1 ssa_430 = ffma ssa_384, ssa_132, ssa_144
>>>
>>> Whoops. Ideas for fixing that? I'm guessing that this accounts for
>>> nearly all of the remaining 1120 hurt programs.
>>
>> Ugh... We've been tacitly assuming that your constant combine stuff
>> will magically make immediates not a problem.  In this case, they are
>> a problem.  I guess we could do something different for 1 vs. 2
>> immediates.
>
> That's not really the problem as far as I see. I mean, we could split
> MADs that do x * imm + imm, but I would think NIR shouldn't be
> combining these operations if the multiply is used in a bunch of
> places.
>
> The current code in the ffma peephole in does... to quote the comment:
>
>   /* Only absorb a fmul into a ffma if the fmul is is only used in fadd
>* operations.  This prevents us from being too aggressive with our
>* fusing which can actually lead to more instructions.
>*/
>
> Can't we pretty trivially modify that to count the number of uses as
> well and only combine if it's used in one place?
>
> To be honest, before I looked in the code I thought that's what it was doing.

If you want to know why I did it that way, just run shader-db. :-)
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

2015-05-16 Thread Matt Turner 
On Sat, May 16, 2015 at 12:45 PM, Jason Ekstrand  wrote:
> On Sat, May 16, 2015 at 12:12 PM, Matt Turner  wrote:
>> On Fri, May 8, 2015 at 3:27 AM, Kenneth Graunke  
>> wrote:
>>> Looking at a couple of the shaders that are still worse off...it looks
>>> like a ton of Source shaders used to do MUL/ADD with an attribute and
>>> two immediates, and now are doing MOV/MOV/MAD.
>>
>> I just looked, and thought that too for a minute, but it actually
>> shouldn't be doing that. Take for instance:
>>
>> shaders/closed/steam/dota-2/498.shader_test VS SIMD8: 47 -> 53 (12.77%)
>>
>> It indeed replaces 6x MUL/ADD pairs with MOV/MAD (introducing 6 extra
>> MOVs), but
>>
>> Without NIR we have
>>
>> mul(8)  g15<1>F g6<8,8,1>F  6F
>> ...
>> add(8)  g16<1>F g15<8,8,1>F 2.1F
>> add(8)  g35<1>F g15<8,8,1>F 3.1F
>> add(8)  g42<1>F g15<8,8,1>F 4.1F
>> add(8)  g45<1>F g15<8,8,1>F 5.1F
>> add(8)  g48<1>F g15<8,8,1>F 0.1F
>> add(8)  g51<1>F g15<8,8,1>F 1.1F
>>
>> That is, one multiply is consumed by 6 adds.
>>
>> With NIR we have
>>
>> mov(1)  g22<1>F 2.1F
>> mov(1)  g22.1<1>F   6F
>> mad(8)  g16<1>F g22<0,1,0>.xF   g22.1<0,1,0>.xF g6<4,4,1>F
>> mov(1)  g22.2<1>F   3.1F
>> mad(8)  g23<1>F g22.2<0,1,0>.xF g22.1<0,1,0>.xF g6<4,4,1>F
>> mov(1)  g22.3<1>F   4.1F
>> mad(8)  g30<1>F g22.3<0,1,0>.xF g22.1<0,1,0>.xF g6<4,4,1>F
>> mov(1)  g22.4<1>F   5.1F
>> mad(8)  g33<1>F g22.4<0,1,0>.xF g22.1<0,1,0>.xF g6<4,4,1>F
>> mov(1)  g22.5<1>F   0.1F
>> mad(8)  g36<1>F g22.5<0,1,0>.xF g22.1<0,1,0>.xF g6<4,4,1>F
>> mov(1)  g22.6<1>F   1.1F
>> mad(8)  g39<1>F g22.6<0,1,0>.xF g22.1<0,1,0>.xF g6<4,4,1>F
>>
>> So we're doing the g6 * 6F operation 6 times! We see this in the NIR as well:
>>
>> vec1 ssa_419 = ffma ssa_384, ssa_132, ssa_133
>> vec1 ssa_423 = ffma ssa_384, ssa_132, ssa_135
>> vec1 ssa_427 = ffma ssa_384, ssa_132, ssa_137
>> vec1 ssa_428 = ffma ssa_384, ssa_132, ssa_139
>> vec1 ssa_429 = ffma ssa_384, ssa_132, ssa_141
>> vec1 ssa_430 = ffma ssa_384, ssa_132, ssa_144
>>
>> Whoops. Ideas for fixing that? I'm guessing that this accounts for
>> nearly all of the remaining 1120 hurt programs.
>
> Ugh... We've been tacitly assuming that your constant combine stuff
> will magically make immediates not a problem.  In this case, they are
> a problem.  I guess we could do something different for 1 vs. 2
> immediates.

That's not really the problem as far as I see. I mean, we could split
MADs that do x * imm + imm, but I would think NIR shouldn't be
combining these operations if the multiply is used in a bunch of
places.

The current code in the ffma peephole in does... to quote the comment:

  /* Only absorb a fmul into a ffma if the fmul is is only used in fadd
   * operations.  This prevents us from being too aggressive with our
   * fusing which can actually lead to more instructions.
   */

Can't we pretty trivially modify that to count the number of uses as
well and only combine if it's used in one place?

To be honest, before I looked in the code I thought that's what it was doing.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

2015-05-16 Thread Jason Ekstrand 
On Sat, May 16, 2015 at 12:12 PM, Matt Turner  wrote:
> On Fri, May 8, 2015 at 3:27 AM, Kenneth Graunke  wrote:
>> Looking at a couple of the shaders that are still worse off...it looks
>> like a ton of Source shaders used to do MUL/ADD with an attribute and
>> two immediates, and now are doing MOV/MOV/MAD.
>
> I just looked, and thought that too for a minute, but it actually
> shouldn't be doing that. Take for instance:
>
> shaders/closed/steam/dota-2/498.shader_test VS SIMD8: 47 -> 53 (12.77%)
>
> It indeed replaces 6x MUL/ADD pairs with MOV/MAD (introducing 6 extra
> MOVs), but
>
> Without NIR we have
>
> mul(8)  g15<1>F g6<8,8,1>F  6F
> ...
> add(8)  g16<1>F g15<8,8,1>F 2.1F
> add(8)  g35<1>F g15<8,8,1>F 3.1F
> add(8)  g42<1>F g15<8,8,1>F 4.1F
> add(8)  g45<1>F g15<8,8,1>F 5.1F
> add(8)  g48<1>F g15<8,8,1>F 0.1F
> add(8)  g51<1>F g15<8,8,1>F 1.1F
>
> That is, one multiply is consumed by 6 adds.
>
> With NIR we have
>
> mov(1)  g22<1>F 2.1F
> mov(1)  g22.1<1>F   6F
> mad(8)  g16<1>F g22<0,1,0>.xF   g22.1<0,1,0>.xF g6<4,4,1>F
> mov(1)  g22.2<1>F   3.1F
> mad(8)  g23<1>F g22.2<0,1,0>.xF g22.1<0,1,0>.xF g6<4,4,1>F
> mov(1)  g22.3<1>F   4.1F
> mad(8)  g30<1>F g22.3<0,1,0>.xF g22.1<0,1,0>.xF g6<4,4,1>F
> mov(1)  g22.4<1>F   5.1F
> mad(8)  g33<1>F g22.4<0,1,0>.xF g22.1<0,1,0>.xF g6<4,4,1>F
> mov(1)  g22.5<1>F   0.1F
> mad(8)  g36<1>F g22.5<0,1,0>.xF g22.1<0,1,0>.xF g6<4,4,1>F
> mov(1)  g22.6<1>F   1.1F
> mad(8)  g39<1>F g22.6<0,1,0>.xF g22.1<0,1,0>.xF g6<4,4,1>F
>
> So we're doing the g6 * 6F operation 6 times! We see this in the NIR as well:
>
> vec1 ssa_419 = ffma ssa_384, ssa_132, ssa_133
> vec1 ssa_423 = ffma ssa_384, ssa_132, ssa_135
> vec1 ssa_427 = ffma ssa_384, ssa_132, ssa_137
> vec1 ssa_428 = ffma ssa_384, ssa_132, ssa_139
> vec1 ssa_429 = ffma ssa_384, ssa_132, ssa_141
> vec1 ssa_430 = ffma ssa_384, ssa_132, ssa_144
>
> Whoops. Ideas for fixing that? I'm guessing that this accounts for
> nearly all of the remaining 1120 hurt programs.

Ugh... We've been tacitly assuming that your constant combine stuff
will magically make immediates not a problem.  In this case, they are
a problem.  I guess we could do something different for 1 vs. 2
immediates.
--Jason
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

2015-05-16 Thread Ilia Mirkin 
On Sat, May 16, 2015 at 3:12 PM, Matt Turner  wrote:
> On Fri, May 8, 2015 at 3:27 AM, Kenneth Graunke  wrote:
>> Looking at a couple of the shaders that are still worse off...it looks
>> like a ton of Source shaders used to do MUL/ADD with an attribute and
>> two immediates, and now are doing MOV/MOV/MAD.
>
> I just looked, and thought that too for a minute, but it actually
> shouldn't be doing that. Take for instance:
>
> shaders/closed/steam/dota-2/498.shader_test VS SIMD8: 47 -> 53 (12.77%)
>
> It indeed replaces 6x MUL/ADD pairs with MOV/MAD (introducing 6 extra
> MOVs), but
>
> Without NIR we have
>
> mul(8)  g15<1>F g6<8,8,1>F  6F
> ...
> add(8)  g16<1>F g15<8,8,1>F 2.1F
> add(8)  g35<1>F g15<8,8,1>F 3.1F
> add(8)  g42<1>F g15<8,8,1>F 4.1F
> add(8)  g45<1>F g15<8,8,1>F 5.1F
> add(8)  g48<1>F g15<8,8,1>F 0.1F
> add(8)  g51<1>F g15<8,8,1>F 1.1F
>
> That is, one multiply is consumed by 6 adds.
>
> With NIR we have
>
> mov(1)  g22<1>F 2.1F
> mov(1)  g22.1<1>F   6F
> mad(8)  g16<1>F g22<0,1,0>.xF   g22.1<0,1,0>.xF g6<4,4,1>F
> mov(1)  g22.2<1>F   3.1F
> mad(8)  g23<1>F g22.2<0,1,0>.xF g22.1<0,1,0>.xF g6<4,4,1>F
> mov(1)  g22.3<1>F   4.1F
> mad(8)  g30<1>F g22.3<0,1,0>.xF g22.1<0,1,0>.xF g6<4,4,1>F
> mov(1)  g22.4<1>F   5.1F
> mad(8)  g33<1>F g22.4<0,1,0>.xF g22.1<0,1,0>.xF g6<4,4,1>F
> mov(1)  g22.5<1>F   0.1F
> mad(8)  g36<1>F g22.5<0,1,0>.xF g22.1<0,1,0>.xF g6<4,4,1>F
> mov(1)  g22.6<1>F   1.1F
> mad(8)  g39<1>F g22.6<0,1,0>.xF g22.1<0,1,0>.xF g6<4,4,1>F
>
> So we're doing the g6 * 6F operation 6 times! We see this in the NIR as well:
>
> vec1 ssa_419 = ffma ssa_384, ssa_132, ssa_133
> vec1 ssa_423 = ffma ssa_384, ssa_132, ssa_135
> vec1 ssa_427 = ffma ssa_384, ssa_132, ssa_137
> vec1 ssa_428 = ffma ssa_384, ssa_132, ssa_139
> vec1 ssa_429 = ffma ssa_384, ssa_132, ssa_141
> vec1 ssa_430 = ffma ssa_384, ssa_132, ssa_144
>
> Whoops. Ideas for fixing that? I'm guessing that this accounts for
> nearly all of the remaining 1120 hurt programs.

How did those become fma's in the first place? On nouveau, we only do
mul + add -> fma if that is the only use of the mul. Otherwise we
leave them alone.

Cheers,

  -ilia
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

2015-05-16 Thread Matt Turner 
On Fri, May 8, 2015 at 3:27 AM, Kenneth Graunke  wrote:
> Looking at a couple of the shaders that are still worse off...it looks
> like a ton of Source shaders used to do MUL/ADD with an attribute and
> two immediates, and now are doing MOV/MOV/MAD.

I just looked, and thought that too for a minute, but it actually
shouldn't be doing that. Take for instance:

shaders/closed/steam/dota-2/498.shader_test VS SIMD8: 47 -> 53 (12.77%)

It indeed replaces 6x MUL/ADD pairs with MOV/MAD (introducing 6 extra
MOVs), but

Without NIR we have

mul(8)  g15<1>F g6<8,8,1>F  6F
...
add(8)  g16<1>F g15<8,8,1>F 2.1F
add(8)  g35<1>F g15<8,8,1>F 3.1F
add(8)  g42<1>F g15<8,8,1>F 4.1F
add(8)  g45<1>F g15<8,8,1>F 5.1F
add(8)  g48<1>F g15<8,8,1>F 0.1F
add(8)  g51<1>F g15<8,8,1>F 1.1F

That is, one multiply is consumed by 6 adds.

With NIR we have

mov(1)  g22<1>F 2.1F
mov(1)  g22.1<1>F   6F
mad(8)  g16<1>F g22<0,1,0>.xF   g22.1<0,1,0>.xF g6<4,4,1>F
mov(1)  g22.2<1>F   3.1F
mad(8)  g23<1>F g22.2<0,1,0>.xF g22.1<0,1,0>.xF g6<4,4,1>F
mov(1)  g22.3<1>F   4.1F
mad(8)  g30<1>F g22.3<0,1,0>.xF g22.1<0,1,0>.xF g6<4,4,1>F
mov(1)  g22.4<1>F   5.1F
mad(8)  g33<1>F g22.4<0,1,0>.xF g22.1<0,1,0>.xF g6<4,4,1>F
mov(1)  g22.5<1>F   0.1F
mad(8)  g36<1>F g22.5<0,1,0>.xF g22.1<0,1,0>.xF g6<4,4,1>F
mov(1)  g22.6<1>F   1.1F
mad(8)  g39<1>F g22.6<0,1,0>.xF g22.1<0,1,0>.xF g6<4,4,1>F

So we're doing the g6 * 6F operation 6 times! We see this in the NIR as well:

vec1 ssa_419 = ffma ssa_384, ssa_132, ssa_133
vec1 ssa_423 = ffma ssa_384, ssa_132, ssa_135
vec1 ssa_427 = ffma ssa_384, ssa_132, ssa_137
vec1 ssa_428 = ffma ssa_384, ssa_132, ssa_139
vec1 ssa_429 = ffma ssa_384, ssa_132, ssa_141
vec1 ssa_430 = ffma ssa_384, ssa_132, ssa_144

Whoops. Ideas for fixing that? I'm guessing that this accounts for
nearly all of the remaining 1120 hurt programs.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

2015-05-08 Thread Matt Turner 
On Fri, May 8, 2015 at 10:08 AM, Jason Ekstrand  wrote:
> On Fri, May 8, 2015 at 3:27 AM, Kenneth Graunke  wrote:
>> On Thursday, May 07, 2015 06:17:46 PM Matt Turner wrote:
>>> On Thu, May 7, 2015 at 4:50 PM, Jason Ekstrand  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 took a stab at that tonight.  The good news is, the majority of the
>> hurt is pretty stupid.  Indirect uniform address calculations involve
>> a lot of integer multiplication by 4.
>>
>> For whatever reason, we're getting 4*x instead of x*4, which doesn't
>> support immediates.  So we get:
>>
>> MOV tmp 4
>> MUL dst tmp x
>>
>> Normally, constant propagation would commute the operands, giving us
>> "MUL dst x 4" like we want.  But it sees integer multiplication and
>> chickens out, due to the asymmetry on some platforms.
>
> Right.  I just sent out a patch that puts immediates in src1 for
> commutative ALU ops at the emit stage.  We probably still want to do
> something in constant propagation in case we can fold something, but
> it fixes the problem for now.  It also helps even more than the
> shifting patch.
>
> I don't know.  Maybe we just want to make constant propagation do the
> right thing on BDW+.  Matt?

Yes.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

2015-05-08 Thread Jason Ekstrand 
On Fri, May 8, 2015 at 3:27 AM, Kenneth Graunke  wrote:
> On Thursday, May 07, 2015 06:17:46 PM Matt Turner wrote:
>> On Thu, May 7, 2015 at 4:50 PM, Jason Ekstrand  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 took a stab at that tonight.  The good news is, the majority of the
> hurt is pretty stupid.  Indirect uniform address calculations involve
> a lot of integer multiplication by 4.
>
> For whatever reason, we're getting 4*x instead of x*4, which doesn't
> support immediates.  So we get:
>
> MOV tmp 4
> MUL dst tmp x
>
> Normally, constant propagation would commute the operands, giving us
> "MUL dst x 4" like we want.  But it sees integer multiplication and
> chickens out, due to the asymmetry on some platforms.

Right.  I just sent out a patch that puts immediates in src1 for
commutative ALU ops at the emit stage.  We probably still want to do
something in constant propagation in case we can fold something, but
it fixes the problem for now.  It also helps even more than the
shifting patch.

I don't know.  Maybe we just want to make constant propagation do the
right thing on BDW+.  Matt?
--jason

> I think we can extend that - on Broadwell it should work fine, and
> might work fine for 16-bit immediates on Gen7 and Cherryview, too.
>
> Alternatively, I wrote a nir_opt_algebraic_late optimization that turns
> 4*x into x << 2, which works around the problem, and is also apparently
> much better for R600.
>
> Statistics on the shift patch are:
>
> total instructions in shared programs: 7432587 -> 7388982 (-0.59%)
> instructions in affected programs: 1360411 -> 1316806 (-3.21%)
> helped:5772
> HURT:  0
>
> Statistics for GLSL IR vs. NIR+(4*x => x << 2):
>
> total instructions in shared programs: 7232451 -> 7175983 (-0.78%)
> instructions in affected programs: 1586917 -> 1530449 (-3.56%)
> helped:5780
> HURT:  1654
>
> which is much better.
>
> Looking at a couple of the shaders that are still worse off...it looks
> like a ton of Source shaders used to do MUL/ADD with an attribute and
> two immediates, and now are doing MOV/MOV/MAD.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

2015-05-08 Thread Kenneth Graunke 
On Thursday, May 07, 2015 06:17:46 PM Matt Turner wrote:
> On Thu, May 7, 2015 at 4:50 PM, Jason Ekstrand  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 took a stab at that tonight.  The good news is, the majority of the
hurt is pretty stupid.  Indirect uniform address calculations involve
a lot of integer multiplication by 4.

For whatever reason, we're getting 4*x instead of x*4, which doesn't
support immediates.  So we get:

MOV tmp 4
MUL dst tmp x

Normally, constant propagation would commute the operands, giving us
"MUL dst x 4" like we want.  But it sees integer multiplication and
chickens out, due to the asymmetry on some platforms.

I think we can extend that - on Broadwell it should work fine, and
might work fine for 16-bit immediates on Gen7 and Cherryview, too.

Alternatively, I wrote a nir_opt_algebraic_late optimization that turns
4*x into x << 2, which works around the problem, and is also apparently
much better for R600.

Statistics on the shift patch are:

total instructions in shared programs: 7432587 -> 7388982 (-0.59%)
instructions in affected programs: 1360411 -> 1316806 (-3.21%)
helped:5772
HURT:  0

Statistics for GLSL IR vs. NIR+(4*x => x << 2):

total instructions in shared programs: 7232451 -> 7175983 (-0.78%)
instructions in affected programs: 1586917 -> 1530449 (-3.56%)
helped:5780
HURT:  1654

which is much better.

Looking at a couple of the shaders that are still worse off...it looks
like a ton of Source shaders used to do MUL/ADD with an attribute and
two immediates, and now are doing MOV/MOV/MAD.


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

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

2015-05-07 Thread Jason Ekstrand 
On Thu, May 7, 2015 at 8:49 PM, Jason Ekstrand  wrote:
> On Thu, May 7, 2015 at 6:17 PM, Matt Turner  wrote:
>> On Thu, May 7, 2015 at 4:50 PM, Jason Ekstrand  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)nullg42<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
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

2015-05-07 Thread Jason Ekstrand 
On Thu, May 7, 2015 at 6:17 PM, Matt Turner  wrote:
> On Thu, May 7, 2015 at 4:50 PM, Jason Ekstrand  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)nullg42<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
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

2015-05-07 Thread Jason Ekstrand 
On Thu, May 7, 2015 at 6:17 PM, Matt Turner  wrote:
> On Thu, May 7, 2015 at 4:50 PM, Jason Ekstrand  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...

What confuses me more is why the results aren't better.  When we first
turned NIR on by default for FS, the shader-db results looked a lot
better.  On one branch (wip/nir-by-default-v2) I applied the ATTR
copy-prop and we had the following:

GLSL IR vs. NIR shader-db results on Broadwell (VS only):

   total instructions in shared programs: 7106293 -> 7001640 (-1.47%)
   instructions in affected programs: 4604798 -> 4500145 (-2.27%)
   helped:16786
   HURT:  8442
   GAINED:1563
   LOST:  1526

The difference between gained/lost was due to capturing standard
error.  However, that shouldn't  affect the over-all numbers that
much.  I think adding the improved ffma stuff probably made a bunch of
the difference.

As far as when we turn it on, I do think that we want to do it before
the merge window closes if we can.  Being able to delete the visitor
after the branch would be really nice.  Also, we want to get people
testing it and reporting bugs because we're not going to find every
bug in every vertex shader  by inspection.

> 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)nullg42<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.

Yes, that needs some investigation.  I can also take a look at some of
the hurt and/or really helped shaders as well and see what I find.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

2015-05-07 Thread Ian Romanick 
On 05/07/2015 06:17 PM, Matt Turner wrote:
> On Thu, May 7, 2015 at 4:50 PM, Jason Ekstrand  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...

Yeah... I think I just (foolishly) assumed it was mostly +/- small
amounts given the % in affected programs.

> 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)nullg42<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.

Yikes.  I guess I'm surprised that piglit+gles3conform+deqp didn't
already find

> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

2015-05-07 Thread Matt Turner 
On Thu, May 7, 2015 at 4:50 PM, Jason Ekstrand  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)nullg42<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.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

2015-05-07 Thread Ian Romanick 
On 05/07/2015 05:44 PM, Jason Ekstrand wrote:
> 
> On May 7, 2015 5:38 PM, "Ian Romanick"  > wrote:
>>
>> On 05/07/2015 04:50 PM, Jason Ekstrand 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.
>>
>> I thought we already did this... why didn't this happen when NIR became
>> the default for the FS backend?  And has that reason (assuming there was
>> one) been resolved?
> 
> We couldn't do copy propagation of values in the attribute register
> file.  That, it turn was blocked on reworking the LOAD_PAYLOAD
> instruction.  I pushed a series this morning that fixed both of those
> and cut 7.5% off of all SIMD8 VS instructions when using NIR.  It also
> helps GLSL IR but by only 1% or so.
> --Jason

Ah, that's right.  Make it so!

Reviewed-by: Ian Romanick 

>> > ---
>> >  src/mesa/drivers/dri/i965/brw_context.c | 2 +-
>> >  1 file changed, 1 insertion(+), 1 deletion(-)
>> >
>> > diff --git a/src/mesa/drivers/dri/i965/brw_context.c
> b/src/mesa/drivers/dri/i965/brw_context.c
>> > index fd7420a..8615e5e 100644
>> > --- a/src/mesa/drivers/dri/i965/brw_context.c
>> > +++ b/src/mesa/drivers/dri/i965/brw_context.c
>> > @@ -588,7 +588,7 @@ brw_initialize_context_constants(struct
> brw_context *brw)
>> >   
> ctx->Const.ShaderCompilerOptions[MESA_SHADER_VERTEX].EmitNoIndirectTemp
> = true;
>> >   
> ctx->Const.ShaderCompilerOptions[MESA_SHADER_VERTEX].OptimizeForAOS = false;
>> >
>> > -  if (brw_env_var_as_boolean("INTEL_USE_NIR", false))
>> > +  if (brw_env_var_as_boolean("INTEL_USE_NIR", true))
>> > 
>  ctx->Const.ShaderCompilerOptions[MESA_SHADER_VERTEX].NirOptions =
> &nir_options;
>> > }
>> >
>>

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

2015-05-07 Thread Jason Ekstrand 
On May 7, 2015 5:38 PM, "Ian Romanick"  wrote:
>
> On 05/07/2015 04:50 PM, Jason Ekstrand 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.
>
> I thought we already did this... why didn't this happen when NIR became
> the default for the FS backend?  And has that reason (assuming there was
> one) been resolved?

We couldn't do copy propagation of values in the attribute register file.
That, it turn was blocked on reworking the LOAD_PAYLOAD instruction.  I
pushed a series this morning that fixed both of those and cut 7.5% off of
all SIMD8 VS instructions when using NIR.  It also helps GLSL IR but by
only 1% or so.
--Jason

> > ---
> >  src/mesa/drivers/dri/i965/brw_context.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/src/mesa/drivers/dri/i965/brw_context.c
b/src/mesa/drivers/dri/i965/brw_context.c
> > index fd7420a..8615e5e 100644
> > --- a/src/mesa/drivers/dri/i965/brw_context.c
> > +++ b/src/mesa/drivers/dri/i965/brw_context.c
> > @@ -588,7 +588,7 @@ brw_initialize_context_constants(struct brw_context
*brw)
> >
ctx->Const.ShaderCompilerOptions[MESA_SHADER_VERTEX].EmitNoIndirectTemp =
true;
> >
ctx->Const.ShaderCompilerOptions[MESA_SHADER_VERTEX].OptimizeForAOS = false;
> >
> > -  if (brw_env_var_as_boolean("INTEL_USE_NIR", false))
> > +  if (brw_env_var_as_boolean("INTEL_USE_NIR", true))
> >
 ctx->Const.ShaderCompilerOptions[MESA_SHADER_VERTEX].NirOptions =
&nir_options;
> > }
> >
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

2015-05-07 Thread Ian Romanick 
On 05/07/2015 04:50 PM, Jason Ekstrand 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.

I thought we already did this... why didn't this happen when NIR became
the default for the FS backend?  And has that reason (assuming there was
one) been resolved?

> ---
>  src/mesa/drivers/dri/i965/brw_context.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/src/mesa/drivers/dri/i965/brw_context.c 
> b/src/mesa/drivers/dri/i965/brw_context.c
> index fd7420a..8615e5e 100644
> --- a/src/mesa/drivers/dri/i965/brw_context.c
> +++ b/src/mesa/drivers/dri/i965/brw_context.c
> @@ -588,7 +588,7 @@ brw_initialize_context_constants(struct brw_context *brw)
>
> ctx->Const.ShaderCompilerOptions[MESA_SHADER_VERTEX].EmitNoIndirectTemp = 
> true;
>ctx->Const.ShaderCompilerOptions[MESA_SHADER_VERTEX].OptimizeForAOS = 
> false;
>  
> -  if (brw_env_var_as_boolean("INTEL_USE_NIR", false))
> +  if (brw_env_var_as_boolean("INTEL_USE_NIR", true))
>   ctx->Const.ShaderCompilerOptions[MESA_SHADER_VERTEX].NirOptions = 
> &nir_options;
> }
>  

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

2015-05-07 Thread Kenneth Graunke 
On Thursday, May 07, 2015 04:50:39 PM Jason Ekstrand 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.
> ---
>  src/mesa/drivers/dri/i965/brw_context.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/src/mesa/drivers/dri/i965/brw_context.c 
> b/src/mesa/drivers/dri/i965/brw_context.c
> index fd7420a..8615e5e 100644
> --- a/src/mesa/drivers/dri/i965/brw_context.c
> +++ b/src/mesa/drivers/dri/i965/brw_context.c
> @@ -588,7 +588,7 @@ brw_initialize_context_constants(struct brw_context *brw)
>
> ctx->Const.ShaderCompilerOptions[MESA_SHADER_VERTEX].EmitNoIndirectTemp = 
> true;
>ctx->Const.ShaderCompilerOptions[MESA_SHADER_VERTEX].OptimizeForAOS = 
> false;
>  
> -  if (brw_env_var_as_boolean("INTEL_USE_NIR", false))
> +  if (brw_env_var_as_boolean("INTEL_USE_NIR", true))
>   ctx->Const.ShaderCompilerOptions[MESA_SHADER_VERTEX].NirOptions = 
> &nir_options;
> }
>  
> 

We definitely want to throw the switch before 10.6, so that all the
scalar backends are using NIR, and we'll be able to delete the
deprecated ones post-release.

Acked-by: Kenneth Graunke 


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

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

2015-05-07 Thread Jason Ekstrand 
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.
---
 src/mesa/drivers/dri/i965/brw_context.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/mesa/drivers/dri/i965/brw_context.c 
b/src/mesa/drivers/dri/i965/brw_context.c
index fd7420a..8615e5e 100644
--- a/src/mesa/drivers/dri/i965/brw_context.c
+++ b/src/mesa/drivers/dri/i965/brw_context.c
@@ -588,7 +588,7 @@ brw_initialize_context_constants(struct brw_context *brw)
   ctx->Const.ShaderCompilerOptions[MESA_SHADER_VERTEX].EmitNoIndirectTemp 
= true;
   ctx->Const.ShaderCompilerOptions[MESA_SHADER_VERTEX].OptimizeForAOS = 
false;
 
-  if (brw_env_var_as_boolean("INTEL_USE_NIR", false))
+  if (brw_env_var_as_boolean("INTEL_USE_NIR", true))
  ctx->Const.ShaderCompilerOptions[MESA_SHADER_VERTEX].NirOptions = 
&nir_options;
}
 
-- 
2.4.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev