From 16a22a5f4a9e0497164ef0fddcb4fe9ba1f6756e Mon Sep 17 00:00:00 2001 From: Keith Whitwell Date: Tue, 12 Sep 2006 13:54:31 +0000 Subject: Potential fix for doom3 lockups. Seems that there is a conflict between the vertex cache, the vertex shader and the clipping stages, all of which are competitors for URB entries assigned to the VS unit. This change reduces the maximum number of clip and VS threads by enough to ensure that they cannot consume all the available URB entries, and then reduces the number somewhat more up to an arbitary amount I discovered by trial and error. Unfortunately trial and error solutions don't inspire total confidence... --- src/mesa/drivers/dri/i965/brw_vs_state.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) (limited to 'src/mesa/drivers/dri/i965/brw_vs_state.c') diff --git a/src/mesa/drivers/dri/i965/brw_vs_state.c b/src/mesa/drivers/dri/i965/brw_vs_state.c index 70de0e8256..c225bf8f5c 100644 --- a/src/mesa/drivers/dri/i965/brw_vs_state.c +++ b/src/mesa/drivers/dri/i965/brw_vs_state.c @@ -53,7 +53,11 @@ static void upload_vs_unit( struct brw_context *brw ) /* BRW_NEW_URB_FENCE */ vs.thread4.nr_urb_entries = brw->urb.nr_vs_entries; vs.thread4.urb_entry_allocation_size = brw->urb.vsize - 1; - vs.thread4.max_threads = MIN2(brw->urb.nr_vs_entries, 16) - 1; + vs.thread4.max_threads = MIN2( + MAX2(0, (brw->urb.nr_vs_entries - 6) / 2 - 1), + 15); + + if (INTEL_DEBUG & DEBUG_SINGLE_THREAD) vs.thread4.max_threads = 0; -- cgit v1.2.3