2014-08-04 21:25 GMT+02:00 Eric Anholt <e...@anholt.net>: > thomashellan...@gmail.com writes: > >> From: Thomas Helland <thomashellan...@gmail.com> >> >> When writing that A || (A && B) patch some >> days ago I also wrote some other patches >> that have no impact on my collection of shaders. >> (shader-db + Some TF2 and Portal-shaders). >> No reduction in instruction count, and no >> significant increase in compilation time. >> >> I decided to put them up here anyway, as >> with your collection of shaders maybe YMMV. > > I'm definitely interested in seeing our optimizer gain features like > this, even if we don't have samples of code triggering them in our > database yet. What we have in shader-db from real-world apps is a > subset of what our compiler will encounter -- it doesn't tend to cover > code by novice shader developers, nor does it cover more-complex, > more-code-generated code we expect to see in the future.
This was my initial thought to. Also, while some of these patterns are simple, and likely be spotted by a seasoned programmer, they may end up in our tree from other optimizations simplifying the code. > > If the patches are cleaned up to use spaces instead of tabs, and avoid > trailing whitespace, patches 1-4, 7-8, and 10 are: > > Reviewed-by: Eric Anholt <e...@anholt.net> > I'll get these cleaned up and posted to the list again soon. I don't have commit access, so I'll need someone to push them for me. > For the sub case, I'm going want to disable lower_sub_to_add_neg on my > hardware, since I've got SUB but no negate modifier on operands. This > makes the (A - neg(B)) patch interesting to me. However, since neg(A) - > B -> neg(A+B) was questioned, and it would be no change for me as well, > I think we should probably drop that half. I'll rewrite this to drop the neg(A)-B part, and post it along with the rest. > > The min/max patches I'm not that interested in -- I think that class of > optimization would be better handled in an pass that can track various > bounds that values might have over time, rather than being a special > case in algebraic. _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
