i965: Don't emit bad packets when no VBs are referenced.

It appears that sometimes Mesa (and I suppose a VS could as well) emits
a program which references no vertex data, and thus we end up with
nr_enabled == 0 even though some VBs are enabled.  We'd end up emitting
VB/VE packet headers of 0xffffffff in that case, leading to GPU hangs.

Bug #22945 (wine with an uncompiled VS)
(cherry picked from commit d1fbfd0f962347e4153db3852292d44de5aea863)

diff --git a/src/mesa/drivers/dri/i965/brw_draw_upload.c b/src/mesa/drivers/dri/i965/brw_draw_upload.c
index c1fe85908b822439095934353c6ce1ac31e772f6..e7a87b6e09fbe4478ea52074af49ce17d5ce01b6 100644 (file)
--- a/src/mesa/drivers/dri/i965/brw_draw_upload.c
+++ b/src/mesa/drivers/dri/i965/brw_draw_upload.c
@@ -479,6 +479,28 @@ static void brw_emit_vertices(struct brw_context *brw)
 
    brw_emit_query_begin(brw);
 
+   /* If the VS doesn't read any inputs (calculating vertex position from
+    * a state variable for some reason, for example), emit a single pad
+    * VERTEX_ELEMENT struct and bail.
+    *
+    * The stale VB state stays in place, but they don't do anything unless
+    * a VE loads from them.
+    */
+   if (brw->vb.nr_enabled == 0) {
+      BEGIN_BATCH(3, IGNORE_CLIPRECTS);
+      OUT_BATCH((CMD_VERTEX_ELEMENT << 16) | 1);
+      OUT_BATCH((0 << BRW_VE0_INDEX_SHIFT) |
+               BRW_VE0_VALID |
+               (BRW_SURFACEFORMAT_R32G32B32A32_FLOAT << BRW_VE0_FORMAT_SHIFT) |
+               (0 << BRW_VE0_SRC_OFFSET_SHIFT));
+      OUT_BATCH((BRW_VE1_COMPONENT_STORE_0 << BRW_VE1_COMPONENT_0_SHIFT) |
+               (BRW_VE1_COMPONENT_STORE_0 << BRW_VE1_COMPONENT_1_SHIFT) |
+               (BRW_VE1_COMPONENT_STORE_0 << BRW_VE1_COMPONENT_2_SHIFT) |
+               (BRW_VE1_COMPONENT_STORE_1_FLT << BRW_VE1_COMPONENT_3_SHIFT));
+      ADVANCE_BATCH();
+      return;
+   }
+
    /* Now emit VB and VEP state packets.
     *
     * This still defines a hardware VB for each input, even if they