diff options
| -rw-r--r-- | src/mesa/drivers/dri/i965/brw_vs.c | 22 | ||||
| -rw-r--r-- | src/mesa/drivers/dri/i965/brw_vs.h | 10 | ||||
| -rw-r--r-- | src/mesa/drivers/dri/i965/gen6_sf_state.c | 13 |
3 files changed, 34 insertions, 11 deletions
diff --git a/src/mesa/drivers/dri/i965/brw_vs.c b/src/mesa/drivers/dri/i965/brw_vs.c index 08104717781..64659c084d8 100644 --- a/src/mesa/drivers/dri/i965/brw_vs.c +++ b/src/mesa/drivers/dri/i965/brw_vs.c @@ -258,15 +258,17 @@ do_vs_prog(struct brw_context *brw, c.prog_data.inputs_read |= VERT_BIT_EDGEFLAG; } - /* Put dummy slots into the VUE for the SF to put the replaced - * point sprite coords in. We shouldn't need these dummy slots, - * which take up precious URB space, but it would mean that the SF - * doesn't get nice aligned pairs of input coords into output - * coords, which would be a pain to handle. - */ - for (i = 0; i < 8; i++) { - if (c.key.point_coord_replace & (1 << i)) - c.prog_data.outputs_written |= BITFIELD64_BIT(VERT_RESULT_TEX0 + i); + if (intel->gen < 6) { + /* Put dummy slots into the VUE for the SF to put the replaced + * point sprite coords in. We shouldn't need these dummy slots, + * which take up precious URB space, but it would mean that the SF + * doesn't get nice aligned pairs of input coords into output + * coords, which would be a pain to handle. + */ + for (i = 0; i < 8; i++) { + if (c.key.point_coord_replace & (1 << i)) + c.prog_data.outputs_written |= BITFIELD64_BIT(VERT_RESULT_TEX0 + i); + } } brw_compute_vue_map(brw, &c); @@ -429,7 +431,7 @@ static void brw_upload_vs_prog(struct brw_context *brw) key.clamp_vertex_color = ctx->Light._ClampVertexColor; /* _NEW_POINT */ - if (ctx->Point.PointSprite) { + if (intel->gen < 6 && ctx->Point.PointSprite) { for (i = 0; i < 8; i++) { if (ctx->Point.CoordReplace[i]) key.point_coord_replace |= (1 << i); diff --git a/src/mesa/drivers/dri/i965/brw_vs.h b/src/mesa/drivers/dri/i965/brw_vs.h index 75c8a5f8c98..caa8f7c145e 100644 --- a/src/mesa/drivers/dri/i965/brw_vs.h +++ b/src/mesa/drivers/dri/i965/brw_vs.h @@ -86,7 +86,17 @@ struct brw_vs_prog_key { GLuint userclip_planes_enabled_gen_4_5:MAX_CLIP_PLANES; GLuint copy_edgeflag:1; + + /** + * For pre-Gen6 hardware, a bitfield indicating which texture coordinates + * are going to be replaced with point coordinates (as a consequence of a + * call to glTexEnvi(GL_POINT_SPRITE, GL_COORD_REPLACE, GL_TRUE)). Because + * our SF thread requires exact matching between VS outputs and FS inputs, + * these texture coordinates will need to be unconditionally included in + * the VUE, even if they aren't written by the vertex shader. + */ GLuint point_coord_replace:8; + GLuint clamp_vertex_color:1; struct brw_sampler_prog_key_data tex; diff --git a/src/mesa/drivers/dri/i965/gen6_sf_state.c b/src/mesa/drivers/dri/i965/gen6_sf_state.c index 7071acc8d27..87f5bb10ebd 100644 --- a/src/mesa/drivers/dri/i965/gen6_sf_state.c +++ b/src/mesa/drivers/dri/i965/gen6_sf_state.c @@ -78,7 +78,18 @@ get_attr_override(struct brw_vue_map *vue_map, int urb_entry_read_offset, if (slot == -1) { /* This attribute does not exist in the VUE--that means that the vertex - * shader did not write to it. Behavior is undefined in this case, so + * shader did not write to it. This means that either: + * + * (a) This attribute is a texture coordinate, and it is going to be + * replaced with point coordinates (as a consequence of a call to + * glTexEnvi(GL_POINT_SPRITE, GL_COORD_REPLACE, GL_TRUE)), so the + * hardware will ignore whatever attribute override we supply. + * + * (b) This attribute is read by the fragment shader but not written by + * the vertex shader, so its value is undefined. Therefore the + * attribute override we supply doesn't matter. + * + * In either case the attribute override we supply doesn't matter, so * just reference the first available attribute. */ return 0; |