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

[Kenneth Graunke]

On Friday, March 20, 2015 04:35:11 PM Jason Ekstrand wrote:
> 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:
> >> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20150321/6aa482cc/attachment.sig>