On 07/10/2013 02:46 PM, Chris Forbes wrote:
Fixes undefined results if a back color is written, but the corresponding front color is not, and only backfacing primitives are drawn. Results are still undefined if a frontfacing primitive is drawn, but that's OK.The other reasonable way to fix this would have been to just pick the one color slot that was populated, but that dilutes the value of the tests. On Gen6+, the fixed function clipper and triangle setup already take care of this. Fixes 11 piglits: spec/glsl-1.10/execution/interpolation/interpolation-none-gl_Back*Color-* NOTE: This is a candidate for stable branches. Signed-off-by: Chris Forbes <chr...@ijw.co.nz> --- src/mesa/drivers/dri/i965/brw_vs.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/src/mesa/drivers/dri/i965/brw_vs.c b/src/mesa/drivers/dri/i965/brw_vs.c index 60b40c5..5b8173d 100644 --- a/src/mesa/drivers/dri/i965/brw_vs.c +++ b/src/mesa/drivers/dri/i965/brw_vs.c @@ -277,6 +277,12 @@ do_vs_prog(struct brw_context *brw, if (c.key.point_coord_replace & (1 << i)) outputs_written |= BITFIELD64_BIT(VARYING_SLOT_TEX0 + i); } + + /* if back colors are written, allocate slots for front colors too */ + if (outputs_written & BITFIELD64_BIT(VARYING_SLOT_BFC0)) + outputs_written |= BITFIELD64_BIT(VARYING_SLOT_COL0); + if (outputs_written & BITFIELD64_BIT(VARYING_SLOT_BFC1)) + outputs_written |= BITFIELD64_BIT(VARYING_SLOT_COL1); } brw_compute_vue_map(brw, &prog_data.base.vue_map, outputs_written,
I'm not terribly familiar with how this works, but it seems reasonable to me; those two usually come in pairs so we can use swizzling to select which we want.
Reviewed-by: Kenneth Graunke <kenn...@whitecape.org> _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
