I noticed with current mesa master a visual corruption with the game panzers 2. This is a regression to current git on 7.6 branch where it works fine. I tried a bisect but I get many other bugs (compile errors, r300 segfaults, game crashes that are fixed with mesa master) while doing that and I cannot find the bugged commit. However I suspect the bug appeared around the merging of texformat-rework branch. My card: Mesa DRI R300 (RV530 71C5) 20090101 x86/MMX/SSE2 TCL I also attach a screenshot of the problem: note that the white in the image sometime change to red or blue or dark.
Created attachment 31090 [details] Screenshot of corruption
Please compile mesa with --enable-debug option, and attach full app output.
Created attachment 31733 [details] full console output with mesa *7.6* compiled with --enable-debug and with KMS -> it works fine
Created attachment 31734 [details] full console output with mesa *7.7* compiled with --enable-debug and with KMS -> textures are missing/corrupted
OK I tried again commit around the merge of texformat-rework branch, now with KMS (where the crash bug was not reproducible). It's working fine up to the previous commit: http://cgit.freedesktop.org/mesa/mesa/commit/?h=mesa_7_7_branch&id=0ea575d721821262a862ceef010db9b1a8b4a6d9 The following commit is the merge of the texformat-rework branch and here textures are missing/corrupted: http://cgit.freedesktop.org/mesa/mesa/commit/?h=mesa_7_7_branch&id=1f196b786d6bd0c6a5dbdc638574ff716cc3d4de
I'm taking a quick look at the diffs between 0ea575d721821262a862ceef010db9b1a8b4a6d9 and 1f196b786d6bd0c6a5dbdc638574ff716cc3d4de One thing that looks suspicious is the VALID_FORMAT() macro used in the radeon/r200/r300/etc drivers. I have no idea what it's supposed to do, but it depends on the order/value of the MESA_FORMAT_x tokens. That's pretty fragile. The order of the formats may have changed a bit on the texformat-rework branch. Also, the tx_table[] array is indexed with a MESA_FORMAT_x value so it depends on the MESA_FORMAT_x enums never changing (again, fragile). This should probably be converted into a switch/case in a utility function. Maybe one of the radeon developers can look into this.
(In reply to comment #6) > I'm taking a quick look at the diffs between > 0ea575d721821262a862ceef010db9b1a8b4a6d9 and > 1f196b786d6bd0c6a5dbdc638574ff716cc3d4de > > One thing that looks suspicious is the VALID_FORMAT() macro used in the > radeon/r200/r300/etc drivers. I have no idea what it's supposed to do, but it > depends on the order/value of the MESA_FORMAT_x tokens. That's pretty fragile. > The order of the formats may have changed a bit on the texformat-rework > branch. > > Also, the tx_table[] array is indexed with a MESA_FORMAT_x value so it depends > on the MESA_FORMAT_x enums never changing (again, fragile). This should > probably be converted into a switch/case in a utility function. > > Maybe one of the radeon developers can look into this. > I'll look into it.
Created attachment 31756 [details] proposed patch Fabio: Could you try this patch?
> Could you try this patch? It's still the same with the patch.
Can you check current mesa master?
> Can you check current mesa master? The problem persists, tried with both UMS/KMS.
(In reply to comment #11) > > Can you check current mesa master? > > The problem persists, tried with both UMS/KMS. > It works with the 7.7 branch now, however!
(In reply to comment #12) > (In reply to comment #11) > > > Can you check current mesa master? > > > > The problem persists, tried with both UMS/KMS. > > > > It works with the 7.7 branch now, however! > Ah, right. I was meant to tell you to try the 7.7 branch not the master. Can you confirm it's the f1900323ea1 "r300: fix depth textures" commit that fixed it?
> Ah, right. I was meant to tell you to try the 7.7 branch not the master. Can > you confirm it's the f1900323ea1 "r300: fix depth textures" commit that fixed > it? Confirmed. Thanks for all this nice work!
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.