On Friday, March 20, 2015 04:35:11 PM Jason Ekstrand wrote: > 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: > >> 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. :-)
On platforms that have native integer support, I made prog_to_nir use b2f(f__(x)) for SLT, SGE, SLE, SGT, SEQ, SNE. Also, CMP uses bcsel(flt(x), y, z)...and KIL uses bany4 instead of fany4. The thinking is to separate out the actual operation from the "bools as floats" part, so hopefully some of that can be optimized away. It also saves backends from having to implement SLT and friends. I've been hoping to go through and add algebraic optimizations for common ARB patterns (i.e. fmul(b2f(...)) -> b2f(iand(...))). --Ken
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
