(version 7.11 is now in the list so changed version from git to 7.11)

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.

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

Okay, found the commit, it's 23d75936a72b9a9b9e1d04a901a86a75d93dbffb

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

Changing component to Mesa core.

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.

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.

(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.

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.

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.

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).