[Mesa-dev] [PATCH 00/23] Handle Booleans and things better

Jason Ekstrand jason at jlekstrand.net
Fri Mar 20 16:35:11 PDT 2015


On Fri, Mar 20, 2015 at 4:26 PM, Ian Romanick <idr at freedesktop.org> wrote:
> On 03/20/2015 03:10 PM, Jason Ekstrand wrote:
>> On Fri, Mar 20, 2015 at 1:58 PM, Ian Romanick <idr at freedesktop.org> wrote:
>>> This is a series that I've been working on for quite some time.  Some of
>>> these patches data from as long ago as July 2014.  It's finally time to
>>> just send it out.  I have felt like I have been shaving an infinite yak,
>>> and I have some additional patchs in-progress that will go on top of
>>> this series.
>>>
>>> Overall results for the without NIR:
>>>
>>> GM45 (0x2A42):
>>> total instructions in shared programs: 3550788 -> 3544141 (-0.19%)
>>> instructions in affected programs:     513721 -> 507074 (-1.29%)
>>> helped:                                1409
>>> HURT:                                  269
>>>
>>> Iron Lake (0x0046):
>>> total instructions in shared programs: 4980593 -> 4973020 (-0.15%)
>>> instructions in affected programs:     572150 -> 564577 (-1.32%)
>>> helped:                                1649
>>> HURT:                                  386
>>> GAINED:                                5
>>> LOST:                                  24
>>>
>>> Sandy Bridge (0x0116):
>>> total instructions in shared programs: 6817068 -> 6797680 (-0.28%)
>>> instructions in affected programs:     1388229 -> 1368841 (-1.40%)
>>> helped:                                5343
>>> HURT:                                  319
>>> GAINED:                                4
>>> LOST:                                  11
>>>
>>> Ivy Bridge (0x0166):
>>> total instructions in shared programs: 6290138 -> 6273022 (-0.27%)
>>> instructions in affected programs:     1204828 -> 1187712 (-1.42%)
>>> helped:                                4558
>>> HURT:                                  825
>>> GAINED:                                1
>>> LOST:                                  3
>>>
>>> Haswell (0x0426):
>>> total instructions in shared programs: 5777876 -> 5759525 (-0.32%)
>>> instructions in affected programs:     1130638 -> 1112287 (-1.62%)
>>> helped:                                4830
>>> HURT:                                  606
>>> GAINED:                                1
>>> LOST:                                  3
>>>
>>> Broadwell (0x162E):
>>> total instructions in shared programs: 6821191 -> 6806526 (-0.21%)
>>> instructions in affected programs:     1252081 -> 1237416 (-1.17%)
>>> helped:                                5090
>>> HURT:                                  608
>>> GAINED:                                4
>>> LOST:                                  4
>>
>> FYI: I added a "-p" for platform option to Matt's fancy new
>> shader-runner so you can do "./run -p bdw shaders" and it does the
>> INTEL_DEVID_OVERRIDE for you.  I was doing similar experiments this
>> week (running shader-db on everything) and found it useful.  Thought
>> you might like to know.
>
> I noticed that, and I plan to start using it.  All of this data is
> generated by scripts, and my scripts use the uppercase names.  Once I
> make a patch so that -p will also accept uppercase short names, I'll
> update my scripts.
>
>>> In some ways the results with NIR are even better (if you ignore Sandy
>>> Bridge):
>>>
>>> Sandy Bridge (0x0116) NIR:
>>> total instructions in shared programs: 6820689 -> 6785869 (-0.51%)
>>> instructions in affected programs:     1858575 -> 1823755 (-1.87%)
>>> helped:                                4559
>>> HURT:                                  3320
>>> GAINED:                                3
>>> LOST:                                  29
>>>
>>> Ivy Bridge (0x0166) NIR:
>>> total instructions in shared programs: 6309309 -> 6276897 (-0.51%)
>>> instructions in affected programs:     1639688 -> 1607276 (-1.98%)
>>> helped:                                4053
>>> HURT:                                  3496
>>> GAINED:                                34
>>> LOST:                                  3
>>>
>>> Haswell (0x0426) NIR:
>>> total instructions in shared programs: 5790261 -> 5751689 (-0.67%)
>>> instructions in affected programs:     1506127 -> 1467555 (-2.56%)
>>> helped:                                5407
>>> HURT:                                  1957
>>> GAINED:                                28
>>> LOST:                                  3
>>>
>>> Broadwell (0x162E) NIR:
>>> total instructions in shared programs: 7012929 -> 6977716 (-0.50%)
>>> instructions in affected programs:     1604094 -> 1568881 (-2.20%)
>>> helped:                                5626
>>> HURT:                                  2029
>>> GAINED:                                20
>>> LOST:                                  3
>>>
>>> In that there are 12 shaders that are hurt (by ~40 instructions) because
>>> we are now able to unroll a loop.  This is noted in the commit message
>>> of "glsl: Optimize certain if-statements to just casts from the
>>> condition".
>>>
>>> There are a couple commits that hurt a fair number of shaders with NIR.
>>> It doesn't seem like this should be the case, and it seems like there is
>>> probably work that can be done in brw_fs_nir.cpp to account for this.
>>
>> What commits were those?  In particular, what was needed to avoid
>> regressions from later commits?
>
> IIRC, and most of these were written quite some time ago, 2 through 6,
> ce3f463, and b616164.
>
>>> Without some of the initial changes to brw_fs_visitor.cpp, there were
>>> also regressions without NIR.  All of the changes in this series at the
>>> GLSL IR level are things that could have been written in the shader
>>> source.
>>
>> As the local defender of NIR, I feel the need to say that it would be
>> good if someone threw together a few patches to try and mirror the
>> algebraic optimizations here in NIR.  Patches 8, 9, 11, 12, 13, 14,
>> 16, and 23 could be implemented with a line or two each in
>> nir_opt_algebraic.py.
>
> I figured that would be the case, and that's part of the reason I wanted
> to get these out.  It seems like most of these kinds of optimizations
> will need to be implemented at each level of the IR.
>
>> There are a couple of reasons I'm asking for this.  One is that NIR
>> may be able to CSE something that results in one of these patterns and
>> we wouldn't get the optimization.  Another reason is that with Ken's
>> work to run ARB programs through NIR, we would like those to get as
>> many optimizations as the can and they b2f the universe.  As an aside,
>
> That doesn't seem right.  There's no bool in ARB programs, so how are
> they getting b2f?

