On 05/25/2014 01:02 PM, Matt Turner wrote: > On Sun, May 25, 2014 at 1:08 AM, Kenneth Graunke <kenn...@whitecape.org> > wrote: >> diff --git a/src/mesa/drivers/dri/i965/brw_clip_tri.c >> b/src/mesa/drivers/dri/i965/brw_clip_tri.c >> index fdab260..5894b80 100644 >> --- a/src/mesa/drivers/dri/i965/brw_clip_tri.c >> +++ b/src/mesa/drivers/dri/i965/brw_clip_tri.c >> @@ -433,6 +434,7 @@ void brw_clip_tri( struct brw_clip_compile *c ) >> BRW_CONDITIONAL_GE, >> c->reg.nr_verts, >> brw_imm_ud(3)); >> + brw_set_predicate_control(p, BRW_PREDICATE_NORMAL); > > I think the following instructions are predicated on the flag value > set by this compare instruction -- a couple of shifts, and add, and > then a while instruction. I don't see a break or another way out of > the loop, so I'm guessing that the while is predicated on this > compare.
Yes, I agree...and that's what the code should be doing. brw_set_predicate_control(p, BRW_PREDICATE_NORMAL) sets the default state for all future instructions to be predicated. brw_WHILE will reset that to BRW_PREDICATE_NONE after emitting the WHILE instruction. Killing that implicit magic is on my to do list as well, but for now, this at least gets the rubbish out of brw_CMP. One bit at a time... :)
signature.asc
Description: OpenPGP digital signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
