Created attachment 107328 [details] sysprof recording from borderlands 2 only 00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor Graphics Controller (rev 09) 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Wimbledon XT [Radeon HD 7970M] (rev ff) xorg stable, mesa git, linux 3.17-rc7. I have had something similar in some games I think, but most recently with Borderlands 2. Here is a random screenshot with the HUD fps display from someone with a HD 7870 that shows that it runs mostly with 60 fps: https://i.imgur.com/qH0sBkl.jpg And here is a short clip of how it runs for me that shows it runs with 20-30 fps: https://www.youtube.com/watch?v=ZeZreRntt3k Radeontop says that the gpu is only used to ~30%. While running Borderlands 2 the CPU usage is always at 100+% on my i7 3632qm. I was undecided whether to report this here, but the difference is quite large so I thought I'd give it a try because I think the game itself is not supposed to use this much cpu time, so maybe it has something to do with the driver. Theories: < glennk> guessing from that output that the game engine uses a lot of occlusion queries and is stalling on them I haven't really found anything to test that yet. < agd5f> haagch, hybrid laptops have to do a lot of extra copying to get the frame from the rendering GPU to the display GPU I hope that the overhead is not *that* large because losing 70+% of gpu time would make it kind of useless for the affected games. Fortunately many (most?) games run much better, for example unigine valley shows good gpu usage: https://www.youtube.com/watch?v=sLWvYJlfvWM which makes me believe that there is a specific bottleneck. Attached is a sysprof profile of borderlands 2 but I don't know which of it is normal (like 25% total cpu time for glDrawRangeElements?).
(In reply to Christoph Haag from comment #0) > sysprof recording from borderlands 2 only Can you create another profile including all processes? BTW, if you can make sure that at least Mesa and libdrm are compiled with -fno-omit-frame-pointer (after any other compiler flags implying -fomit-frame-pointer, such as -O), that might improve the quality of the callgraphs in the profile.
Created attachment 107418 [details] sysprof (In reply to Michel Dänzer from comment #1) > (In reply to Christoph Haag from comment #0) > > sysprof recording from borderlands 2 only > > Can you create another profile including all processes? > > BTW, if you can make sure that at least Mesa and libdrm are compiled with > -fno-omit-frame-pointer (after any other compiler flags implying > -fomit-frame-pointer, such as -O), that might improve the quality of the > callgraphs in the profile. Ok, so in my first sysprof profile I had mesa compiled with -O0 -ggdb and --enable-debug. That was probably overkill, but it had hardly any effect on perceived performance. Now this is probably more realistic. mesa is *not* compiled with --enable-debug and it *is* compiled with with "-Og -ggdb". Also libdrm is compiled with "-Og -ggdb". If I'm reading this correctly now it unfortunately looks like Borderlands 2 is consuming most of the CPU time itself now... It's still the same cpu consumption: 112-114% CPU. So far I really have only to go on that my cpu should be good enough to not bottleneck the game this much...
(In reply to Christoph Haag from comment #2) > mesa [...] *is* compiled with with "-Og -ggdb". Also libdrm is compiled with > "-Og -ggdb". Looks like you didn't add -fno-omit-frame-pointer though? Can you get another profile with Mesa and libdrm built with that?
Created attachment 107479 [details] hopefully with -fno-omit-frame-pointer (xz compressed) Damn, I really thought -Og would activate that too. Sorry. I hope this is better. By the way, Is there a better way to profile something likethis or is sysprof already the most appropriate tool?
(In reply to Christoph Haag from comment #4) > I hope this is better. Yes, looks better, thanks. > By the way, Is there a better way to profile something likethis or is > sysprof already the most appropriate tool? I find sysprof's UI the most intuitive, but perf is nice as well. I don't notice anything using obviously too much CPU in your profile. Can you get a screenshot with GALLIUM_HUD like in bug 84570?
Created attachment 107595 [details] GALLIUM_HUD="fps,VRAM-usage+GTT-usage,requested-VRAM+requested-GTT,num-bytes-moved;cpu0+cpu1+cpu2+cpu3;cpu4+cpu5+cpu6+cpu7" (In reply to Michel Dänzer from comment #5) > I don't notice anything using obviously too much CPU in your profile. Can > you get a screenshot with GALLIUM_HUD like in bug 84570? For the screenshot I pinned the game to the cpus 3,7 with taskset to stop it from polluting the graphs so much when jumping between cpus. Didn't really decrease or increase the performance much. I really don't know right now... When the game loses the input focus, it pauses the game and the game rendering itself is not updated anymore I think. The cpu usage will drop from 112-114% cpu usage to 100% cpu usage and the fps go up to 60 fps. When the game is focussed again, it unpauses, and then it's again low performance.
(In reply to Christoph Haag from comment #6) > For the screenshot I pinned the game to the cpus 3,7 with taskset to stop it > from polluting the graphs so much when jumping between cpus. I'm more interested in the graphics memory usage graphs anyway. BTW, I find 'requested-GTT+GTT-usage,requested-VRAM+VRAM-usage' more useful than 'VRAM-usage+GTT-usage,requested-VRAM+requested-GTT' because it allows to see immediately how well (or not) the actuall VRAM/GTT usage matches what radeonsi wants to use. Anyway, it looks like current Mesa Git and/or the patches from bug 84662 might help.
Created attachment 107663 [details] borderlands 2 with GALLIUM_HUD with patches and drm-next-3.18 Well, the good news is that I can confirm that the random huge pauses in borderlands 2 and in unreal engine 4 demos with drm-next-3.18 are gone with the patches. If the CPU usage is all in Borderlands 2 itself and not in mesa, then maybe I'll need to start asking around what other people's cpus are and how much cpu time it uses. Maybe it really is some physics/internal rendering calculation that is so slow, when I get almost 80 fps when the game is paused in the menu or unfocussed..
I wish I had an idea what causes this. I think this is a general problem, but I can't put my finger on it. Yesterday at home I tried the oculus rift unity3d demo with -force-opengl in wine and got pretty much 75fps everywhere. Today at uni it drops to 45 fps when looking at the more complex objects in the demo. Then CPU usage is at ~113% and the GPU usage is relatively low. Something from disconnecting audio jacks, dvi monitor, usb hub with keyboard, mouse and usb DAC, suspending, waking up on battery, suspending again, waking up on power must have caused the state where it's performing badly. Trying with dri2 instead of dri3, setting vblank_mode=0, switching to another window manager, restarting X, connecting another dvi monitor, setting the display to another crtc, nothing seems to have any effect. I think at one point I disabled intel pstate cpu scaling and this didn't help either... The state where it's performing well happens rarely, but it seems that it randomly does happen. The next time I'll make sure to test borderlands 2 too to confirm whether there is some underlying problem and collect some profiling data...
Closing. The shader cache should fix the pauses. glthread will improve performance.
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.