Commen=
t # 28
on bug 94900<=
/a>
from Heiko
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 i=
t 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 sh=
ows
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 remo=
ving
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 c=
ount 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 :/