What | Removed | Added |
---|---|---|
Attachment #125271 is obsolete | 1 |
Comment # 28
on bug 94900
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 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.
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel