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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



changed bug 94900
What Removed Added
Attachment #125271 is obsolete   1

Comment # 28 on bug 94900 from
Created attachment 126832 [details] [review]
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:
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux