Bug 40361 - Glitches on X3100 after upgrade to 7.11
Glitches on X3100 after upgrade to 7.11
Status: RESOLVED FIXED
Product: Mesa
Classification: Unclassified
Component: Mesa core
git
x86-64 (AMD64) Linux (All)
: medium normal
Assigned To: mesa-dev
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-08-24 10:52 UTC by Jaroslav Šmíd
Modified: 2012-02-17 15:27 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
Debug output with array and indices printing (148.06 KB, text/plain)
2012-01-23 16:58 UTC, Jaroslav Šmíd
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jaroslav Šmíd 2011-08-24 10:52:48 UTC
After upgrading mesa from 7.10.3 to 7.11 (I chose git version because 7.11 isn't available in the list) I started to see glitches in Regnum Online making the game unplayable. I also noticed slight FPS drop.

Short video of Ignis realm gate with intel dri 7.10.3
http://www.youtube.com/watch?v=r_hg8GlHgSo

Short video of Ignis realm gate with intel dri 7.11
http://www.youtube.com/watch?v=sgg05FLffUU

Glitches appear on character selection screen too, I can record it too if needed, but i think it will be caused by the same bug.

My graphic card is intel X3100.
Comment 1 Jaroslav Šmíd 2011-08-25 04:32:42 UTC
(version 7.11 is now in the list so changed version from git to 7.11)
Comment 2 Jaroslav Šmíd 2012-01-22 13:12:49 UTC
Traced it to commit 963431829055f63ec94d88c97a5d07d30e49833a

http://cgit.freedesktop.org/mesa/mesa/commit/src/mesa/drivers/dri/i965?id=963431829055f63ec94d88c97a5d07d30e49833a

Since that commit the game is 'broken' as shown in the video.
Comment 3 Jaroslav Šmíd 2012-01-22 13:55:35 UTC
Ignore my last comment, bug appeared somewhere else. Game is buggy with 963431829055f63ec94d88c97a5d07d30e49833a, and is ok with commit 66b66295d0bc856c69fdcccc22575580c7ecee16.

Something in between had to break it, but I don't see anything using web interface http://cgit.freedesktop.org/mesa/mesa/log/src/mesa/drivers/dri/i965?ofs=800
Comment 4 Jaroslav Šmíd 2012-01-22 16:12:18 UTC
Okay, found the commit, it's 23d75936a72b9a9b9e1d04a901a86a75d93dbffb

http://cgit.freedesktop.org/mesa/mesa/commit/src/mesa?id=23d75936a72b9a9b9e1d04a901a86a75d93dbffb

Changing component to Mesa core.
Comment 5 Jaroslav Šmíd 2012-01-22 16:26:08 UTC
Now, I am not sure if this is even bug in mesa since there is warning in that function, saying "This should probably be fixed in the application".

But, if I comment out that condition added by the patch, the game runs stable, and everything seems to be drawn correctly, without any kind of blinking.
Comment 6 Jaroslav Šmíd 2012-01-22 17:01:45 UTC
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.



When I set MESA_DEBUG, the game prints these:

Mesa warning: glDraw[Range]Elements(start 0, end 20496, count 20496, type 0x1403, indices=(nil))
	end is out of bounds (max=3448)  Element Buffer 392 (size 40992)
	This should probably be fixed in the application.
Mesa warning: glDraw[Range]Elements(start 20586, end 21384, count 798, type 0x1403, indices=0xa0d4)
	end is out of bounds (max=13316)  Element Buffer 396 (size 54072)
	This should probably be fixed in the application.
Mesa warning: glDraw[Range]Elements(start 21546, end 21696, count 150, type 0x1403, indices=0xa854)
	end is out of bounds (max=13316)  Element Buffer 396 (size 54072)
	This should probably be fixed in the application.
Mesa warning: glDraw[Range]Elements(start 40146, end 40602, count 456, type 0x1403, indices=0x139a4)
	end is out of bounds (max=22005)  Element Buffer 390 (size 81204)
	This should probably be fixed in the application.
Mesa warning: glDraw[Range]Elements(start 26034, end 26946, count 912, type 0x1403, indices=0xcb64)
	end is out of bounds (max=13316)  Element Buffer 396 (size 54072)
	This should probably be fixed in the application.
Mesa warning: glDraw[Range]Elements(start 27018, end 27036, count 18, type 0x1403, indices=0xd314)
	end is out of bounds (max=13316)  Element Buffer 396 (size 54072)
	This should probably be fixed in the application.
Mesa warning: glDraw[Range]Elements(start 35577, end 39177, count 3600, type 0x1403, indices=0x115f2)
	end is out of bounds (max=22005)  Element Buffer 390 (size 81204)
	This should probably be fixed in the application.
Mesa warning: glDraw[Range]Elements(start 19434, end 20586, count 1152, type 0x1403, indices=0x97d4)
	end is out of bounds (max=13316)  Element Buffer 396 (size 54072)
	This should probably be fixed in the application.
Mesa warning: glDraw[Range]Elements(start 39177, end 39960, count 783, type 0x1403, indices=0x13212)
	end is out of bounds (max=22005)  Element Buffer 390 (size 81204)
	This should probably be fixed in the application.
Comment 7 Roland Scheidegger 2012-01-23 13:05:51 UTC
(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.
Comment 8 Jaroslav Šmíd 2012-01-23 16:58:19 UTC
Created attachment 56059 [details]
Debug output with array and indices printing

I did actiavate array printing and added some stuff to print those indices, it really seems the game is making up those start and end indexes, every index included in indices is in bounds.
The driver actually seems to ignore start and end and because indices are correct, everything is rendered correctly. But since mesa is checking them before passing, the game renders wrong.

I think this can be closed and I will report this to RO developers.
Comment 9 Roland Scheidegger 2012-01-23 19:17:11 UTC
Looks like an app issue then indeed, I think though the test mesa does is actually incorrect wrt basevertex.
As far as i can tell it would be perfectly ok (though maybe stupid) if _MaxElement is 100, start is 100, end is 200 and basevertex is -100 (since start/end are prior to adding the basevertex). And also the other way round of course.
Comment 10 Kenneth Graunke 2012-02-17 15:27:28 UTC
I've pushed a workaround to Mesa master: we now ignore bogus out-of-bounds ranges.  This should fix Regnum Online (though it's still an app bug).