Bug 34030 - [bisected] Starcraft 2: some effects are corrupted or too big
[bisected] Starcraft 2: some effects are corrupted or too big
Status: RESOLVED FIXED
Product: Mesa
Classification: Unclassified
Component: Drivers/Gallium/r300
git
Other All
: medium minor
Assigned To: Default DRI bug account
: regression
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-02-08 04:15 UTC by Pavel Ondračka
Modified: 2011-02-11 20:07 UTC (History)
0 users

See Also:


Attachments
screenshot of the problem (266.70 KB, image/jpeg)
2011-02-08 04:15 UTC, Pavel Ondračka
Details
screenshot without corruption for comparison (262.58 KB, image/jpeg)
2011-02-08 04:17 UTC, Pavel Ondračka
Details
output of RADEON_DEBUG=fp,vp with mesa master (233.87 KB, application/x-bzip2)
2011-02-09 00:34 UTC, Pavel Ondračka
Details
output of RADEON_DEBUG=fp,vp with mesa master and 8f32c6cfc6503dd234f09fb06941803866c23c65 reverted (223.96 KB, application/x-bzip2)
2011-02-09 00:35 UTC, Pavel Ondračka
Details
Possible Fix (1.20 KB, patch)
2011-02-09 01:46 UTC, Tom Stellard
Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Pavel Ondračka 2011-02-08 04:15:26 UTC
Created attachment 43092 [details]
screenshot of the problem

With latest mesa git there are some messed up effects in Starcraft 2 (harvesting drones, vespene geysers, and some surfaces have solid background color insted transparent). This is with Wine 1.3.13 and GLSL disabled in Wine. (GLSL codepath works fine)

I did a regression test:
68b701f5ded5f6b73a6b07cf37d862fab4836607 is the first bad commit
commit 68b701f5ded5f6b73a6b07cf37d862fab4836607
Author: Tom Stellard <tstellar@gmail.com>
Date:   Sat Feb 5 22:39:58 2011 -0800

    r300/compiler: Disable register rename pass on r500
    
    The scheduler and the register allocator are not good enough yet to deal
    with the effects of the register rename pass.  This was causing a 50%
    performance drop in Lightsmark.  The pass can be re-enabled once the
    scheduler and the register allocator are more mature.  r300 and r400
    still need this pass, because it prevents a lot of shaders from using
    too many texture indirections.
    
    NOTE: This is a candidate for the 7.10 branch.

However this looked like unlikely to cause this regression, I was quite sure it worked before register rename pass was introduced and indeed commit bbe49bc585c4fed46f55d184b463d13bddd97f1b (r300/compiler: Use presubtract operations as much as possible) was working fine. Also commit 	8833f53e659e079e7ab74bb9197f9b44b1eeefe0 (r300/compiler: Enable rename_reg pass for r500 cards) alone or with 68b701f5ded5f6b73a6b07cf37d862fab4836607 manually applied worked fine, so this have led me to an idea that the actual regression happened somewhere between 8833f53e659e079e7ab74bb9197f9b44b1eeefe0 and 68b701f5ded5f6b73a6b07cf37d862fab4836607 and was hidden by the register rename pass. Finally bisecting between mentioned commits and manually applying 68b701f5ded5f6b73a6b07cf37d862fab4836607 in each step led to:

8f32c6cfc6503dd234f09fb06941803866c23c65 is the first bad commit
commit 8f32c6cfc6503dd234f09fb06941803866c23c65
Author: Tom Stellard <tstellar@gmail.com>
Date:   Sat Jan 29 14:37:58 2011 -0800

    r300/compiler: Standardize the number of bits used by swizzle fields
    
    Swizzles are now defined everywhere as a field with 12 bits that contains
    4 channels worth of meaningful information.  Any channel that is unused is
    set to RC_SWIZZLE_UNUSED.  This change is necessary because rgb instructions
    and alpha instructions were initializing channels that would never be used
    (channel 3 for rgb and channels 1-3 for alpha) with 0 (aka RC_SWIZZLE_X).
    This made it impossible to use generic helper functions for swizzles,
    because sometimes a channel value of 0 meant unused and other times it
    meant RC_SWIZZLE_X.
    
    All hacks that tried to guess how many channels were relevant have
    also been removed.
Comment 1 Pavel Ondračka 2011-02-08 04:17:13 UTC
Created attachment 43093 [details]
screenshot without corruption for comparison

BTW reverting 8f32c6cfc6503dd234f09fb06941803866c23c65 from current mesa master makes the problem go away.
Comment 2 Tom Stellard 2011-02-08 21:12:48 UTC
Can you post the output of RADEON_DEBUG=fp,vp with the master branch and with 8f32c6cfc6503dd234f09fb06941803866c23c65 reverted?
Comment 3 Pavel Ondračka 2011-02-09 00:34:57 UTC
Created attachment 43151 [details]
output of RADEON_DEBUG=fp,vp with mesa master
Comment 4 Pavel Ondračka 2011-02-09 00:35:42 UTC
Created attachment 43152 [details]
output of RADEON_DEBUG=fp,vp with mesa master and 8f32c6cfc6503dd234f09fb06941803866c23c65 reverted
Comment 5 Tom Stellard 2011-02-09 01:46:08 UTC
Created attachment 43154 [details] [review]
Possible Fix

This patch should be applied to the master branch.  Does it fix the problem?  If not can you post the output of RADEON_DEBUG=fp,vp with this patch applied.
Comment 6 Pavel Ondračka 2011-02-09 02:05:40 UTC
(In reply to comment #5)
> Created an attachment (id=43154) [details]
> Possible Fix
> 
> This patch should be applied to the master branch.  Does it fix the problem? 
> If not can you post the output of RADEON_DEBUG=fp,vp with this patch applied.

Yes, this patch fixes the problem. Thank you.
Comment 7 Tom Stellard 2011-02-11 20:07:05 UTC
Fix in git by commit 9106b98766e36b04daf738bd81c4f86eedfa1b8d