Bug 84663

(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.