Bug 30960 - [r300g][glsl][libtxc_dxtn] Texture corruption in Xonotic with lightmaps
Summary: [r300g][glsl][libtxc_dxtn] Texture corruption in Xonotic with lightmaps
Status: RESOLVED DUPLICATE of bug 28800
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/Gallium/r300 (show other bugs)
Version: git
Hardware: x86 (IA32) Linux (All)
: medium normal
Assignee: Default DRI bug account
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-10-18 05:42 UTC by Tomasz Czapiewski
Modified: 2010-10-26 01:29 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
Screenshot of lightmaps corruption (169.70 KB, image/jpeg)
2010-10-18 05:42 UTC, Tomasz Czapiewski
Details
Screenshot of lightmaps corruption #2 (ignore the error messages on top and white rectangle - it's fixed in tommorows build) (186.09 KB, image/jpeg)
2010-10-18 05:45 UTC, Tomasz Czapiewski
Details
Screenshot of lightmaps corruption #3 (125.06 KB, image/jpeg)
2010-10-18 05:46 UTC, Tomasz Czapiewski
Details
dmesg (124.10 KB, text/plain)
2010-10-18 15:54 UTC, Tomasz Czapiewski
Details
glxinfo (23.49 KB, text/plain)
2010-10-18 15:55 UTC, Tomasz Czapiewski
Details
Xorg.0.log (53.06 KB, text/plain)
2010-10-18 15:56 UTC, Tomasz Czapiewski
Details
GLSL shader dump from the game (47.53 KB, text/plain)
2010-10-18 16:03 UTC, Tomasz Czapiewski
Details
RADEON_DEBUG=fp,vp (STDERR log) (461.39 KB, text/plain)
2010-10-19 09:16 UTC, Tomasz Czapiewski
Details
RADEON_DEBUG=fp,vp (STDOUT [game] log) (58.74 KB, text/plain)
2010-10-19 09:17 UTC, Tomasz Czapiewski
Details
Screenshot during logs grab xonotic000001.jpg (184.29 KB, image/jpeg)
2010-10-19 09:20 UTC, Tomasz Czapiewski
Details
Screenshot during logs grab xonotic000002.jpg (135.32 KB, image/jpeg)
2010-10-19 09:21 UTC, Tomasz Czapiewski
Details
Screenshot during logs grab xonotic000003.jpg (195.62 KB, image/jpeg)
2010-10-19 09:22 UTC, Tomasz Czapiewski
Details
Screenshot during logs grab xonotic000004.jpg (146.79 KB, image/jpeg)
2010-10-19 09:23 UTC, Tomasz Czapiewski
Details
Screenshot during logs grab xonotic000005.jpg (111.82 KB, image/jpeg)
2010-10-19 09:24 UTC, Tomasz Czapiewski
Details
Screenshot during logs grab xonotic000006.jpg (153.14 KB, image/jpeg)
2010-10-19 09:25 UTC, Tomasz Czapiewski
Details
RADEON_DEBUG=fp,vp + game log 2>&1 merged (393.99 KB, text/plain)
2010-10-19 09:33 UTC, Tomasz Czapiewski
Details
Screenshot during merged logs grab xonotic000008.jpg (141.30 KB, image/jpeg)
2010-10-19 09:34 UTC, Tomasz Czapiewski
Details
Screenshot during merged logs grab xonotic000009.jpg (159.15 KB, image/jpeg)
2010-10-19 09:35 UTC, Tomasz Czapiewski
Details
Screenshot during merged logs grab xonotic000010.jpg (201.09 KB, image/jpeg)
2010-10-19 09:35 UTC, Tomasz Czapiewski
Details
RADEON_DEBUG=fp,vp +game log lightmaps+deluxemapping (411.71 KB, text/plain)
2010-10-19 09:50 UTC, Tomasz Czapiewski
Details
Screenshot during merged logs grab lightmap+deluxemapping xonotic000011.jpg (155.61 KB, image/jpeg)
2010-10-19 09:51 UTC, Tomasz Czapiewski
Details
Screenshot during merged logs grab lightmap+deluxemapping xonotic000012.jpg (190.15 KB, image/jpeg)
2010-10-19 09:51 UTC, Tomasz Czapiewski
Details
Screenshot during merged logs grab lightmap+deluxemapping xonotic000013.jpg (136.31 KB, image/jpeg)
2010-10-19 09:52 UTC, Tomasz Czapiewski
Details
RADEON_DEBUG=tex log (88.68 KB, application/octet-stream)
2010-10-24 13:50 UTC, Tomasz Czapiewski
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Tomasz Czapiewski 2010-10-18 05:42:49 UTC
Created attachment 39504 [details]
Screenshot of lightmaps corruption

