https://bugs.freedesktop.org/show_bug.cgi?id=28800
Summary: [r300c] Texture corruption with World of Warcraft Product: Mesa Version: git Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/r300 AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: rankincj@googlemail.com
Created an attachment (id=36583) --> (https://bugs.freedesktop.org/attachment.cgi?id=36583) Screenshot of corrupt textures
A large number of textures are rendered incorrectly in World of Warcraft. (The game appears otherwise stable and moderately playable, although the frame rate isn't particularly high.)
This is with an AGP RV350, running Linux 2.6.33.5, xorg-xf86-drv-ati from git and Fedora 13.
My theory is that this is related to bug 28033, which has been fixed for r300g. However it is impossible to confirm this due to WoW crashing with r300g before I can enter the game. (See bug 28630.)
https://bugs.freedesktop.org/show_bug.cgi?id=28800
--- Comment #1 from Chris Rankin rankincj@googlemail.com 2010-06-30 15:34:47 PDT --- Created an attachment (id=36647) --> (https://bugs.freedesktop.org/attachment.cgi?id=36647) Similarly broken textures with r300g
Now that I can run Warcraft under Gallium, I can see that some of the textures are broken in the same way as with r300c. However, the breakage doesn't seem so extreme with r300g as it does with r300c.
https://bugs.freedesktop.org/show_bug.cgi?id=28800
Chris Rankin rankincj@googlemail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|[r300c] Texture corruption |[r300c, r300g] Texture |with World of Warcraft |corruption with World of | |Warcraft
https://bugs.freedesktop.org/show_bug.cgi?id=28800
--- Comment #2 from Chris Rankin rankincj@googlemail.com 2010-07-06 12:33:59 PDT --- I tried running WoW with the RADEON_DEBUG="tex" option, and noticed that many textures were in formats:
dxt1_rgba dxt3_rgba dxt5_rgba
And so because I am also using libtxc_dxtn070518.tar.gz, I moved the libtxc_dxtn.so object out of /usr/lib and tried running WoW again. And this time, the textures were all fine... right up until WoW crashed a few seconds later.
From this I conclude that:
a) Both r300c and r300g have difficulty with compressed textures, and b) r300g also has a more serious problem with b8g8r8a8_unorm, b4g4r4a4_unorm, b5g6r5_unorm textures (and possibly others), because these are what WoW uses when compressed texture support isn't available.
https://bugs.freedesktop.org/show_bug.cgi?id=28800
--- Comment #3 from Marek Olšák maraeo@gmail.com 2010-07-06 14:33:08 PDT --- Can you obtain a backtrace of the crash?
https://bugs.freedesktop.org/show_bug.cgi?id=28800
--- Comment #4 from Chris Rankin rankincj@googlemail.com 2010-07-06 14:40:14 PDT --- (In reply to comment #3)
Can you obtain a backtrace of the crash?
The crash seems to happen within WoW itself, which suggests to me that WoW *needs* S3TC textures to run correctly. I get the exact same crash when I remove libtxc_dxtn.so from r300c too.
r300: texture_create: Macro: NO, Micro: NO, Pitch: 128, Dim: 128x8x0, LastLevel: 0, Size: 4096, Format: b8g8r8a8_unorm r300: texture_create: Macro: NO, Micro: NO, Pitch: 8, Dim: 8x64x0, LastLevel: 0, Size: 2048, Format: b8g8r8a8_unorm wine: Unhandled page fault on read access to 0x00000000 at address (nil) (thread 0009), starting debugger... Unhandled exception: page fault on read access to 0x00000000 in 32-bit code (0x00000000).
Register dump: CS:0073 SS:007b DS:007b ES:007b FS:0033 GS:003b EIP:00000000 ESP:0196fd04 EBP:0196fd64 EFLAGS:00210246( R- -- I Z- -P- ) EAX:000083f1 EBX:00008000 ECX:00000de1 EDX:0cf0ece0 ESI:00000000 EDI:0c37c558 Stack dump: 0x0196fd04: 0069de43 00000de1 00000000 000083f1 0x0196fd14: 00000100 00000100 00000000 00008000 0x0196fd24: 0cf0ece0 00000100 0c37c558 00000100 0x0196fd34: 00000000 00000000 00000100 00000100 0x0196fd44: 0000813d 00000008 00000000 00000200 0x0196fd54: 0cf16ce0 00008000 0cf0ece0 000083f1 Backtrace: =>0 0x00000000 (0x0196fd64) 1 0x0069e078 in wow (+0x29e077) (0x0196fdbc)
Ouch.
https://bugs.freedesktop.org/show_bug.cgi?id=28800
--- Comment #5 from Chris Rankin rankincj@googlemail.com 2010-07-11 16:17:50 PDT --- (In reply to comment #3)
Can you obtain a backtrace of the crash?
With r300c, I can remove the libtxc_dtxn.so library but set a flag in my .drirc file instead:
<option name="force_s3tc_enable" value="true" />
This adds the GL_EXT_texture_compression_s3tc and GL_S3_s3tc extensions back, and is enough to stop WoW crashing with r300c. However, this <option/> does not work with r300g. Is there an equivalent option with a different name for r300g instead, please?
Note that the texture corruption is still present with r300c, even with the libtxc_dtxn.so library removed. However, it would be interesting to test r300g as well.
https://bugs.freedesktop.org/show_bug.cgi?id=28800
--- Comment #6 from Marek Olšák maraeo@gmail.com 2010-07-11 17:33:51 PDT --- There is nothing I can do about a crash in WoW and not in the driver, though I believe WoW without S3TC has not been tested by Blizzard QA because there are no Windows drivers that do not advertise S3TC.
I don't think there is an equivalent to force_s3tc_enable in Gallium, and I think the presence of libtxc_dxtn has nothing to do with the texture corruption issue.
Now let's get back on topic.
There are two issues regarding the corrupted textures on r3xx-r4xx.
1) Assigning texture cache regions. This was fixed in r300g some time ago.
2) Occasional texture corruption which seems to be triggered by some other state (e.g. a soldier entering the view). This is a bug in r300g, at least. It's a real mystery to me.
https://bugs.freedesktop.org/show_bug.cgi?id=28800
--- Comment #7 from Chris Rankin rankincj@googlemail.com 2010-07-12 01:15:18 PDT --- (In reply to comment #6)
There is nothing I can do about a crash in WoW and not in the driver, though I believe WoW without S3TC has not been tested by Blizzard QA because there are no Windows drivers that do not advertise S3TC.
The WoWWiki documents WoW as *needing* S3TC textures: http://www.wowwiki.com/BLP_files
The crash is almost certainly to do with WoW using one of the S3TC extensions without checking whether the driver supports it first.
I don't think there is an equivalent to force_s3tc_enable in Gallium,
Then I'll raise that as a separate bug, because WoW is going to need the S3TC extensions to be advertised, and some people might not be able to use the IP-encumbered libtxc_dxtn library.
and I think the presence of libtxc_dxtn has nothing to do with the texture corruption issue.
I'm not so sure about that. The remaining texture corruption only happens in certain *locations*. It has nothing to do with NPCs appearing on screen. More interestingly, none of these locations is in "The Burning Crusade" expansion, where DXT5 compression was apparently used for the first time. (See link above.)
The final interesting observation was that when I uninstalled libtxc_dxtn and tried playing WoW with r300g, the expected texture corruption was not present for those few seconds before the game crashed. This is another reason why I am interested in a force_s3tc_enable for Gallium: to see whether the corruption reappears if I can avoid the crash. (Failing that, at least to eliminate a blob of unmaintained code as the cause of the problem.)
https://bugs.freedesktop.org/show_bug.cgi?id=28800
--- Comment #8 from Chris Rankin rankincj@googlemail.com 2010-07-12 14:08:46 PDT --- Created an attachment (id=36972) --> (https://bugs.freedesktop.org/attachment.cgi?id=36972) Corruption from first angle
Have I mentioned that this texture corruption varies with the player's "camera angle"? You'll notice that the corruption here has very linear boundaries, and square patterns within those boundaries. But those boundaries change as I rotate my character around.
https://bugs.freedesktop.org/show_bug.cgi?id=28800
--- Comment #9 from Chris Rankin rankincj@googlemail.com 2010-07-12 14:10:28 PDT --- Created an attachment (id=36973) --> (https://bugs.freedesktop.org/attachment.cgi?id=36973) Corruption from the second angle
After a quick turn to my right...
https://bugs.freedesktop.org/show_bug.cgi?id=28800
--- Comment #10 from Chris Rankin rankincj@googlemail.com 2010-07-12 14:12:18 PDT --- Created an attachment (id=36974) --> (https://bugs.freedesktop.org/attachment.cgi?id=36974) Corruption from a third angle
A further turn to the right, and "eyes down" a bit too.
https://bugs.freedesktop.org/show_bug.cgi?id=28800
--- Comment #11 from Marek Olšák maraeo@gmail.com 2010-08-01 18:19:22 PDT --- Created an attachment (id=37512) View: https://bugs.freedesktop.org/attachment.cgi?id=37512 Review: https://bugs.freedesktop.org/review?bug=28800&attachment=37512
possible workaround
Could you try this patch?
https://bugs.freedesktop.org/show_bug.cgi?id=28800
--- Comment #12 from Chris Rankin rankincj@googlemail.com 2010-08-02 13:48:41 PDT --- (In reply to comment #11)
Could you try this patch?
Sorry, that made no difference.
https://bugs.freedesktop.org/show_bug.cgi?id=28800
--- Comment #13 from Chris Rankin rankincj@googlemail.com 2010-08-02 17:25:43 PDT --- I have just upgraded this machine from 2.6.33.6 to 2.6.34.2 and have discovered that the texture corruption is now *massively* reduced. There are still artifacts here and there if I look closely, but the large blocks of mangled textures have gone!
Switching back to 2.6.33.6 makes the corruption reappear.
I'm stunned. I should probably also mention now that I am using KMS.
https://bugs.freedesktop.org/show_bug.cgi?id=28800
Marek Olšák maraeo@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |aaalmosss@gmail.com
--- Comment #14 from Marek Olšák maraeo@gmail.com 2010-08-05 16:39:34 PDT --- *** Bug 28993 has been marked as a duplicate of this bug. ***
https://bugs.freedesktop.org/show_bug.cgi?id=28800
--- Comment #15 from Marek Olšák maraeo@gmail.com 2010-08-05 16:44:32 PDT --- I have tried everything in r300g. Flushing and invalidating all caches, flushing command stream after every draw operation and re-emitting all state, nothing helps.
Chris, considering what you say, I think this is a kernel issue, not an r300g issue.
https://bugs.freedesktop.org/show_bug.cgi?id=28800
Marek Olšák maraeo@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|Drivers/DRI/r300 |Drivers/Gallium/r300
https://bugs.freedesktop.org/show_bug.cgi?id=28800
Marek Olšák maraeo@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |xeros@irc.pl
--- Comment #16 from Marek Olšák maraeo@gmail.com 2010-10-23 18:38:37 PDT --- *** Bug 30960 has been marked as a duplicate of this bug. ***
https://bugs.freedesktop.org/show_bug.cgi?id=28800
--- Comment #17 from Tomasz Czapiewski xeros@irc.pl 2010-10-24 14:15:19 PDT --- (In reply to comment #16)
*** Bug 30960 has been marked as a duplicate of this bug. ***
I've made some comments in this duplicate... Should I comment later here or in my duplicate?
Considering that WoW is closed source and could not be easily debugged, Xonotic is open source game and it's developers might be helpful to give usefull information from game code, too. And now I know that there, the problem appears only with lightmaps+s3tc textures and without lightmaps the s3tc textures work just fine there (Xonotic).
https://bugs.freedesktop.org/show_bug.cgi?id=28800
--- Comment #18 from Chris Rankin rankincj@googlemail.com 2010-11-29 15:25:54 PST --- (In reply to comment #15)
Chris, considering what you say, I think this is a kernel issue, not an r300g issue.
I have a T60p with an internal M66 (~ RV530) chip, and have tested it against the exact same version of Mesa as my RV350. The RV350 still has this issue, but the M66 does not.
(Not a perfect test, mind. The M66 is using Linux 2.6.36.1 whereas the RV350 is still using 2.6.35.9, but both are running Fedora 14 userspace with xorg-drv-ati from git.)
https://bugs.freedesktop.org/show_bug.cgi?id=28800
--- Comment #19 from Álmos aaalmosss@gmail.com 2010-12-03 13:27:04 PST --- I don't know if this information helps, but this corruption also appears on the water in google earth, if there is a semi-transparent icon over it (like the one for a shipwreck). If I set the view so that only one such icon is visible, and move the cursor over it, the icon becomes solid, and the glitch disappears. The viewport change indicator cursor (appearing while holding down the right or middle mouse button) also triggers this glitch, if the cursor is over an area, where water is drawn. Checking/unchecking the texture compression option doesn't change anything, maybe it's a no-op if s3tc is available...
To Chris: I believe it was already known that this glitch is only present with pre-r500 cards (maybe due to vram sizes), but now that I checked the other bugreports about it, I discovered that all reporters have rv350. Coincidence?
https://bugs.freedesktop.org/show_bug.cgi?id=28800
--- Comment #20 from Álmos aaalmosss@gmail.com 2010-12-16 06:12:18 PST --- Created an attachment (id=41170) View: https://bugs.freedesktop.org/attachment.cgi?id=41170 Review: https://bugs.freedesktop.org/review?bug=28800&attachment=41170
r300g_multitexturing.diff
I played around with the tmu texture cache region assignment code, read the corresponding part of the r3xx register manual, and deduced the following: - you must assign different region for different textures - assigned regions must not overlap The existing code guarantees none of these, especially if there are partial updates (which are quite common). The texture corruption is the result of the tmu loading different textures into the same cache area (possibly in different formats), and only one of them won't be garbage. This only applies to r3xx and r4xx, because r5xx ignores this parameter and assigns cache automatically.
My patch doesn't guarantee anything either, is meant to be a proof-of-concept (or more like a hackload of hacky hacks), that almost completely fixes texturing in ut2004, vastly improves the situation in etqw (the corruption occurs only on strogg architecture and vehicles instead of almost everywhere), and changes nothing in googleearth. Doom3 would also be a good test, but it crashes since I increased GART from 64MB to 256MB.
https://bugs.freedesktop.org/show_bug.cgi?id=28800
--- Comment #21 from Marek Olšák maraeo@gmail.com 2010-12-16 07:00:56 PST --- (In reply to comment #20)
Created an attachment (id=41170)
View: https://bugs.freedesktop.org/attachment.cgi?id=41170 Review: https://bugs.freedesktop.org/review?bug=28800&attachment=41170
r300g_multitexturing.diff
I played around with the tmu texture cache region assignment code, read the corresponding part of the r3xx register manual, and deduced the following:
- you must assign different region for different textures
- assigned regions must not overlap
The existing code guarantees none of these, especially if there are partial updates (which are quite common). The texture corruption is the result of the tmu loading different textures into the same cache area (possibly in different formats), and only one of them won't be garbage.
Thanks a lot for looking into this, but let's discuss it a bit.
Could you give me a prove that the current code is wrong? At least one case where the assignment of texture cache regions is done wrong.
Currently it should assign the regions as follows:
1 texture: R300_TX_CACHE_WHOLE
2 textures: R300_TX_CACHE_HALF_0 R300_TX_CACHE_HALF_1
3 textures: R300_TX_CACHE_HALF_1 R300_TX_CACHE_FOURTH_0 R300_TX_CACHE_FOURTH_1
4 textures: R300_TX_CACHE_FOURTH_0 R300_TX_CACHE_FOURTH_1 R300_TX_CACHE_FOURTH_2 R300_TX_CACHE_FOURTH_3
5 textures: R300_TX_CACHE_FOURTH_1 R300_TX_CACHE_FOURTH_2 R300_TX_CACHE_FOURTH_3 R300_TX_CACHE_EIGHTH_0 R300_TX_CACHE_EIGHTH_1
6 textures: R300_TX_CACHE_FOURTH_2 R300_TX_CACHE_FOURTH_3 R300_TX_CACHE_EIGHTH_0 R300_TX_CACHE_EIGHTH_1 R300_TX_CACHE_EIGHTH_2 R300_TX_CACHE_EIGHTH_3
7 textures: R300_TX_CACHE_FOURTH_3 R300_TX_CACHE_EIGHTH_0 R300_TX_CACHE_EIGHTH_1 R300_TX_CACHE_EIGHTH_2 R300_TX_CACHE_EIGHTH_3 R300_TX_CACHE_EIGHTH_4 R300_TX_CACHE_EIGHTH_5
8 textures: R300_TX_CACHE_EIGHTH_0 R300_TX_CACHE_EIGHTH_1 R300_TX_CACHE_EIGHTH_2 R300_TX_CACHE_EIGHTH_3 R300_TX_CACHE_EIGHTH_4 R300_TX_CACHE_EIGHTH_5 R300_TX_CACHE_EIGHTH_6 R300_TX_CACHE_EIGHTH_7
And so on. I can't see any overlapping regions. It always divides the whole texture cache between all the textures. The code assumes each region can be divided to two of half the size of the original one. E.g. the case with 2 textures is:
R300_TX_CACHE_HALF_0 R300_TX_CACHE_HALF_1
And when you add the 3rd texture, the first region will get divided evenly like this:
R300_TX_CACHE_FOURTH_0 R300_TX_CACHE_FOURTH_1 R300_TX_CACHE_HALF_1
Does it look wrong to you? Do you think that the hardware doesn't like so _tight_ configuration of the regions?
https://bugs.freedesktop.org/show_bug.cgi?id=28800
Álmos aaalmosss@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #41170|0 |1 is obsolete| |
--- Comment #22 from Álmos aaalmosss@gmail.com 2010-12-16 15:18:11 PST --- Created an attachment (id=41192) View: https://bugs.freedesktop.org/attachment.cgi?id=41192 Review: https://bugs.freedesktop.org/review?bug=28800&attachment=41192
r300g_multitexturing_v2.diff
Yes, your calculations are OK. The problem is the if (&state->sampler_views[i]->base != views[i]) {} part, which leaves some samplers untouched, and their cache regions get reused sometimes.
My attached patch is IMHO significantly better than the previous one. It completely fixes texturing in etqw, but there are occasional glitches in ut2004 and the water in googleearth is still bad. See the TODO and XXX comments in the patch for more explanation.
https://bugs.freedesktop.org/show_bug.cgi?id=28800
--- Comment #23 from Chris Rankin rankincj@googlemail.com 2010-12-16 16:37:34 PST --- (In reply to comment #22)
My attached patch is IMHO significantly better than the previous one.
The patch may be flawed, but it greatly improves WoW as well. I've just run around a couple of "texture hotspots" without noticing any problems, although the console log has been warning me of "trouble ahead" a fair bit as well.
I would say that the patch is definitely heading in the correct general direction. (Although it doesn't apply cleanly to git. Perhaps it was made against altered sources?)
https://bugs.freedesktop.org/show_bug.cgi?id=28800
--- Comment #24 from Marek Olšák maraeo@gmail.com 2010-12-17 00:11:49 PST --- Created an attachment (id=41199) View: https://bugs.freedesktop.org/attachment.cgi?id=41199 Review: https://bugs.freedesktop.org/review?bug=28800&attachment=41199
possible fix
(In reply to comment #22)
Yes, your calculations are OK. The problem is the if (&state->sampler_views[i]->base != views[i]) {} part, which leaves some samplers untouched, and their cache regions get reused sometimes.
Well spotted! Could you guys please test this patch? I've just removed the conditional.
https://bugs.freedesktop.org/show_bug.cgi?id=28800
--- Comment #25 from Álmos aaalmosss@gmail.com 2010-12-17 03:07:50 PST --- The 'possible fix' patch fixes everything, and is far superior to my attempts (somehow I thought that if is important). Please commit it.
https://bugs.freedesktop.org/show_bug.cgi?id=28800
Marek Olšák maraeo@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED
--- Comment #26 from Marek Olšák maraeo@gmail.com 2010-12-17 04:20:44 PST --- The 'if' was an optimization from the days before the texture cache partitioning was implemented.
Again, thanks a lot.
Committed to master and closing the bug.. (finally!)
https://bugs.freedesktop.org/show_bug.cgi?id=28800
--- Comment #27 from Chris Rankin rankincj@googlemail.com 2010-12-19 13:37:27 PST --- (In reply to comment #26)
Committed to master and closing the bug.. (finally!)
Yes, this fixes Warcraft too. Thanks, everyone :-) !!
dri-devel@lists.freedesktop.org
-
bugzilla-daemon＠freedesktop.org