i965/gen6: Refactor gen6_upload_urb
authorJason Ekstrand <jason.ekstrand@intel.com>
Wed, 17 Aug 2016 15:01:01 +0000 (08:01 -0700)
committerJason Ekstrand <jason.ekstrand@intel.com>
Mon, 29 Aug 2016 19:17:34 +0000 (12:17 -0700)
This splits it into two functions very similar to gen7_upload_urb.

Signed-off-by: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Topi Pohjolainen <topi.pohjolainen@intel.com>
src/mesa/drivers/dri/i965/brw_context.h
src/mesa/drivers/dri/i965/gen6_urb.c

index d8aa2ba..da80e34 100644 (file)
@@ -1695,6 +1695,9 @@ gen7_emit_push_constant_state(struct brw_context *brw, unsigned vs_size,
                               unsigned gs_size, unsigned fs_size);
 
 void
+gen6_upload_urb(struct brw_context *brw, unsigned vs_size,
+                bool gs_present, unsigned gs_size);
+void
 gen7_upload_urb(struct brw_context *brw, unsigned vs_size,
                 bool gs_present, bool tess_present);
 
index 1e54474..4370fed 100644 (file)
  * Sandybridge GT1 has 32kB of URB space, while GT2 has 64kB.
  * (See the Sandybridge PRM, Volume 2, Part 1, Section 1.4.7: 3DSTATE_URB.)
  */
-static void
-gen6_upload_urb( struct brw_context *brw )
+void
+gen6_upload_urb(struct brw_context *brw, unsigned vs_size,
+                bool gs_present, unsigned gs_size)
 {
    int nr_vs_entries, nr_gs_entries;
    int total_urb_size = brw->urb.size * 1024; /* in bytes */
 
-   bool gs_present = brw->ff_gs.prog_active || brw->geometry_program;
-
-   /* BRW_NEW_VS_PROG_DATA */
-   unsigned vs_size = MAX2(brw->vs.prog_data->base.urb_entry_size, 1);
-
-   /* Whe using GS to do transform feedback only we use the same VUE layout for
-    * VS outputs and GS outputs (as it's what the SF and Clipper expect), so we
-    * can simply make the GS URB entry size the same as for the VS.  This may
-    * technically be too large in cases where we have few vertex attributes and
-    * a lot of varyings, since the VS size is determined by the larger of the
-    * two. For now, it's safe.
-    *
-    * For user-provided GS the assumption above does not hold since the GS
-    * outputs can be different from the VS outputs.
-    */
-   unsigned gs_size = vs_size;
-   if (brw->geometry_program) {
-      gs_size = brw->gs.prog_data->base.urb_entry_size;
-      assert(gs_size >= 1);
-   }
-
    /* Calculate how many entries fit in each stage's section of the URB */
    if (gs_present) {
       nr_vs_entries = (total_urb_size/2) / (vs_size * 128);
@@ -124,6 +104,34 @@ gen6_upload_urb( struct brw_context *brw )
    brw->urb.gs_present = gs_present;
 }
 
+static void
+upload_urb(struct brw_context *brw)
+{
+   /* BRW_NEW_VS_PROG_DATA */
+   const unsigned vs_size = MAX2(brw->vs.prog_data->base.urb_entry_size, 1);
+
+   /* BRW_NEW_GEOMETRY_PROGRAM, BRW_NEW_GS_PROG_DATA */
+   const bool gs_present = brw->ff_gs.prog_active || brw->geometry_program;
+
+   /* Whe using GS to do transform feedback only we use the same VUE layout for
+    * VS outputs and GS outputs (as it's what the SF and Clipper expect), so we
+    * can simply make the GS URB entry size the same as for the VS.  This may
+    * technically be too large in cases where we have few vertex attributes and
+    * a lot of varyings, since the VS size is determined by the larger of the
+    * two. For now, it's safe.
+    *
+    * For user-provided GS the assumption above does not hold since the GS
+    * outputs can be different from the VS outputs.
+    */
+   unsigned gs_size = vs_size;
+   if (brw->geometry_program) {
+      gs_size = brw->gs.prog_data->base.urb_entry_size;
+      assert(gs_size >= 1);
+   }
+
+   gen6_upload_urb(brw, vs_size, gs_present, gs_size);
+}
+
 const struct brw_tracked_state gen6_urb = {
    .dirty = {
       .mesa = 0,
@@ -134,5 +142,5 @@ const struct brw_tracked_state gen6_urb = {
              BRW_NEW_GS_PROG_DATA |
              BRW_NEW_VS_PROG_DATA,
    },
-   .emit = gen6_upload_urb,
+   .emit = upload_urb,
 };