On 10/31/2012 06:13 PM, Eric Anholt wrote:
Kenneth Graunke <kenn...@whitecape.org> writes:
On 10/31/2012 02:26 PM, Eric Anholt wrote:
Otherwise, if we had a set of prims passed in with a num_instances varying
between them, we wouldn't upload enough (or too much!) from user vertex
arrays.
---
src/mesa/drivers/dri/i965/brw_draw.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/src/mesa/drivers/dri/i965/brw_draw.c
b/src/mesa/drivers/dri/i965/brw_draw.c
index 1cfba29..22d18f9 100644
--- a/src/mesa/drivers/dri/i965/brw_draw.c
+++ b/src/mesa/drivers/dri/i965/brw_draw.c
@@ -474,7 +474,10 @@ static bool brw_try_draw_prims( struct gl_context *ctx,
intel_batchbuffer_require_space(intel, estimated_max_prim_size, false);
intel_batchbuffer_save_state(intel);
- brw->num_instances = prim->num_instances;
+ if (brw->num_instances != prim->num_instances) {
+ brw->num_instances = prim->num_instances;
+ brw->state.dirty.brw |= BRW_NEW_VERTICES;
+ }
if (intel->gen < 6)
brw_set_prim(brw, &prim[i]);
else
I agree that BRW_NEW_VERTICES needs to be changed when num_instances
changes. However, it's already unconditionally flagged above:
brw->vb.min_index = min_index;
brw->vb.max_index = max_index;
brw->state.dirty.brw |= BRW_NEW_VERTICES;
So I don't think you'll be able to observe any problems. That said, I
approve of this change anyway, because it's self-documentating and
guards against potential problems.
That's outside the per-prim loop, though.
Oh dear. Yes, brw_upload_state() is inside the loop, so it clears the
BRW_NEW_VERTICES flag. So your change is necessary. My mistake.
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
