Created attachment 112734 [details] LIBGL_DEBUG=verbose steam It's more then a week that I've faced a new issue with steam. I haven't played since November so I don't know if it's a known bug or a dumb configuration. In Dota2 settings I get only 10 (or less) FPS but as soon as I start a game I have almost 30 FPS. The GPU is an R7-265 with an FX-8320@4.4GHz. I'm sure that back in November I can run Dota settings at about 50+ FPS. What's going on? I can't see any warning in dmesg. Is this a common behaviour or it's a configuration problem? I'm running kernel from agd5f git repo, drm-fixes-3.19 branch. I've tried also with mesa in Debian Sid branch or with llvm3.6. No changes at all. I've run: $ LIBGL_DEBUG=verbose steam > dota2.txt I hope this can help. PS: I build mesa on a separate 32bit chroot.
Created attachment 112735 [details] mesa-build script
(In reply to Lorenzo Bona from comment #0) > In Dota2 settings I get only 10 (or less) FPS but as soon as I start a game > I have almost 30 FPS. The GPU is an R7-265 with an FX-8320@4.4GHz. > I'm sure that back in November I can run Dota settings at about 50+ FPS. > What's going on? I can't see any warning in dmesg. What changed in the meantime on your system? Did you update Mesa or LLVM or ...?
(In reply to Michel Dänzer from comment #2) > (In reply to Lorenzo Bona from comment #0) > > In Dota2 settings I get only 10 (or less) FPS but as soon as I start a game > > I have almost 30 FPS. The GPU is an R7-265 with an FX-8320@4.4GHz. > > I'm sure that back in November I can run Dota settings at about 50+ FPS. > > What's going on? I can't see any warning in dmesg. > > What changed in the meantime on your system? Did you update Mesa or LLVM or > ...? Sure, I updated all. Mesa, ddx, xserver, drm and kernel from git while LLVM from Debian snapshot. Do you need more information? Like an apitrace? I can try to build it and trace steam. PS: for tracing Dota2 which is a 32bit game I need a 32bit version of apitrace right?
Mmm I think I've found the problem. I've tried booting up my system (debian sid) with the "stock" kernel (3.16-ckt4-1) and I get almost 70FPS in settings and in game. Wow that's good! So, could be a kernel regression or a dumb kernel configuration?
(In reply to Lorenzo Bona from comment #4) > So, could be a kernel regression or a dumb kernel configuration? Have you changed the kernel configuration compared to before the problem started? If not, it's probably a kernel regression, can you bisect?
(In reply to Michel Dänzer from comment #5) > (In reply to Lorenzo Bona from comment #4) > > So, could be a kernel regression or a dumb kernel configuration? > > Have you changed the kernel configuration compared to before the problem > started? If not, it's probably a kernel regression, can you bisect? Ok. First impression, I've done some tests. I've used my 3.19-rc5 configuration, and I've rebuilded from drm-fixes-3.16 to drm-fixes-3.19. It looks like the issue is between drm-fixes-3.16 and drm-fixes-3.17. In 3.16 I get about 70 (or more)FPS in settings/menus, and 60FPS in game. After, from 3.17 on, I get about 4 (or less) FPS in settings/menus, and 30FPS in game. I'll try to dig more.
So, I've attached the result from git bisect log. Looks like the last good commit is ae045e2455429c418a418a3376301a9e5753a0a8 and the first bad commit is 0a44e68ca0a8456ed33c62c99b8c42bebdcbbc8c I'm really sorry, it's the first time I've made a git bisect, so take this with salt. If I've missed something or I can bisect more give me a hint. Hope this will help you. :)
Created attachment 112910 [details] git_bisect.log
Another hint, running current drm-fixes-3.19 with radeon.dpm=0 doesn't change anything. My GPU is based on pitcairn microcode.
(In reply to Lorenzo Bona from comment #8) > git_bisect.log That looks way too short to be the final result. Keep going until git bisect tells you which commit is the first bad one.
(In reply to Michel Dänzer from comment #10) > (In reply to Lorenzo Bona from comment #8) > > git_bisect.log > > That looks way too short to be the final result. Keep going until git bisect > tells you which commit is the first bad one. Sorry for the delay. Here the git bisect result: $git bisect bad 02376d8282b88f07d0716da6155094c8760b1a13 is the first bad commit commit 02376d8282b88f07d0716da6155094c8760b1a13 Author: Michel Dänzer <michel.daenzer@amd.com> Date: Thu Jul 17 19:01:08 2014 +0900 drm/radeon: Allow write-combined CPU mappings of BOs in GTT (v2) v2: fix rebase onto drm-fixes Signed-off-by: Michel Dänzer <michel.daenzer@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> :040000 040000 369d9e0ff185b6e6c9614de87296fc60072f56b9 d9fb7256264156abdaf238cd0e6f0925d7e54ac7 M drivers Attached the complete git bisect log.
Created attachment 112935 [details] git_complete_bisect.log
This looks to me like another "32bit toolchain caused stutter" like in bug 83436 Lorenzo, can you try how it goes if you add in your script also '-mtune' to both CFLAGS and CXXFLAGS ?
(In reply to Lorenzo Bona from comment #1) > Created attachment 112735 [details] > mesa-build script I mean in this mesa build script of course to add -mtune, while using recent kernel
(In reply to smoki from comment #13) > This looks to me like another "32bit toolchain caused stutter" like in bug > 83436 > > Lorenzo, can you try how it goes if you add in your script also '-mtune' to > both CFLAGS and CXXFLAGS ? Yeah, looks like it's the same issue, btw I've rebuilded mesa with " .. -mtune=native -march=native .." and nothing change with newer 3.19 kernel. I get 1 FPS in menus/settings and around 30 in game. With the 3.16rc6 I get always 60FPS (vsync enabled).
Hm well i can't see slowdwons in dota, but anyway as a guess can you try to revert this mesa commit i see some slodowns with it too: https://bugs.freedesktop.org/show_bug.cgi?id=88658#c6
(In reply to smoki from comment #16) > Hm well i can't see slowdwons in dota, but anyway as a guess can you try to > revert this mesa commit i see some slodowns with it too: > > https://bugs.freedesktop.org/show_bug.cgi?id=88658#c6 I will try. Can you post your build script? Could be a bad format in my build script? I forget if I've changed something between this one and the previous one I use back in November.
Reverting this commit http://cgit.freedesktop.org/mesa/mesa/commit/src/gallium/drivers/radeon/r600_buffer_common.c?id=7b4276d7acf2e0f77044cb50caa6ad936fa78786 helps a little bit. But it's not as fluid as on 3.16rc6 kernel.
(In reply to Lorenzo Bona from comment #18) > Reverting this commit > > http://cgit.freedesktop.org/mesa/mesa/commit/src/gallium/drivers/radeon/ > r600_buffer_common.c?id=7b4276d7acf2e0f77044cb50caa6ad936fa78786 > > helps a little bit. > > But it's not as fluid as on 3.16rc6 kernel. That same mesa used with 3.16rc6 and drm-fixes-3.19? Does those two kernels have same/similar performance (without that large drop), but just drm-fixes-3.19 is not so fluid like when 3.16rc6 kernel is used? And you builded that mesa now with -mtune=native for both CFLAGS and CXXFLAGS? Asking all those because i don't have those sttuter problems with 3.19 kernel and that reverted but that is on APU... than it seems to me like only dedicated cards are affected.
For 3.19, you may be hitting: https://bugzilla.kernel.org/show_bug.cgi?id=90741
(In reply to smoki from comment #19) > (In reply to Lorenzo Bona from comment #18) > > Reverting this commit > > > > http://cgit.freedesktop.org/mesa/mesa/commit/src/gallium/drivers/radeon/ > > r600_buffer_common.c?id=7b4276d7acf2e0f77044cb50caa6ad936fa78786 > > > > helps a little bit. > > > > But it's not as fluid as on 3.16rc6 kernel. > > That same mesa used with 3.16rc6 and drm-fixes-3.19? Does those two kernels > have same/similar performance (without that large drop), but just > drm-fixes-3.19 is not so fluid like when 3.16rc6 kernel is used? > > And you builded that mesa now with -mtune=native for both CFLAGS and > CXXFLAGS? > > Asking all those because i don't have those sttuter problems with 3.19 > kernel and that reverted but that is on APU... than it seems to me like only > dedicated cards are affected. Yeah. I've compiled mesa, with both -march and -mtune set to native on CFLAGS and CXXFLAGS. On 3.16rc6 is running like a charme (I've never seen radeonsi so fast), on 3.19 is crap, BUT this is only for 32bit program(s) (tested only Dota2). Unigine Valley results are almost the same on both kernel. Near 5000 points, max FPS around 40, min FPS around 7 and average near 27FPS. So is it something related to architecture, from my poorly point of view. (In reply to Alex Deucher from comment #20) > For 3.19, you may be hitting: > https://bugzilla.kernel.org/show_bug.cgi?id=90741 Mmm but with that bug people are experiencing pauses, I don't have pauses but costant low FPS.
(In reply to Lorenzo Bona from comment #11) > 02376d8282b88f07d0716da6155094c8760b1a13 is the first bad commit If you build Mesa at commit 07c65b85eada8dd34019763b6e82ed4257a9b4a6, does the problem occur with that? If not, can you bisect between that and the snapshot of Mesa you're currently using? Please use a current 3.19 kernel for testing this.
(In reply to Michel Dänzer from comment #22) > (In reply to Lorenzo Bona from comment #11) > > 02376d8282b88f07d0716da6155094c8760b1a13 is the first bad commit > > If you build Mesa at commit 07c65b85eada8dd34019763b6e82ed4257a9b4a6, does > the problem occur with that? If not, can you bisect between that and the > snapshot of Mesa you're currently using? > > Please use a current 3.19 kernel for testing this. Yes, the problem is still there. I will try to take the Debian sid kernel .config, and use it as a starting point for building the newer drm-fixes-3.19 and see if the problem still occur.
With the Debian .config seems to be better, not as fast as with 3.16. So I think I've messed up my original .config file. Probably I've strip down some useful option. I will test more deep. BTW, with tonight updates from mesa I get some graphical glitch. Do I have to bisect? Yesterday my last build is against this commit: docs: fix mesa 10.4.3 release date 765cfe9a90b6d592b232d1647d65d50c983bea2f
Created attachment 112972 [details] glitch
Created attachment 112973 [details] glitch_between_trees
Created attachment 112974 [details] glitch_near_shop
I'm really sorry. I've made more tests today and I can confirm it's my fault. I've probably messed up my .config. So this can be marked as not a bug. Sorry for wasting your time. BTW since yesterday morning git updates, as you can see, I'm facing glitch (or whatever they are). Should I open a new bug or I can edit the obj of this one?
(In reply to Lorenzo Bona from comment #28) > I've probably messed up my .config. It's surprising though that something in .config could cause this. Can you attach the good and bad .config for comparison? > BTW since yesterday morning git updates, as you can see, I'm facing glitch > (or whatever they are). > > Should I open a new bug or I can edit the obj of this one? Please file a new report. Can you bisect?
(In reply to Michel Dänzer from comment #29) > (In reply to Lorenzo Bona from comment #28) > > I've probably messed up my .config. > > It's surprising though that something in .config could cause this. Can you > attach the good and bad .config for comparison? > > Yes, here you are the config-3.19.0-rc5-g16653db-dirty (bad one) and the config-3.19.0-rc5+ (good one). > > BTW since yesterday morning git updates, as you can see, I'm facing glitch > > (or whatever they are). > > > > Should I open a new bug or I can edit the obj of this one? > > Please file a new report. Can you bisect? Ok, sure.
Created attachment 113087 [details] bad_kernel_config
Created attachment 113088 [details] good_kernel_config
I guess it was most likely because CONFIG_X86_PAT was disabled.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.