On Fri, Feb 20, 2015 at 11:54 AM, Eric Anholt <[email protected]> wrote: > I wanted patch #1 to land, so I took a look at this one :)
Thanks! :) > Matt Turner <[email protected]> writes: >> + if (brw->gen >= 6) { >> + /* Bit 15 of g0.0 is 0 if the polygon is front facing. */ >> + fs_reg g0 = fs_reg(retype(brw_vec1_grf(0, 0), BRW_REGISTER_TYPE_W)); >> + >> + /* For (gl_FrontFacing ? 1.0 : -1.0), emit: >> + * >> + * or(8) tmp.1<2>W g0.0<0,1,0>W 0x00003f80W >> + * and(8) dst<1>D tmp<8,8,1>D 0xbf800000D >> + * >> + * and negate g0.0<0,1,0>W for (gl_FrontFacing ? -1.0 : 1.0). >> + */ >> + >> + if (value1->f[0] == -1.0f) { >> + g0.negate = true; >> + } > > Does this do what you want? If g0.0 happened to be *all* zeroes, you're > still going to get 0 after negation, right? That's a good question. I'm not sure. The bits below it are 13: Source Depth Present to Render Target. 12: oMask to Render Target 11: Source0 Alpha Present to RenderTarget. 8:6: Starting Sample Pair Index BDW adds some additional fields as well. The others are "ignored". It's not clear to me that at least one of the defined bits is guaranteed to be zero. It's no guarantee or anything, but FWIW without realizing it we were depending on some bit being non-zero for the frontfacing optimizations that used ASR as well (commits d1c43ed4, 19c6617a) and haven't seen any problems from it. So if there's a problem... we're not making it worse in this commit... The simulator seems to set some bits in the ignored fields, but I don't have any explanation for that, nor is that evidence that we can rely on the hardware to do the same. Or maybe I'm just wrong and some bit is guaranteed to be set? > (I suppose your primitive type is probably going to be triangles if > you're doing facing, so the low bits will be non-zero) _______________________________________________ mesa-dev mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/mesa-dev
