| Age | Commit message (Collapse) | Author |
|---|
|
The clip thread could potentially deadlock when processing tristrips since
being moved back to dual-thread mode, as the two threads could each have 4 VUEs
referenced and not be able to allocate another one since SF processing
wasn't able to continue (needing 5 entries before it freed 2).
In constrained URB mode, similar deadlock could even have occurred with
polygons (so we cut back max_threads if we can't handle it any primitive type).
|
|
It shouldn't offer anything new over what's in the docs (except for G4X notes),
but here it's all in one place.
|
|
Also, add a comment explaining what brw->urb.constrained tries to do.
|
|
This reverts commit 7c81124d7c4a4d1da9f48cbf7e82ab1a3a970a7a.
|
|
This reverts commit 53675e5c05c0598b7ea206d5c27dbcae786a2c03.
Conflicts:
src/mesa/drivers/dri/i965/brw_wm_surface_state.c
|
|
To do this, I had to clean up some of 965 state upload stuff. We may end
up over-emitting state in the aperture overflow case, but that should be rare,
and I'd rather have the simplification of state management.
|
|
|
|
e.g. bridge of fate.
If vs output is big, driver may fall back to use 8 urb entries for vs,
unfortunally, for some unknown reason, if vs is working at 4x2 mode,
8 entries is not enough, may lead to gpu hang.
|
|
Makes state emission into a 2 phase, prepare sets things up and accounts
the size of all referenced buffer objects. The emit stage then actually
does the batchbuffer touching for emitting the objects.
There is an assert in dri_emit_reloc if a reloc occurs for a buffer
that hasn't been accounted yet.
|
|
These don't appear to have ever been used.
|
|
|
|
values for nr of entries) should meet the requirement.
|
|
specifically {8,16,32}.
|
|
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...
|
|
This driver comes from Tungsten Graphics, with a few further modifications by
Intel.
|
