Bug 30960

Created attachment 39505 [details]
Screenshot of lightmaps corruption #2 (ignore the error messages on top and white rectangle - it's fixed in tommorows build)

Created attachment 39506 [details]
Screenshot of lightmaps corruption #3

The problem has been discussed with Xonotic developers and does look like driver bug.

The problem is not on every map but on most of them and not on every texture.
Example map red_V2: 
http://picpaste.com/xonotic000025-izMRie6h.jpg
The same at a bit closer distance:
http://picpaste.com/xonotic000026-JgQAIEys.jpg
More closer (on the left textures ok, doors and right textures broken):
http://picpaste.com/xonotic000027-j4riFPmN.jpg
Almost ok (this texture corruption gets random whenever I move the mouse):
http://picpaste.com/xonotic000028-ZEkd1DoG.jpg
Another map - evilspace2 (http://beta.xonotic.org/autobuild-bsp/evilspace-full-cb6860159bdfb02f5bd5d76ad78db7fdbeb2f1c3-310d495e18dccf5de69f7319f57176178d4d72ce.pk3): http://picpaste.com/xonotic000033-QRBL0lWT.jpg - textures on the lower floor are OK always.
The same map - showing one texture ok (it's always OK) and others broken: 
http://picpaste.com/xonotic000037-h1vhAD9q.jpg
Tried with suggested game option "r_shadow_deferred 1":
http://picpaste.com/xonotic000023-rNkR29Tq.jpg
Default map (glowplant) with lightmaps on glsl:
http://picpaste.com/xonotic000062-nOfZlVRw.jpg
The same place with lightmaps+deluxemapping:
http://picpaste.com/xonotic000063-WqFIFjDk.jpg
Once more red_V2 with lightmaps: 
http://picpaste.com/xonotic000066-ilX94A1H.jpg
The same place with lightmaps and "r_glsl_deluxemapping 1", too:
http://picpaste.com/xonotic000065-19VIO1a7.jpg
The same place with lightmaps, "r_glsl_deluxemapping 1" and "r_fakelight 2":
http://picpaste.com/xonotic000067-4VM3tJn9.jpg
Map that is working ok (evilspace remix) with both lightmaps and deluxemapping: 
http://picpaste.com/xonotic000060-gfu8U61e.jpg
Default map (glowplant) with "gl_picmip 1000":
http://picpaste.com/xonotic000071-eg1KFicn.jpg
The same after moving mouse a bit:
http://picpaste.com/xonotic000072-pIgPU6Sd.jpg
Like previous:
http://picpaste.com/xonotic000073-6NFQ7D9B.jpg
And one more:
http://picpaste.com/xonotic000074-5qEkk2A7.jpg
Glowplant map with default "mod_q3bsp_lightmapmergepower 4" option:
http://picpaste.com/xonotic000079-p7ku82CV.jpg
The same (not moved) with "mod_q3bsp_lightmapmergepower 3":
http://picpaste.com/xonotic000080-7p7PgQ2U.jpg
The same (not moved) with "mod_q3bsp_lightmapmergepower 2":
http://picpaste.com/xonotic000081-1mYDfeKo.jpg
The same (not moved) with "mod_q3bsp_lightmapmergepower 1":
http://picpaste.com/xonotic000084-xQuzetgC.jpg
The same (not moved) with "mod_q3bsp_lightmapmergepower 0":
http://picpaste.com/xonotic000082-AwGA2wtr.jpg - almost OK but with a big cost of FPS drop and here a floor is still a problem but it's just like before - random, not only the floor.

And the problem is gone when I disable GLSL.

Created attachment 39521 [details]
dmesg

Created attachment 39522 [details]
glxinfo

Created attachment 39523 [details]
Xorg.0.log

Created attachment 39524 [details]
GLSL shader dump from the game

Can you run the program with RADEON_DEBUG=fp,vp and post the output?

Created attachment 39531 [details]
RADEON_DEBUG=fp,vp (STDERR log)

Created attachment 39532 [details]
RADEON_DEBUG=fp,vp (STDOUT [game] log)

Created attachment 39533 [details]
Screenshot during logs grab xonotic000001.jpg

Created attachment 39534 [details]
Screenshot during logs grab xonotic000002.jpg

Created attachment 39535 [details]
Screenshot during logs grab xonotic000003.jpg

Created attachment 39536 [details]
Screenshot during logs grab xonotic000004.jpg

Created attachment 39537 [details]
Screenshot during logs grab xonotic000005.jpg

Created attachment 39538 [details]
Screenshot during logs grab xonotic000006.jpg

Created attachment 39539 [details]
RADEON_DEBUG=fp,vp + game log 2>&1 merged

Created attachment 39540 [details]
Screenshot during merged logs grab xonotic000008.jpg

Created attachment 39541 [details]
Screenshot during merged logs grab xonotic000009.jpg

Created attachment 39542 [details]
Screenshot during merged logs grab xonotic000010.jpg

Created attachment 39544 [details]
RADEON_DEBUG=fp,vp +game log lightmaps+deluxemapping

Created attachment 39545 [details]
Screenshot during merged logs grab lightmap+deluxemapping xonotic000011.jpg

Created attachment 39546 [details]
Screenshot during merged logs grab lightmap+deluxemapping xonotic000012.jpg

Created attachment 39547 [details]
Screenshot during merged logs grab lightmap+deluxemapping xonotic000013.jpg

Does running with RADEON_DEBUG=noopt fix the problem?  If it does, can out post the output of RADEON_DEBUG=vp,fp,noopt?  You can just post the stderr output, I don't need any more screenshots.

I don't see any difference with RADEON_DEBUG=noopt for both lightmap and lightmap+deluxemapping problem - both look like before.
And sorry for that many screenshots - I thought that making screenshots during logs grab might help you to see what's the problem.

And I've tested it now with libgl1-mesa-dri_7.10.0~git20101019+gallium.974fb466-0ubuntu0tormod_i386.deb + the same version of glx and libglu packages from ubuntu xorg-edgers/radeon ppa, too - no change comparing to previous builds.

It looks exactly like bug 28800 which we don't know how to fix.

*** This bug has been marked as a duplicate of bug 28800 ***

(In reply to comment #29)
> It looks exactly like bug 28800 which we don't know how to fix.

Having said that, the corruption I observe with bug 28800 was much reduced by upgrading my kernel from 2.6.34.x to 2.6.35.x. I haven't tried with 2.6.36.x yet.

(In reply to comment #29)
> It looks exactly like bug 28800 which we don't know how to fix.

It's not *exactly* like bug 28800; I don't see anything like this in my dmesg log:

[13255.216618] radeon 0000:01:00.0: object_init failed for (1048576, 0x00000006)
[13255.216631] [drm:radeon_gem_object_create] *ERROR* Failed to allocate GEM object (1048576, 6, 4096, -12)

Also, I see from the glxinfo output that you have S3TC texturing enabled, which presumably implies that you have the libtxc_dxtn.so library installed. So assuming that Xonotic doesn't need S3TC texturing for anything, does uninstalling this library affect the corruption in any way, please?

I have noticed the corruption happens under extreme memory pressure (e.g. ETQW has corrupted textures with 64MB VRAM and the lowest graphics details, but if you have 256MB VRAM, you may see the corruption with the highest details only), so here is my theory.

In the kernel, there is function r100_copy_blit for copying buffers between RAM and VRAM using the 2D engine, and it's hooked up in the TTM. The function is used on r100 up to r500.

I believe switching between the 2D and 3D engine doesn't work as it should or we don't flush some cache or something.

Chris, yours suggestion was right!
I've installed libtxc_dxtn.so some time ago as some apps (games) could use it.
After removing this library the problem with rainbow colors/texture corruption in my case was resolved. The other workaround is to enable option 'Avoid loosy texture compression' in Xonotic menu which disables use of S3TC DDS textures.

And that what Marek has suggested about texture corruption with high detail it was right, too but it didn't look like on those screenshots.
I've found this problem when I've run Xonotic with KDE KWin desktop effects enabled and without libtxc_dxtn.so - not only the big FPS drop but there were many different problems with textures (black textures, black and white textures, black and white noise, screen smoothing with no textures, etc.). Disabling KWin desktop effects + using lower quality textures + removing libtxc_dxtn.so (so it disables GL_EXT_texture_compression_s3tc and GL_S3_s3tc extensions) altogether does make the problem disappear.

And for texture formats that Xonotic needs - it uses JPG and TGA textures but DDS compressed textures, too and I'd like to use them as I could use better quality textures as I think it needs less RAM/VRAM(?) to handle them. And better quality textures compressed as DDS does not make any FPS drop. And most commercial games need S3TC.

So IMO, it does look like it's a duplicate of 28800.

Is there any chance to get this bug with libtxc_dxtn.so fixed to properly handle DDS compressed textures?

I wonder why does S3TC with libtxc_dxtn.so in Xonotic works properly when lightmaps are disabled? I can use better quality DDS textures (without KWin desktop effects) just fine in Xonotic without lightmaps.

Created attachment 39744 [details]
RADEON_DEBUG=tex log

So, the problematic textures are dxt1_rgb and/or dxt1_rgba.

I've done some more testing and I've saw that when I have 60 FPS the problem is gone with S3TC+lightmaps (all textures are OK, no matter what I'm looking at on the map) but when the FPS gets dropped to 30 FPS the problem arrives or when the problem arrives I get FPS drop to 30(?).

I wonder if the problem is with library or the S3TC handling by the driver itself.
I wish I could enable S3TC on r300g without this library (as it could be done with r300c) to check if the textures sent to the card without software recoding library will have simmilar effect.

(In reply to comment #36)
> I wish I could enable S3TC on r300g without this library (as it could be done
> with r300c) to check if the textures sent to the card without software recoding
> library will have simmilar effect.

Have you tested whether the corruption happens with r300c too? It does with WoW (although r300g has fewer other bugs).

Still, I'm glad you at least have a workaround available.

(In reply to comment #32)
> In the kernel, there is function r100_copy_blit for copying buffers between RAM
> and VRAM using the 2D engine, and it's hooked up in the TTM. The function is
> used on r100 up to r500.
> 
> I believe switching between the 2D and 3D engine doesn't work as it should or
> we don't flush some cache or something.

Interesting theory - should this bug now include a title tag for r100-r500 DRM kernel modules?

(In reply to comment #38)
> (In reply to comment #32)
> > In the kernel, there is function r100_copy_blit for copying buffers between RAM
> > and VRAM using the 2D engine, and it's hooked up in the TTM. The function is
> > used on r100 up to r500.
> > 
> > I believe switching between the 2D and 3D engine doesn't work as it should or
> > we don't flush some cache or something.
> 
> Interesting theory - should this bug now include a title tag for r100-r500 DRM
> kernel modules?

Not necessary, it's just a theory. It would be interesting to rewrite that function to use the 3D engine on r300 and see if it fixes anything.

I've done some more testing in spectate mode (so I can go closer to walls, even fly through them) and my theory about 60->30 FPS drop does not work everytime as there are walls which can look at (very close look) where I have 60 FPS and the problem is still there but it might be something with lightning with lightmaps on just s3tc textures. The textures which (always) are not broken (probably not s3tc) when s3tc+lightmaps are enabled on the same map have working lightmaps effect.

(In reply to comment #39)
> Not necessary, it's just a theory. It would be interesting to rewrite that
> function to use the 3D engine on r300 and see if it fixes anything.

A simpler test could be to use r200_copy_dma instead of r100_copy_blit for the .copy hook in radeon_asic.c. (On my mobile RV350 that seems to perform better anyway...)

(In reply to comment #41)
> A simpler test could be to use r200_copy_dma instead of r100_copy_blit for the
> .copy hook in radeon_asic.c. (On my mobile RV350 that seems to perform better
> anyway...)

I replaced r100_copy_blit with r200_copy_dma in both radeon_asic.copy and r300_asic_pcie.copy, but didn't notice any significant difference in the texture corruption. (This was with kernel 2.6.35.6.)

(In reply to comment #37)
> Have you tested whether the corruption happens with r300c too? It does with WoW
> (although r300g has fewer other bugs).

On r300c enabling (in menu) lightmaps effect does not change anything as it could be enabled when GLSL is enabled but on r300c glxinfo reports only:
OpenGL vendor string: DRI R300 Project
OpenGL renderer string: Mesa DRI R300 (RV350 4150) 20090101 x86/MMX/SSE2 TCL DRI2
OpenGL version string: 1.5 Mesa 7.10-devel
(without GLSL)

(In reply to comment #42)
> (In reply to comment #41)
> > A simpler test could be to use r200_copy_dma instead of r100_copy_blit for the
> > .copy hook in radeon_asic.c. (On my mobile RV350 that seems to perform better
> > anyway...)
> 
> I replaced r100_copy_blit with r200_copy_dma in both radeon_asic.copy and
> r300_asic_pcie.copy, but didn't notice any significant difference in the
> texture corruption. (This was with kernel 2.6.35.6.)

OK, thanks for testing.

(In reply to comment #42)
> I replaced r100_copy_blit with r200_copy_dma in both radeon_asic.copy and
> r300_asic_pcie.copy, but didn't notice any significant difference in the
> texture corruption. (This was with kernel 2.6.35.6.)

Assuming that's with your AGP RV350, r300_asic.copy is used. Did you mean that instead of radeon_asic.copy?

(In reply to comment #45)
> Assuming that's with your AGP RV350, r300_asic.copy is used. Did you mean that
> instead of radeon_asic.copy?

Yes, I meant r300_asic.copy really. (Sorry, typo...)