https://bugs.freedesktop.org/show_bug.cgi?id=40361
--- Comment #7 from Roland Scheidegger <srol...@vmware.com> 2012-01-23 13:05:51
PST ---
(In reply to comment #6)
> I hope I am not spamming too much :D
> Now looking at that code ...
>
> if (end >= ctx->Array.ArrayObj->_MaxElement) {
>
> Maybe there shouldn't be greater or equal, but only greater? Just asking,
> since
> start+count is end so end should actually be invalid?. And when I checked
> _mesa_validate_DrawRangeElements which then called check_index_bounds (in
> mesa/main/api_validate.c), there I can see code
>
> if ((int)(min + basevertex) < 0 || max + basevertex >
> ctx->Array.ArrayObj->_MaxElement)
>
> see, only "greater than" condition.
Good catch. I actually believe though the code in check_index_bounds is wrong
and should match what's in vbo_exec_array.c (so >= for both). The reason is
that the max (or end) value represents an index, whereas _MaxElement (slightly
misnamed probably) rather indicates count (or bufsize). So _MaxElement of 1
really means "max is first element" (which has index zero).
The debug output actually shows "end" is way larger than "max" so this can't be
the problem.
Either somewhere _MaxElements isn't correctly calculated (or updated) somewhere
in mesa which seems unlikely or this really is an app bug. Since it works if
you revert the (correct as far as I can see) code to return early if end <
start I suppose the driver doesn't care much about those values.
My best bet is the app is enabling a vertex array (or rather forgetting to
disable) which it didn't really want to (that is it's actually unused in the
vertex shader). Depending on the driver that works just fine (as the hw won't
actually try to access the out-of-bounds values or it might have per-array
min/max settings and the bogus values won't get used anyway) but it's still an
app bug.
You could try enabling the mesa_print_arrays code below to see what the arrays
are looking like.
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
