aboutsummaryrefslogtreecommitdiffstats
path: root/src/mesa/drivers/dri/i965/brw_vs.c
diff options
context:
space:
mode:
authorPaul Berry <[email protected]>2013-02-16 05:59:34 -0800
committerPaul Berry <[email protected]>2013-02-20 13:48:45 -0800
commit54d9c8a04a3d79da9a73f4b30d1c30874e05dc58 (patch)
tree0fb7150cc4ec84129222bac97ee5c059c56124e5 /src/mesa/drivers/dri/i965/brw_vs.c
parent8b586322e71d5ad0ce95d0fbcbfeb4df13f65040 (diff)
i965: Consign COORD_REPLACE VS hacks to Pre-Gen6.
Pre-Gen6, the SF thread requires exact matching between VS output slots (aka VUE slots) and FS input slots, even when the corresponding VS output slot is unused due to being overwritten by point coordinate replacement (glTexEnvi(GL_POINT_SPRITE, GL_COORD_REPLACE, GL_TRUE)). As a result, we have a special hack in the VS to ensure when any texture coordinate is subject to point coordinate replacement, it is always allocated space in the VUE, even if it isn't written to by the VS. This hack isn't needed from Gen6 onwards, since SF (Gen7: SBE) swizzling has the ability to insert the point coordinate into gl_TexCoord[] without needing a corresponding unused VUE slot. Note that no modification of SF setup code is required for this patch--get_attr_override() already does the right thing. However, we make a slight comment change to clarify why this works. In addition to eliminating unnecessary VS recompiles and saving precious URB space on Gen6+, this will save us the trouble of having to adjust this hack when we implement geometry shaders. Reviewed-by: Kenneth Graunke <[email protected]>
Diffstat (limited to 'src/mesa/drivers/dri/i965/brw_vs.c')
-rw-r--r--src/mesa/drivers/dri/i965/brw_vs.c22
1 files changed, 12 insertions, 10 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);