i965/gen6: Refactor gen6_upload_urb

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>
This commit is contained in:
Jason Ekstrand 2016-08-17 08:01:01 -07:00
parent 3e4b43d11d
commit 7ecbb9bada
2 changed files with 35 additions and 24 deletions

View 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);

View file

@ -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,
};