https://bugs.freedesktop.org/show_bug.cgi?id=94900
Heiko <lil_tux at web.de> changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #125271|0 |1
is obsolete| |
--- Comment #28 from Heiko <lil_tux at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160928/986d2aa7/attachment.html>
