Bug 11174

*** Bug 12241 has been marked as a duplicate of this bug. ***

ping?

Any chance this bug could get some attention, I'm more then willing to help with testing, or even trying to fix it myself if someone can give me some clues where to look.

(In reply to comment #2): If you are willing to test, then build and try the latest Mesa from git: http://dri.freedesktop.org/wiki/Building .

I'm currently using 7.0.1 with the r300 part updated to the latest git, I would think thats recent enough. Especially since this broke between 6.4.2 and 6.5.1 I think that its very unlikely that this got fixed by any commits after 7.0.1

If you're already using git, then you could now use git-bisect to find the commit that caused the breakage.

I'm not using git, I'm using the Fedora development bracnh packages which are mesa-7.0.1 + a patch updating r300 support to git master. Not that the r300 patch is very relevant as I can reproduce this on intel video machines as well.

Erm, was mesa already using git in the 6.4.2 days? As that was the latest working version. Also installing 6.4.2 requires me to downgrade several key Operating system parts like the xserver, libdrm, etc. I don't want to know what I have todo to my system to be able to build 6.4.2 from source.

As said I'm willing to spend some time on this, but telling me to go fetch a needle in a haystack isn't really helpful.

I gave this a very quick try, and it indeed looks horrible (on r200). For me though it always looks horrible, I don't have to press space. Also, it doesn't just look black, it more looks like z-fighting issues so it flickers black.
Not sure if that's related, but unless this is a bug in mesa (with display list handling?), the game does some things it shouldn't do - there are tons of mesa warnings about stack overflows (mostly in the menu) and stack underflows (in-game) with the projection/modelview matrix stacks (and it tries to use an illegal filter mode for the texture mag filter, but that should be harmless).
This app uses GL_LINE polygon mode, which causes a tcl fallback in the r200 driver, which could lead to z-fighting - but even specifiying tcl_mode=0 doesn't do anything.
With the software rasterizer, it looks almost ok though - there are a lot of very small white triangles flying around randomly (maybe that represents some snow or something and is meant to be there), and the tile boundaries look crappy (they are somewhat disjoint, I think the game uses the GL_LINE poly mode to draw the tile borders (with polygonoffset) and then GL_FILL mode for the tile, but it doesn't seem to quite match up with the neighboring tiles).

(In reply to comment #6)
> Erm, was mesa already using git in the 6.4.2 days?

It was probably using CVS at the time, but the whole development history was preserved when moving to Git, so this isn't a problem.

> Also installing 6.4.2 requires me to downgrade several key Operating system
> parts like the xserver, libdrm, etc. 

It shouldn't. You don't even need to install anything, just set the environment variable LIBGL_DRIVERS_PATH=/path/to/directory_containing_r300_dri.so/ and possibly LD_LIBRARY_PATH=/path/to/libGL.so.1 .

> I don't want to know what I have todo to my system to be able to build 6.4.2
> from source.

Again, I'm not sure there should be any big trouble. You may want to use

make DRI_DIRS=r300

to avoid any trouble with other drivers though.

> As said I'm willing to spend some time on this, but telling me to go fetch a
> needle in a haystack isn't really helpful.

git-bisect does that for you. :)

(In reply to comment #7)
> I gave this a very quick try, and it indeed looks horrible (on r200). For me
> though it always looks horrible, I don't have to press space. Also, it doesn't
> just look black, it more looks like z-fighting issues so it flickers black.
> Not sure if that's related, but unless this is a bug in mesa (with display list
> handling?), the game does some things it shouldn't do - there are tons of mesa
> warnings about stack overflows (mostly in the menu) and stack underflows
> (in-game) with the projection/modelview matrix stacks (and it tries to use an
> illegal filter mode for the texture mag filter, but that should be harmless).
> This app uses GL_LINE polygon mode, which causes a tcl fallback in the r200
> driver, which could lead to z-fighting - but even specifiying tcl_mode=0
> doesn't do anything.
> With the software rasterizer, it looks almost ok though - there are a lot of
> very small white triangles flying around randomly (maybe that represents some
> snow or something and is meant to be there), and the tile boundaries look
> crappy (they are somewhat disjoint, I think the game uses the GL_LINE poly mode
> to draw the tile borders (with polygonoffset) and then GL_FILL mode for the
> tile, but it doesn't seem to quite match up with the neighboring tiles).
> 

Thanks for looking into this, I already had a hunch that this might actually be a trackballs problem, as all other OpenGL apps seem to work fine. I've mailed upstream about this. Id there anything obvious I can check for in the trackballs source while we are waiting for upstream to respond?

Today I noticed that with the mesa 7.1 pre snapshot included in Fedora Rawhide I can no longer reproduce this on an i810 motherboard.

However, I just tried it on my r300 system and there his still happens, so I guess it was never a bug in core, but in the dri-drivers all along, but it happened to be a bug shared between the i810 and r300 drivers.

Okay, I've bitten the bullet and spend an entire day git bisecting this.

Actually there are 2 regression moments where the trackballs has black vertices problem get introduced, the first one between 6.5.0 and 6.5.1, I've managed to find this with git-bisect and made a patch which fixes 6.5.1, then there is another regression between 6.5.1 (with attached fix) and current master.

bisecting this led me too the vbo merger, after which all I got where either crashing or non building revisions.

Today I've spend an hour or so trying to fix this by looking at how trackballs does this, this has lead to a patch to trackballs which fixes (or workarounds?) this. I'm not sure if trackballs is to blame though, as it works fine with intel cards (7.0.2) and with the software renderer.

I'll also attach that patch, perhaps it sheds some light on this.

Created attachment 13488 [details] [review]
PATCH: fix a regression between 6.5 and 6.5.1 where some vertices in trackballs went black

Note this is the fix (revert of a commit) for the regression between 6.5 and 6.5.1 ported to 7.0.2.

Even though this does not fix the issue with 7.0.2 I still believe this should be applied as the removed code is an old ugly hack to fix bug 6991 (according to the  log of the commit this reverts).

I'm not intimate enough with any of the mesa code to make this assessment for sure though. Note that the removed code is the last user of the dummy_attrib and temp_attrib context members, so those can be removed too if this gets removed.

I tried ppracer with this patch and it still works fine, so the removed code isn't necessary anymore for bug 6991 atleast.

Created attachment 13489 [details] [review]
PATCH: fix black rendered vertices with trackballs

And as promised a patch against trackballs "fixing"? the problem.

Can you reproduce this bug on mesa 7.6?

(In reply to comment #14)
> Can you reproduce this bug on mesa 7.6?
> 

Sorry, it took me a while until I got around to trying this, even with
the workaround removed from trackballs, the black vertices are gone, so it looks like this has been fixed.

For the record:
[hans@localhost devel]$ rpm -q mesa-libGL
mesa-libGL-7.6-0.18.fc12.x86_64