Testing procedure:

1. Download Xonotic (Nexuiz fork) from http://beta.xonotic.org/autobuild/Xonotic-20101017.zip (login: xonotic, pass: g-23) (could be newer build, too)
2. Unzip and run ./xonotic-linux-glx.sh
3. Enable GLSL in video menu
4. Enable "Use lightmaps" in effects menu
5. Connect to any server.

Lightmaps do texture corruption in r300g as seen on screenshots. 
Textures are rendered properly for example on Nvidia binary driver on Nvidia hardware.
My graphic card: ATI Radeon 9600 256MB AGP (RV350).
Comment 1 Tomasz Czapiewski 2010-10-18 05:45:21 UTC
Created attachment 39505 [details]
Screenshot of lightmaps corruption #2 (ignore the error messages on top and white rectangle - it's fixed in tommorows build)
Comment 2 Tomasz Czapiewski 2010-10-18 05:46:13 UTC
Created attachment 39506 [details]
Screenshot of lightmaps corruption #3
Comment 3 Tomasz Czapiewski 2010-10-18 14:26:06 UTC
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.
Comment 4 Tomasz Czapiewski 2010-10-18 14:36:25 UTC
And the problem is gone when I disable GLSL.
Comment 5 Tomasz Czapiewski 2010-10-18 15:54:38 UTC
Created attachment 39521 [details]
dmesg
Comment 6 Tomasz Czapiewski 2010-10-18 15:55:07 UTC
Created attachment 39522 [details]
glxinfo
Comment 7 Tomasz Czapiewski 2010-10-18 15:56:30 UTC
Created attachment 39523 [details]
Xorg.0.log
Comment 8 Tomasz Czapiewski 2010-10-18 16:03:37 UTC
Created attachment 39524 [details]
GLSL shader dump from the game
Comment 9 Tom Stellard 2010-10-18 20:51:33 UTC
Can you run the program with RADEON_DEBUG=fp,vp and post the output?
Comment 10 Tomasz Czapiewski 2010-10-19 09:16:47 UTC
Created attachment 39531 [details]
RADEON_DEBUG=fp,vp (STDERR log)
Comment 11 Tomasz Czapiewski 2010-10-19 09:17:32 UTC
Created attachment 39532 [details]
RADEON_DEBUG=fp,vp (STDOUT [game] log)
Comment 12 Tomasz Czapiewski 2010-10-19 09:20:59 UTC
Created attachment 39533 [details]
Screenshot during logs grab xonotic000001.jpg
Comment 13 Tomasz Czapiewski 2010-10-19 09:21:53 UTC
Created attachment 39534 [details]
Screenshot during logs grab xonotic000002.jpg
Comment 14 Tomasz Czapiewski 2010-10-19 09:22:56 UTC
Created attachment 39535 [details]
Screenshot during logs grab xonotic000003.jpg
Comment 15 Tomasz Czapiewski 2010-10-19 09:23:51 UTC
Created attachment 39536 [details]
Screenshot during logs grab xonotic000004.jpg
Comment 16 Tomasz Czapiewski 2010-10-19 09:24:45 UTC
Created attachment 39537 [details]
Screenshot during logs grab xonotic000005.jpg
Comment 17 Tomasz Czapiewski 2010-10-19 09:25:41 UTC
Created attachment 39538 [details]
Screenshot during logs grab xonotic000006.jpg
Comment 18 Tomasz Czapiewski 2010-10-19 09:33:44 UTC
Created attachment 39539 [details]
RADEON_DEBUG=fp,vp + game log 2>&1 merged
Comment 19 Tomasz Czapiewski 2010-10-19 09:34:38 UTC
Created attachment 39540 [details]
Screenshot during merged logs grab xonotic000008.jpg
Comment 20 Tomasz Czapiewski 2010-10-19 09:35:22 UTC
Created attachment 39541 [details]
Screenshot during merged logs grab xonotic000009.jpg
Comment 21 Tomasz Czapiewski 2010-10-19 09:35:56 UTC
Created attachment 39542 [details]
Screenshot during merged logs grab xonotic000010.jpg
Comment 22 Tomasz Czapiewski 2010-10-19 09:50:42 UTC
Created attachment 39544 [details]
RADEON_DEBUG=fp,vp +game log lightmaps+deluxemapping
Comment 23 Tomasz Czapiewski 2010-10-19 09:51:36 UTC
Created attachment 39545 [details]
Screenshot during merged logs grab lightmap+deluxemapping xonotic000011.jpg
Comment 24 Tomasz Czapiewski 2010-10-19 09:51:57 UTC
Created attachment 39546 [details]
Screenshot during merged logs grab lightmap+deluxemapping xonotic000012.jpg
Comment 25 Tomasz Czapiewski 2010-10-19 09:52:23 UTC
Created attachment 39547 [details]
Screenshot during merged logs grab lightmap+deluxemapping xonotic000013.jpg
Comment 26 Tom Stellard 2010-10-19 23:42:04 UTC
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.
Comment 27 Tomasz Czapiewski 2010-10-20 12:54:15 UTC
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.
Comment 28 Tomasz Czapiewski 2010-10-20 12:57:52 UTC
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.
Comment 29 Marek Olšák 2010-10-23 18:38:37 UTC
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 ***
Comment 30 Chris Rankin 2010-10-24 05:28:23 UTC
(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.
Comment 31 Chris Rankin 2010-10-24 05:50:23 UTC
(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?
Comment 32 Marek Olšák 2010-10-24 09:32:51 UTC
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.
Comment 33 Tomasz Czapiewski 2010-10-24 13:08:36 UTC
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?
Comment 34 Tomasz Czapiewski 2010-10-24 13:16:39 UTC
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.
Comment 35 Tomasz Czapiewski 2010-10-24 13:50:49 UTC
Created attachment 39744 [details]
RADEON_DEBUG=tex log
Comment 36 Tomasz Czapiewski 2010-10-24 14:00:47 UTC
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.
Comment 37 Chris Rankin 2010-10-24 15:27:17 UTC
(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.
Comment 38 Chris Rankin 2010-10-24 15:31:05 UTC
(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?
Comment 39 Marek Olšák 2010-10-24 15:38:54 UTC
(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.
Comment 40 Tomasz Czapiewski 2010-10-24 22:16:30 UTC
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.
Comment 41 Michel Dänzer 2010-10-25 01:14:35 UTC
(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...)
Comment 42 Chris Rankin 2010-10-25 13:42:16 UTC
(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.)
Comment 43 Tomasz Czapiewski 2010-10-25 14:14:02 UTC
(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)
Comment 44 Marek Olšák 2010-10-25 14:15:10 UTC
(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.
Comment 45 Michel Dänzer 2010-10-26 00:31:06 UTC
(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?
Comment 46 Chris Rankin 2010-10-26 01:29:24 UTC
(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...)


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.