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.
