| Priority | medium |
|---|---|
| Bug ID | 83436 |
| Assignee | dri-devel@lists.freedesktop.org |
| Summary | Sudden framerate drops in multiple games |
| Severity | major |
| Classification | Unclassified |
| OS | Linux (All) |
| Reporter | gutigen@outlook.com |
| Hardware | x86-64 (AMD64) |
| Status | NEW |
| Version | git |
| Component | Drivers/Gallium/radeonsi |
| Product | Mesa |
Created attachment 105680 [details]
dmesg
I'm having a lot of fps drops in TF2, Unigine Heaven, Xonotic, Wine games.
Framerate goes from even something like stable 100fps to sudden 5-15fps, it
hangs there for few seconds and goes back up to usual.
On top of that I've noticed some performance decrease in above apps by even
20%.
This is happening since last week (maybe friday? something around the weekend).
I seeing that too now, all of those are 32bit apps is it? -03 compiled mesa seems to fixed that for me.
Yes all 32bit. Xonotic (64bit) is not affected by sudden drops, only by performance decrease, I should have made it a bit more clear, sorry.
Wait a minute... Unigine is affected, but it's 64bit. Reporting bugs is confusing, especially when you can't edit your post ;)
| What | Removed | Added |
|---|---|---|
| Severity | major | normal |
(In reply to comment #4) > Wait a minute... Unigine is affected, but it's 64bit. Reporting bugs is > confusing, especially when you can't edit your post ;) Unigine Heaven have 64 and 32 variants in it as i see, are you sure he does not load 32bit one? If you build you mesa try -O3 gcc optimization, that seems fixed those... don't know yet what is particular issue with default optimization :).
Yes, it's 64bit for sure. As for your fix, I'm getting my mesa from Oibaf PPA, got not enough knowledge to compile it myself.
Actually nothing to do with the -O3, but with the -mtune -march it seems. On Debian default is -mtune=generic -march=i586 maybe that is the problem, if i pass -mtune=native -march=native then it performs fine in most cases :) But not all, glretrace sometimes perform slow sometimes fast... so build system seems borked currently even more on 32bit :)
(In reply to comment #4= ) > Unigine is affected, but it's 64bit. You're saying it's affected by both the framerate drops and performance decrease? Can you guys bisect?
OK i will bisect this, having now here pretty much clear case something like 3 times performance drop in OpenJK :)
(In reply to comment #8) > Can you guys bisect? So latest good is 37d43ebb28ce8be38f3d9b0805b8b14354ce786d, after 07c65b85eada8dd34019763b6e82ed4257a9b4a6 there is corruption (so i can't tested this) all the way until 150ac07b855b5c5f879bf6ce9ca421ccd1a6c938 one week later where is a fix for 3.17 kernel. Took the patch tried 07c65b85eada8dd34019763b6e82ed4257a9b4a6 again an bingo, blah, blah... So PIPE_USAGE_STREAM seems to be a main problem again, but unlike 64bit on 32bit it can't be reverted to old behavior, on 32bit it is unusable produce much corruption.
That happens with default ./autogen blah blah As i said earlier if i pass -mtune=native -march=native flags perf is normal, very weird and funny thing in the same time :D
(In reply to comment #12) > That happens with default ./autogen blah blah > > As i said earlier if i pass -mtune=native -march=native flags perf is > normal, very weird and funny thing in the same time :D But almost normal, as i said earlier too glretrace for example is slowish again :) Very weird issues, all is fine on 37d43ebb28ce8be38f3d9b0805b8b14354ce786d.
(In reply to comment #12) > That happens with default ./autogen blah blah > > As i said earlier if i pass -mtune=native -march=native flags perf is > normal, very weird and funny thing in the same time :D Unless you're provided --enable-debug mesa does mess around with the compiler optimisation/debug options (-O* and -g*). And it never touches -mtune or -march. Might be that the compiler is going for some different heuristics before/after the commit causing substantially different code to be generated ?
Default what Debian 32bit passes in addition to mesa options is: /usr/lib/gcc/i586-linux-gnu/4.9/cc1 -E -quiet -v -imultiarch i386-linux-gnu - -mtune=generic -march=i586 That is with -mtune=generic -march=i586, with -mtune=native -march=native on AMD Kabini it passes this: /usr/lib/gcc/i586-linux-gnu/4.9/cc1 -E -quiet -v -imultiarch i386-linux-gnu - -march=btver2 -mmmx -mno-3dnow -msse -msse2 -msse3 -mssse3 -msse4a -mcx16 -msahf -mmovbe -maes -mno-sha -mpclmul -mpopcnt -mabm -mno-lwp -mno-fma -mno-fma4 -mno-xop -mbmi -mno-bmi2 -mno-tbm -mavx -mno-avx2 -msse4.2 -msse4.1 -mlzcnt -mno-rtm -mno-hle -mno-rdrnd -mf16c -mno-fsgsbase -mno-rdseed -mprfchw -mno-adx -mfxsr -mxsave -mxsaveopt -mno-avx512f -mno-avx512er -mno-avx512cd -mno-avx512pf -mno-prefetchwt1 --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=2048 -mtune=btver2 So Debian default works fine for the 10.2 branch, and for the 10.3-devel up to the commit 37d43ebb28ce8be38f3d9b0805b8b14354ce786d . But anything newer is affected, 10.3 branch and git master. Maybe some of those options need to be added to default, not sure what of these make is work normal :)
(In reply to comment #= 11) > So PIPE_USAGE_STREAM seems to be a main problem = again, Note that this could be due to the application or non-driver Gallium code incorrectly using PIPE_USAGE_STREAM. > but unlike 64bit on 32bit it can't be reverted t= o old behavior, on 32bit it is > unusable produce much corruption. Weird, sounds like a kernel issue.
OK i found -mtune=generic is culprit for performance :). Played a little with -mtune to found what is minimum this code wants to work fast: -mtune=i586 = slow -mtune=pentium = slow -mtune=pentium-mmx = slow -mtune=pentium-pro = fast -mtune=i686 = fast -mtune=pentium3 = fast -mtune=pentium-pro = fast etc... So -mtune=generic seems to set lower cpu target than this code needed to perform fast.
Just tried oibaf's radeonsi_dri.so to copy here on Debian (just to be sure :D) and it suffers from the same problem with -march=generic ;)
(In reply to comment #18) > Just tried oibaf's radeonsi_dri.so to copy here on Debian (just to be sure > :D) and it suffers from the same problem with -march=generic ;) I mean -mtune=generic of course :). Now to bisect where that SSE4.1 code start to compile this slow (4 minututes on Kabini just for that) :D Issue also not present on 64bit ;)
(In reply to comment #19) > (In reply to comment #18) > > Just tried oibaf's radeonsi_dri.so to copy here on Debian (just to be sure > > :D) and it suffers from the same problem with -march=generic ;) > > I mean -mtune=generic of course :). > > Now to bisect where that SSE4.1 code start to compile this slow (4 > minututes on Kabini just for that) :D Issue also not present on 64bit ;) I haven't seen the perf issue on my pure 64 bit setup, but have noticed that the compile sits on sse4.1 for a while recently - just using one core, like it's blocking the other threads of a make -j5 till it's done.
(In reply to comment #20) > (In reply to comment #19) > > (In reply to comment #18) > > > Just tried oibaf's radeonsi_dri.so to copy here on Debian (just to be sure > > > :D) and it suffers from the same problem with -march=generic ;) > > > > I mean -mtune=generic of course :). > > > > Now to bisect where that SSE4.1 code start to compile this slow (4 > > minututes on Kabini just for that) :D Issue also not present on 64bit ;) > > I haven't seen the perf issue on my pure 64 bit setup, but have noticed that > the compile sits on sse4.1 for a while recently - just using one core, like > it's blocking the other threads of a make -j5 till it's done. Oh i bisected that ine, it takes 200X more time to compile on 32bit :D , actually compile libmesa_gallium i think this is the commit: http://cgit.freedesktop.org/mesa/mesa/commit/?id=d55f77b503ab7b59ecdd8f31c4f7dc498710e75b