From 7ecbb9bada62a50f5e430ead7fff9154a45afb68 Mon Sep 17 00:00:00 2001 From: Jason Ekstrand Date: Wed, 17 Aug 2016 08:01:01 -0700 Subject: [PATCH] i965/gen6: Refactor gen6_upload_urb This splits it into two functions very similar to gen7_upload_urb. Signed-off-by: Jason Ekstrand Reviewed-by: Topi Pohjolainen --- src/mesa/drivers/dri/i965/brw_context.h | 3 ++ src/mesa/drivers/dri/i965/gen6_urb.c | 56 ++++++++++++++----------- 2 files changed, 35 insertions(+), 24 deletions(-) diff --git a/src/mesa/drivers/dri/i965/brw_context.h b/src/mesa/drivers/dri/i965/brw_context.h index d8aa2ba47f3..da80e348a7d 100644 --- a/src/mesa/drivers/dri/i965/brw_context.h +++ b/src/mesa/drivers/dri/i965/brw_context.h @@ -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); diff --git a/src/mesa/drivers/dri/i965/gen6_urb.c b/src/mesa/drivers/dri/i965/gen6_urb.c index 1e54474e743..4370fedb820 100644 --- a/src/mesa/drivers/dri/i965/gen6_urb.c +++ b/src/mesa/drivers/dri/i965/gen6_urb.c @@ -46,33 +46,13 @@ * 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, }; -- 2.30.2