[Intel-gfx] [PATCH 4/9] intel gen4-5: Fix backface/frontface selection when one one color is written to.

[Olivier Galibert]

On Fri, Jul 20, 2012 at 10:01:03AM -0700, Eric Anholt wrote:
> > diff --git a/src/mesa/drivers/dri/i965/brw_fs.cpp b/src/mesa/drivers/dri/i965/brw_fs.cpp
> > index 3f98137..3b62952 100644
> > --- a/src/mesa/drivers/dri/i965/brw_fs.cpp
> > +++ b/src/mesa/drivers/dri/i965/brw_fs.cpp
> > @@ -972,6 +972,15 @@ fs_visitor::calculate_urb_setup()
> >  	 if (c->key.vp_outputs_written & BITFIELD64_BIT(i)) {
> >  	    int fp_index = _mesa_vert_result_to_frag_attrib((gl_vert_result) i);
> >  
> > +            /* Special case: two-sided vertex option, vertex program
> > +             * only writes to the back color.  Map it to the
> > +             * associated front color location.
> > +             */
> > +            if (i >= VERT_RESULT_BFC0 && i <= VERT_RESULT_BFC1 &&
> > +                ctx->VertexProgram._TwoSideEnabled &&
> > +                urb_setup[i - VERT_RESULT_BFC0 + FRAG_ATTRIB_COL0] == -1)
> > +               fp_index = i - VERT_RESULT_BFC0 + FRAG_ATTRIB_COL0;
> 
> In the fs_visitor (and brw_wm_pass*), you don't get to look at ctx->
> state like that -- you're getting called once with some set of ctx
> state, but the program will get reused even if the ctx state changes.
> You'd have to get that state into the wm prog key, and use that, which
> would guarantee that you have the appropriate program code.

Ok.  OTOH, we don't actually *need* to look at TwoSideEnabled.  If the
rest of the condition triggers it's either correct or undefined
behaviour.  So we can do it systematically.

  OG.