i965: Allocate dummy slots for point sprites before computing VUE map.

Commit f0cecd43d6b6d moved the VUE map computation to be only once, at
VS compile time.  However, it did so in slightly the wrong place: it
made the one call to brw_vue_compute_map happen right before the
allocation of dummy slots for replaced point sprite coordinates, causing
a different VUE map to be generated (at least on Ironlake).

Fixes a regression in Piglit's point-sprite test on Ironlake.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=46489
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>

diff --git a/src/mesa/drivers/dri/i965/brw_vs.c b/src/mesa/drivers/dri/i965/brw_vs.c
index 7e690326d903be2d0f02ebd8412a35a2ac014021..b1b073e9bdebc65ddb3d0427b6f3ae939ad12d29 100644 (file)
--- a/src/mesa/drivers/dri/i965/brw_vs.c
+++ b/src/mesa/drivers/dri/i965/brw_vs.c
@@ -218,8 +218,6 @@ do_vs_prog(struct brw_context *brw,
       c.prog_data.inputs_read |= VERT_BIT_EDGEFLAG;
    }
 
-   brw_compute_vue_map(&c);
-
    /* 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
@@ -231,6 +229,8 @@ do_vs_prog(struct brw_context *brw,
         c.prog_data.outputs_written |= BITFIELD64_BIT(VERT_RESULT_TEX0 + i);
    }
 
+   brw_compute_vue_map(&c);
+
    if (0) {
       _mesa_fprint_program_opt(stdout, &c.vp->program.Base, PROG_PRINT_DEBUG,
                               true);