On Fri, Mar 20, 2015 at 4:26 PM, Ian Romanick <i...@freedesktop.org> wrote: > On 03/20/2015 03:10 PM, Jason Ekstrand wrote: >> On Fri, Mar 20, 2015 at 1:58 PM, Ian Romanick <i...@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@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
