Ok, but what are the details on the game-- galaxy size, and turn, number of AIs, for example. Can't really assess anything without some info like that.pheldens wrote:Code: Select all
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 13694 user 20 0 1105m 146m 39m R 103 1.8 159:44.00 freeorion
About freeorion's performance
Moderator: Committer
Re: About freeorion's performance
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0
Re: About freeorion's performance
this was while displaying the techtree, when viewing the starmap it drops back to 50% cpu load
6 AI 150 systems, more or less default
6 AI 150 systems, more or less default
Re: About freeorion's performance
Hmm, for me it doesn't seem to make any difference whether I'm showing the tech tree or not (whether it's zoomed in or not, showing all the techs). How far along in the game is that? With default settings the monsters can sometimes proliferate out of hand and really drag down performance.pheldens wrote:this was while displaying the techtree, when viewing the starmap it drops back to 50% cpu load
6 AI 150 systems, more or less default
Also, you compiled yourself, right? Could you double check the cmake settings to see if it compiled it as 'Release' or as 'Debug'? The default used to be 'Debug' which could noticeably slow things down; its not that long ago that we changed the default to 'Release'.
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0
Re: About freeorion's performance
cpu not maximal, gpu not maximal, yet still low fps, whats causing this?
export GALLIUM_HUD=GPU-load,cpu0+cpu1+cpu2+cpu3
./freeorion
export GALLIUM_HUD=GPU-load,cpu0+cpu1+cpu2+cpu3
./freeorion
- Attachments
-
- see fps through transparency
- research.png (183.34 KiB) Viewed 1583 times
Re: About freeorion's performance
for starmap
(btw this image uploader crashes the session/forum often)
(btw this image uploader crashes the session/forum often)
- Attachments
-
- starmapx.png (169.35 KiB) Viewed 1573 times
Re: About freeorion's performance
The compile isn't a debug build as far as I can tell, it makes stripped optimized binaries -O3/-O2 -s when observing the cmake buildprocess when its building.
The AI threads do DEBUG loglevel logging when it's running, leading to quite large logfiles, seen them at 40MB a piece (however this has little impact on performance)
The AI threads do DEBUG loglevel logging when it's running, leading to quite large logfiles, seen them at 40MB a piece (however this has little impact on performance)
Re: About freeorion's performance
I had already narrowed down some of the poor performance of the tech-tree to (I think) the font rendering. I posted about it here:
viewtopic.php?f=9&t=9410
(The idea for a fix was dismissed at the time because it was misread.) The basic idea is to implement a font-glyph cache to improve rendering performance. GG may or may not already have such a cache; if so, it may be poorly implemented.
viewtopic.php?f=9&t=9410
(The idea for a fix was dismissed at the time because it was misread.) The basic idea is to implement a font-glyph cache to improve rendering performance. GG may or may not already have such a cache; if so, it may be poorly implemented.
- adrian_broher
- Programmer
- Posts: 1156
- Joined: Fri Mar 01, 2013 9:52 am
- Location: Germany
Re: About freeorion's performance
There was nothing misread. The issues mentioned in the thread still exist.raptor wrote:The idea for a fix was dismissed at the time because it was misread.
Such mechanism already exists. The only reason why this wasn't addressed is because nobody cares enough to identify the exact problem and fix it. Just throwing a library at a problem doesn't make bugs magically disappear.raptor wrote:The basic idea is to implement a font-glyph cache to improve rendering performance. GG may or may not already have such a cache; if so, it may be poorly implemented.
Resident code gremlin
Attached patches are released under GPL 2.0 or later.
Git author: Marcel Metz
Attached patches are released under GPL 2.0 or later.
Git author: Marcel Metz
Re: About freeorion's performance
None of the issues you brought up in that thread about the library exist (I know this because I have implemented it), which is why I thought you misread it. I'm sorry if I'm mistaken.
But with that said, you are right in that just throwing a library at something doesn't always fix it. If GG does indeed have a glyph-cache, then I wonder if it is actually helping...
But with that said, you are right in that just throwing a library at something doesn't always fix it. If GG does indeed have a glyph-cache, then I wonder if it is actually helping...
- adrian_broher
- Programmer
- Posts: 1156
- Joined: Fri Mar 01, 2013 9:52 am
- Location: Germany
Re: About freeorion's performance
I can give you the reasons for the issues:raptor wrote:None of the issues you brought up in that thread about the library exist (I know this because I have implemented it), which is why I thought you misread it. I'm sorry if I'm mistaken.
- I'm not willing to maintain a CMake build system for a external dependency, may it be in or out of the FO source. If you like to do so for your project: great for your project.
- OpenGL texture states are not restored at all by the library. It assigns textures, but doesn't restore the old texture, it disables the texture unconditionally. Given the already existing FO rendering code this screams for subtle bugs because of the stateful OpenGL nature.
- NIH means 'not invented here'. With 'fine libraries around' I mean FreeType, which is pretty much the de-facto standard for loading TrueType, rendering and measuring fonts. When I read the header 'stb_truetype.h' I see things like: TODO: crashproof on bad data or TODO: hinting? (no longer patented), things that FreeType already has implemented.
Here is my guess: The glyph cache (quad coordinates and texture coordinates) is rebuild every frame, regardless if the underlying text has changed. This would make every caching mechanism useless.raptor wrote:But with that said, you are right in that just throwing a library at something doesn't always fix it. If GG does indeed have a glyph-cache, then I wonder if it is actually helping...
Resident code gremlin
Attached patches are released under GPL 2.0 or later.
Git author: Marcel Metz
Attached patches are released under GPL 2.0 or later.
Git author: Marcel Metz
Re: About freeorion's performance
Thank you for clarifying. I understand your points much better now.
Re: About freeorion's performance
I did a callgrind analysis of the tech-tree window. I started the game, went into the tech-tree as fast as possible, showed all techs and made sure I was zoomed in enough that the tech names rendered (this reduced FPS to about 1/2 on my system). I then let it sit for about 5 min in that window.
Sure enough, the largest culprits are (with absolute percentages of the whole program):
1. GG::Font::RenderCachedText() (~19%) with most of the processing being GL calls.
2. TechTreeWnd::LayoutPanel::Render() (~12%) with 8% in PartlyRoundedRect() and 3% in GG::StaticGraphic::Render()
See graphics below. Also, here is the callgrind file (sorry for using an upload provider, it was a bit too large):
http://s000.tinyupload.com/index.php?fi ... 8886060686
Sure enough, the largest culprits are (with absolute percentages of the whole program):
1. GG::Font::RenderCachedText() (~19%) with most of the processing being GL calls.
2. TechTreeWnd::LayoutPanel::Render() (~12%) with 8% in PartlyRoundedRect() and 3% in GG::StaticGraphic::Render()
See graphics below. Also, here is the callgrind file (sorry for using an upload provider, it was a bit too large):
http://s000.tinyupload.com/index.php?fi ... 8886060686
- Attachments
-
- TechTreeWnd.png (128.03 KiB) Viewed 1506 times
-
- RenderCachedText.png (60.68 KiB) Viewed 1506 times
- adrian_broher
- Programmer
- Posts: 1156
- Joined: Fri Mar 01, 2013 9:52 am
- Location: Germany
Re: About freeorion's performance
Thanks for taking the time to investigating the cause. I have some question on the output.
What do I see for example in the left branch below the GG::Font::RenderCachedText named 0x0…0752c780? Is that a function without a debug symbol? It's causing the majority of the performance hit within the GG::Font::RenderCachedText function.
I assume the percentage showed everywhere is the total CPU time used by the client application (meaning 13.5% it's hanging around in 0x0…0752c780) and not the CPU time relative to the caller?
What do I see for example in the left branch below the GG::Font::RenderCachedText named 0x0…0752c780? Is that a function without a debug symbol? It's causing the majority of the performance hit within the GG::Font::RenderCachedText function.
I assume the percentage showed everywhere is the total CPU time used by the client application (meaning 13.5% it's hanging around in 0x0…0752c780) and not the CPU time relative to the caller?
Resident code gremlin
Attached patches are released under GPL 2.0 or later.
Git author: Marcel Metz
Attached patches are released under GPL 2.0 or later.
Git author: Marcel Metz
- Geoff the Medio
- Programming, Design, Admin
- Posts: 13587
- Joined: Wed Oct 08, 2003 1:33 am
- Location: Munich
Re: About freeorion's performance
GG::Font::RenderCachedText is doing a series of OpenGL calls. For a large number of separate bits of text, such as the tech screen or (I suspect) the map screen, this will involve many repeated bindings of the font texture... perhaps more so for the tech screen, as the ShadowedTextControl that are used in TechPanel contains two GG::TextControl as members, which are collectively rendered 5 times each (with each time re-binding the texture) per ShadowedTextControl render call. This could probably be re-implemented by inheriting from GG::TextControl and override the Render function to work more efficiently. Alternatively, GG::Font could be given a RenderShadowedCachedText function to do the shadowing effect more efficiently, although that's a bit of an odd special case...
Re: About freeorion's performance
Yes, the percentages are as a percentage of the whole instead of relative to parent.
Those missing symbols are the OpenGL function calls to the NVIDIA drivers I'm running (Linux, openSUSE 13.2 x86_64). I'm not sure if I can get the exact symbol names.
I suspect that there is something sub-optimal about the font caching - maybe because of the constant re-binding? Could a texture cache be bound only once at application start-up, then just modify the quad coordinates of the glyph when rendering? I'm afraid I don't understand much of GG's internals yet...
Those missing symbols are the OpenGL function calls to the NVIDIA drivers I'm running (Linux, openSUSE 13.2 x86_64). I'm not sure if I can get the exact symbol names.
I suspect that there is something sub-optimal about the font caching - maybe because of the constant re-binding? Could a texture cache be bound only once at application start-up, then just modify the quad coordinates of the glyph when rendering? I'm afraid I don't understand much of GG's internals yet...