Exactly... which is why Ken's translator b2f's the universe.  You'd
have to double-check with him, but I'm pretty sure that the ARB
version of (a < b), which returns a float, is implemented as b2f(a <
b).  At the very least, it's lowered to that so that the backend
doesn't have to deal with float comparisons.  Then NIR cleans it up
quite a bit before our backends see it.  Ken already killed 10% by
going through NIR.  It'd be nice to kill a few more. :-)

>> it would also be nice to get shader-db numbers for just the NIR
>> versions without the glsl versions optimizing ahead of it.  That will
>> be much easier to do *before* this series lands.
>
> As long as "well, now it doesn't help with NIR" isn't used as a reason
> NAK them. :)  Either way, I think seeing the per-patch numbers for both
> orderings (GLSL changes, then NIR changes and NIR changes, then GLSL
> changes) will be interesting.

Nope, not NAK'ing.  Half the value in these things is figuring out
what optimizations help.  The rest is "just typing"
--Jason

>>> At the end of the day on Broadwell with NIR, there are a bunch of
>>> shaders (some as small as ~22 instructions) hurt by 1 to 4 instructions.
>>> Only one shader is really hurt (119 -> 139).  This shader is noted in
>>> patch "glsl: Distribute multiply over b2f".  At the same time, over 250
>>> shaders with more than 100 instructions are helped by more than 20%.
>>> Oh, and we gained 20 SIMD16 shaders. :)
>>>
>>> This series is also available as the bool-optimizations-v6 branch in my
>>> fd.o Mesa repo.
>>>
>>> _______________________________________________
>>> mesa-dev mailing list
>>> mesa-dev at lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>


More information about the mesa-dev mailing list