[Bug 94900] HD6950 GPU lockup loop with various steam games (octodad[always], saints row 4[always], dead island[always], grid autosport[sometimes])

[bugzilla-daemon@freedesktop.org]

[-- Attachment #1.1: Type: text/plain, Size: 2452 bytes --]

https://bugs.freedesktop.org/show_bug.cgi?id=94900

Heiko <lil_tux@web.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #125271|0                           |1
        is obsolete|                            |

--- Comment #28 from Heiko <lil_tux@web.de> ---
Created attachment 126832
  --> https://bugs.freedesktop.org/attachment.cgi?id=126832&action=edit
Possible fix for the lockups

The more I look at the sb code the more I dislike it :/ Anyhow, looks like the
GCM pass is b0rked and doesn't like unused ops at all.

The problem with that octodad trace is that with a pass through fold_assoc() an
ADD_INT op becomes unused, but isn't removed prior to GCM. GCM then moves it up
to the front of the shader (because there are no users), where the op's src
values aren't defined (in that particular case the loop counter variable). GCM
also moves ops up, if the usage count isn't fulfilled yet. Well that's when
things get really broken, since it seems to move the loop counter -- or at
least the initializer -- to fulfill the usage count. And well, then the GPU
finally locks up on the shader (or if mesa is compiled in debug mode, sb shows
unset registers), probably due to endlessly looping.

I tried to fix GCM, but everytime I thought I've did the right thing, I got
either unscheduled ops or wrong levels for the basic blocks. Also, the
DONT_HOIST stuff doesn't really seem to work that well either.

So I decided to fix the input feeded into the GCM pass, by iteratively removing
all unused ops in dce_cleanup. This could also be reducing amount of
instructions, that weren't actually removed before. Also optimized valtable's
use_count(), which gets called 1500+ times for the octodad trace and did
iterate over the whole use_info list every time...

The (untidied) patch fixes octodad for me. Would be nice, if someone could test
the other problematic games (be sure to test with a debug build, to get an
exception rather than a lockup). If it works there as well, I'd clean things
up.

@Marek, what's the best/usual way to test for performance/instruction count in
mesa changes. I noticed those 'helped'/'hurt'/'+-%' infos and some runtime
numbers in commit messages, but I don't know how they are produced :/

-- 
You are receiving this mail because:
You are the assignee for the bug.

[-- Attachment #1.2: Type: text/html, Size: 4222 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel