Bug 88758 - Low FPS in settings on Dota2
Summary: Low FPS in settings on Dota2
Status: RESOLVED INVALID
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/Gallium/radeonsi (show other bugs)
Version: git
Hardware: x86-64 (AMD64) Linux (All)
: medium minor
Assignee: Default DRI bug account
QA Contact: Default DRI bug account
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-01-23 17:34 UTC by Lorenzo Bona
Modified: 2015-02-03 07:06 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
LIBGL_DEBUG=verbose steam (20.45 KB, text/plain)
2015-01-23 17:34 UTC, Lorenzo Bona
Details
mesa-build script (1.51 KB, text/plain)
2015-01-23 17:35 UTC, Lorenzo Bona
Details
git_bisect.log (731 bytes, text/plain)
2015-01-28 13:42 UTC, Lorenzo Bona
Details
git_complete_bisect.log (2.82 KB, text/plain)
2015-01-29 11:25 UTC, Lorenzo Bona
Details
glitch (424.81 KB, image/jpeg)
2015-01-30 11:57 UTC, Lorenzo Bona
Details
glitch_between_trees (388.17 KB, image/jpeg)
2015-01-30 11:58 UTC, Lorenzo Bona
Details
glitch_near_shop (383.50 KB, image/jpeg)
2015-01-30 11:59 UTC, Lorenzo Bona
Details
bad_kernel_config (92.63 KB, text/plain)
2015-02-03 06:55 UTC, Lorenzo Bona
Details
good_kernel_config (109.12 KB, text/plain)
2015-02-03 06:55 UTC, Lorenzo Bona
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Lorenzo Bona 2015-01-23 17:34:50 UTC
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.
Comment 1 Lorenzo Bona 2015-01-23 17:35:34 UTC
Created attachment 112735 [details]
mesa-build script
Comment 2 Michel Dänzer 2015-01-26 08:19:22 UTC
(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 ...?
Comment 3 Lorenzo Bona 2015-01-26 08:28:22 UTC
(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?
Comment 4 Lorenzo Bona 2015-01-26 09:41:49 UTC
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?
Comment 5 Michel Dänzer 2015-01-28 07:04:11 UTC
(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?
Comment 6 Lorenzo Bona 2015-01-28 10:26:06 UTC
(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.
Comment 7 Lorenzo Bona 2015-01-28 13:41:59 UTC
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. :)
Comment 8 Lorenzo Bona 2015-01-28 13:42:26 UTC
Created attachment 112910 [details]
git_bisect.log
Comment 9 Lorenzo Bona 2015-01-28 14:16:23 UTC
Another hint, running current drm-fixes-3.19 with radeon.dpm=0 doesn't change anything.

My GPU is based on pitcairn microcode.
Comment 10 Michel Dänzer 2015-01-28 14:17:39 UTC
(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.
Comment 11 Lorenzo Bona 2015-01-29 11:24:48 UTC
(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.
Comment 12 Lorenzo Bona 2015-01-29 11:25:29 UTC
Created attachment 112935 [details]
git_complete_bisect.log
Comment 13 smoki 2015-01-29 13:55:44 UTC
 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 ?
Comment 14 smoki 2015-01-29 14:02:06 UTC
(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
Comment 15 Lorenzo Bona 2015-01-29 14:38:30 UTC
(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).
Comment 16 smoki 2015-01-29 15:04:47 UTC
 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
Comment 17 Lorenzo Bona 2015-01-29 15:58:17 UTC
(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.
Comment 18 Lorenzo Bona 2015-01-29 16:44:22 UTC
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.
Comment 19 smoki 2015-01-29 17:14:18 UTC
(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.
Comment 20 Alex Deucher 2015-01-29 17:15:59 UTC
For 3.19, you may be hitting:
https://bugzilla.kernel.org/show_bug.cgi?id=90741
Comment 21 Lorenzo Bona 2015-01-29 18:10:19 UTC
(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.
Comment 22 Michel Dänzer 2015-01-30 03:17:52 UTC
(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.
Comment 23 Lorenzo Bona 2015-01-30 08:41:18 UTC
(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.
Comment 24 Lorenzo Bona 2015-01-30 11:56:13 UTC
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
Comment 25 Lorenzo Bona 2015-01-30 11:57:50 UTC
Created attachment 112972 [details]
glitch
Comment 26 Lorenzo Bona 2015-01-30 11:58:39 UTC
Created attachment 112973 [details]
glitch_between_trees
Comment 27 Lorenzo Bona 2015-01-30 11:59:08 UTC
Created attachment 112974 [details]
glitch_near_shop
Comment 28 Lorenzo Bona 2015-01-31 17:50:00 UTC
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?
Comment 29 Michel Dänzer 2015-02-03 05:54:46 UTC
(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?
Comment 30 Lorenzo Bona 2015-02-03 06:54:48 UTC
(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.
Comment 31 Lorenzo Bona 2015-02-03 06:55:21 UTC
Created attachment 113087 [details]
bad_kernel_config
Comment 32 Lorenzo Bona 2015-02-03 06:55:53 UTC
Created attachment 113088 [details]
good_kernel_config
Comment 33 Michel Dänzer 2015-02-03 07:06:35 UTC
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.