Board index FlightGear Development

FlightGear permanently damages the performance of computers.

FlightGear is opensource, so you can be the developer. In the need for help on anything? We are here to help you.
Forum rules
Core development is discussed on the official FlightGear-Devel development mailing list.

Bugs can be reported in the bug tracker.

FlightGear permanently damages the performance of computers.

Postby islandmonkey » Mon May 18, 2015 4:41 pm

On my Linux PC FlightGear has always been quite a slow program in comparison to other graphics intensive stuff (think Steam games and so on). So I've always been interested -- how does FlightGear compare to something like Team Fortress 2? Today I did a small investigation -- to remind people of my specs, I have:

    A Lenovo Z500 laptop with:
  • GPU: NVIDIA GT635M 1GB & Intel HD4000 (this is an Optimus laptop, so I use the NVIDIA for both -- note that both struggle with the 4000, but FG just falls on its feet while TF2 is still usable)
  • CPU: Intel® Core™ i5-3230M CPU @ 2.60GHz (dual core but with hyperthreading so technically quad)
  • 4GB of RAM
  • 1TB HDD (I am not sure of its speed, I think its only 5400RPM. 606GB is dished out to Ubuntu)

I have also tested FlightGear on Windows 7, but I have not managed to get a comparison and having everything else on DirectX blurs the line slightly. Nevertheless, FG still performs badly (best frame rate on max settings is 15 FPS).

My FG settings are max on all shaders, multithreading on DrawThreadPerContext, all graphics settings enabled excluding Random buildings and tree shadows. Clouds were on 0.64 density and ~110000m visibility with detailed weather enabled. Multiplayer was turned off. Airport was KSFO 28R with ufo. The weather report is posted below, as the conditions will have a load on what is being rendered and how things perform.
Image

Let's take a look at what FPS and spacing we get in game. From the horizon:
Image

A miserable 5 frames per second. Makes FlightGear a pain in the ass to use.

Now lets look at the FPS while we look at the ground:
Image

As you can see, 20/21 frames per second. Okay-ish.

The performance looking at the sky:
Image

24/25 fps.

Now lets take a look at load factors on my machine.
Image

FlightGear within that scenario is using little of the GPU. This is something I do not get about FlightGear and why it is so slow, as Team Fortress 2 will use 92% of VRAM and have a much higher GPU utilisation but will always run at 59/60 FPS with good frame spacing rates.

CPU and RAM:
Image

Team Fortress 2 will use the same amount of CPU and even more RAM. But it will still run faster with everything on highest settings (excl. anti-aliasing and anisotropic filter which are both on 4x).

I should make a note -- I have noticed with multithreading, that FG will decide to max out one core (typically core 3) instead of sharing it around.

Conclusion

Now, I understand that this is a very distant thing in comparison to Team Fortress 2. But the numbers win in a situation like this and as you can see, FlightGear just isn't good enough. It is poorly optimised and I leave it permanently responsible for damaging my computer's performance. If I didn't take apart my laptop and blow compressed air into the fan to get rid of the dust that has collected, I would not be able to run things like Team Fortress 2, the game would just degrade in performance.

This was also the case with my old laptop, which FG also destroyed until I did the same thing as above. FG would run really really slow, on a quad-core i7 with a NVIDIA 540M @ 2GB. Team Fortress 2 and just about every other game that I played? Well, I never got anything lower than 40 FPS on both machines. The big difference, I believe, is that the Source engine appears to pre-load just about everything. TF2 is notable on my machine for bottlenecking badly when loading a game.

Changing FG's graphical settings does little or nothing. If I switch all the shaders to zero, I get no performance boost. If I turn off ALS, I get no performance boost. If I turn off detailed weather, I get no performance boost. I don't think I have to repeat this any more. So, to prevent my computer from permanent damage, I will not be using FG any more.
User avatar
islandmonkey
 
Posts: 786
Joined: Mon Jan 30, 2012 9:51 pm
Location: EGCN (uni), EGHI (home)
Callsign: G-MNKY
OS: Ubuntu 20.04

Re: FlightGear permanently damages the performance of comput

Postby Hooray » Mon May 18, 2015 5:06 pm

Some of your conclusions are basically correct - but others are colored by the tool/s you are -not- using - e.g. the built-in performance monitor, and especially the GUI (it being used in PUI/PLIB)- is adding to the performance overhead you're seeing - the wiki contains better instructions to gather a more detailed/accurate understanding of overall FG/system performance, but that will involved using tools like a profiler - including not just a system profiler, but also an OpenGL/GLSL profiler. Like I said, the conclusion that FG isn't as optimized as some commercial titles certainly holds true, but also largely depends on your startup/run-time settings - there's a plethora of code paths that may be exercises or not, depending on the settings you are using - which is why it does make sense to actually use a really simple startup profile and do profiling for different configurations and compare those to draw conclusions - either way, the general notion that FG "damanges the performance of computers" certainly isn't correct.

If you are interested in understanding FG specific performance issues, I suggest that you download 2-3 free tools to do system-level benchmarking, including at least one OpenGL/GLSL debugger, but also Intel Vtune or AMD's Code Analyst - or alternatively, use Microsoft Visual Studio.

Those are just tools that will help understand FlightGear how it performs as a "black box" - to better understand individual subsystems (and threads), you will inevitably need to patch/rebuild FG itself, and stop using the PLIB-based performance monitor (in fact, even using Torsten's browser-based mongoose/Phi work would be better here, because it's running in a separate thread, and rendering takes place in a different application)

If you're interested in getting to the bottom of this, you should ideally download/install, and read up on using these tools in conjunction with FlightGear:


For NVIDIA hardware/GPUs: https://developer.nvidia.com/nvidia-perfkit
For AMD/ATI hardware/GPUS:

For additional recommendations on profiling OpenGL apps, see: https://www.opengl.org/wiki/Debugging_Tools

To learn more about profiling applications in general, see: http://stackoverflow.com/questions/6755 ... or-windows and: http://stackoverflow.com/questions/2666 ... tool-for-c

Only once you understand how to use these tools, will you get an accurate understanding of application-level issues.

And you will have to start with the minimal startup profile as per: http://wiki.flightgear.org/Troubleshoot ... up_profile
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: FlightGear permanently damages the performance of comput

Postby islandmonkey » Mon May 18, 2015 6:00 pm

Roger that, I've downloaded a trial version of VTune and I'll see what I can do with it; I'll also take a look at the other tools as well and see what I can do with them.

I always thought that comparing something like this to a commercially-built game is a harsh comparison, but at the same time it just shows the importance of optimisation.
User avatar
islandmonkey
 
Posts: 786
Joined: Mon Jan 30, 2012 9:51 pm
Location: EGCN (uni), EGHI (home)
Callsign: G-MNKY
OS: Ubuntu 20.04

Re: FlightGear permanently damages the performance of comput

Postby Gijs » Mon May 18, 2015 6:06 pm

Just wondering, but how is FlightGear responsible for dust creeping into your device?
Airports: EHAM, EHLE, KSFO
Aircraft: 747-400
User avatar
Gijs
Moderator
 
Posts: 9544
Joined: Tue Jul 03, 2007 3:55 pm
Location: Delft, the Netherlands
Callsign: PH-GYS
Version: Git
OS: Windows 10

Re: FlightGear permanently damages the performance of comput

Postby Hooray » Mon May 18, 2015 6:11 pm

you don't need to download any trial versions - pretty much all of the aforementioned tools are available for free, especially for use in open source development.
If you've got an Intel CPU/chipset, you may want to get the Intel stuff, and vice versa for AMD/ATI hardware.
For nvidia GPUs, the perfkit is great.
For general GPU troubleshooting, use gDebugger (shareware, but freely available)
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: FlightGear permanently damages the performance of comput

Postby Thorsten » Mon May 18, 2015 6:11 pm

FlightGear within that scenario is using little of the GPU


Looking at ground: very few vertices in the view frustrum.

Looking at sky: very few vertices in the view frustrum

Looking at horizon: maximal number of vertices in the view frustrum

Always same number of fragments, but terrain has higher fragment shader demands than sky -> your performance is vertex shader driven

Your card in contrast has apparently plenty of cores dedicated to fragment processing and apparently a rather weak vertex processing pipeline - you see a fully utilized vertex pipeline choking the system down and an idle fragment pipeline which can't be utilized because the vertex load isn't arriving fast enough, i.e. the net effect is that your card isn't fully utilized because the GPU doesn't have what's needed for the scene.

Tell-tale - lowering the settings (which largely influence fragment processing load) don't give you much boost.

Rather high vertex demand is characteristic for a Flightsim where many scene optimization tricks (impostors, 'levels',... ) which are rountinely done in 3d shooters for instance simply won't work.

But the numbers win in a situation like this and as you can see, FlightGear just isn't good enough.


Or maybe you have to have a bit of an idea how the rendering pipeline attacks a scene...

Revert to 1.0 scenery, don't use vertex-intensive things like random buildings and trees (or dense cloud layers), watch the framerate go up as the vertex pipeline is freed. And the best thing is - you can still run the high quality fragment processing.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: FlightGear permanently damages the performance of comput

Postby Hooray » Mon May 18, 2015 6:21 pm

I don't think this is helpful Thorsten, you -and others (e.g. F-JJTH & myself included)- have previously given out advice like your's above, which ended up disregarding actual bugs, like those identified, and fixed, by Rebecca & TorstenD (e.g. involving leaking listeners/effects and the memory leak in the route manager code). It does make sense to look at things without any focus on rendering, and use different benchmarks to draw the corresponding conclusions.

The "misconfiguration tale" is an urban legend that is far too common around here, and even Rembrandt evangelists would keep giving that to us, despite the Vsync related findings posted by Richard Harrison lately.

If we keep on telling people that they're too incompetent to configure their systems/software and that they don't understand certain technology/programming concepts, we're also alienating people who may otherwise contribute to finding performance related issues in areas that would otherwise go unnoticed, especially on typical developer systems (like your's), and those covering use-cases that most of us rarely -if ever- do any testing for (think multiplayer/route manager or other virtual airline stuff).

While the advice given above may very well end up providing better performance, it may also help mask issues that are otherwise much more prominent - just like an inefficient Nasal GC won't be showing up on a modern multi-core system capable of providing frame spacing latencies way below 10 ms.

Then again, I certainly wouldn't be testing with advanced weather running at all - definitely not in a basic test scenario.

If we keep looking at every problem like it's rendering related, we'll also keep ignoring more fundamental issues, that have zero to do with rendering, or even scenery/terrain in general.

A number of core developers have been working towards a FlightGear "headless" mode and better multicore support via HLA/RTI - so it does make sense to keep those efforts in mind, and not just look at every problem with a focus on just graphics.

Should IslandMonkey be able to use an OpenGL/GLSL profiler, he will definitely benefit from your graphics related expertise and feedback anyway.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: FlightGear permanently damages the performance of comput

Postby islandmonkey » Mon May 18, 2015 7:07 pm

Thorsten wrote in Mon May 18, 2015 6:11 pm:Revert to 1.0 scenery, don't use vertex-intensive things like random buildings and trees (or dense cloud layers), watch the framerate go up as the vertex pipeline is freed. And the best thing is - you can still run the high quality fragment processing.


I am not confident that would work. I was using my old laptop as I described for FG back in the WS1.0 days (I was quite active from February to August 2012) and it was all very slow nevertheless.
User avatar
islandmonkey
 
Posts: 786
Joined: Mon Jan 30, 2012 9:51 pm
Location: EGCN (uni), EGHI (home)
Callsign: G-MNKY
OS: Ubuntu 20.04

Re: FlightGear permanently damages the performance of comput

Postby islandmonkey » Mon May 18, 2015 7:32 pm

Also, a small but important question -- how can I debug with optimus? I just want to make sure that gDebugger is analysing the correct application. I start FG up with a bash script that launches the compiled edition of FG with optirun -c rgb and with this nothing gets recorded (I use download_and_compile.sh for FG).

I also have a bit of problem -- the link to where libGL.so.1 is hardcoded inside the program. If I symlink it to where it actually is, then I still recieve an error that it doesn't exist.

Problem solved, but now replaced with another, the debugger's OpenGL engine won't start.
User avatar
islandmonkey
 
Posts: 786
Joined: Mon Jan 30, 2012 9:51 pm
Location: EGCN (uni), EGHI (home)
Callsign: G-MNKY
OS: Ubuntu 20.04

Re: FlightGear permanently damages the performance of comput

Postby Hooray » Mon May 18, 2015 8:06 pm

make sure to refer to the help/about dialog to ensure that you're using your dedicated GPU/graphics cards, and not any CPU-emulation (think MESA)
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: FlightGear permanently damages the performance of comput

Postby Thorsten » Tue May 19, 2015 7:16 am

I don't think this is helpful Thorsten,
(...)
It does make sense to look at things without any focus on rendering, and use different benchmarks to draw the corresponding conclusions.


We have in a single post all the information I would use to debug the issue, a textbook example of scaling with vertex number and non-scaling with fragment load (the strong dependence on view direction practically rules out all other issues because there's not much else that's so strongly view dependent in FG).

So if it makes sense for you to look at things without focus on rendering despite the evidence screaming otherwise and if you don't think my observations are helpful because I made a wrong preliminary conclusion once because you prefer to attribute all problems to your tale of bad FG architecture, I shall remove myself from this thread.

I'm looking forward to reading your explanation of the partially idle GPU and the strong view dependence of the framerate :-)
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: FlightGear permanently damages the performance of comput

Postby wkitty42 » Tue May 19, 2015 5:53 pm

Gijs wrote in Mon May 18, 2015 6:06 pm:Just wondering, but how is FlightGear responsible for dust creeping into your device?

somehow i think this has been missed, as well... laptops, especially, are highly susceptible to their vents clogging from dust... i've worked on several to revocer data from them after their owners let them overheat from dust and other blockages... one was used on a bed all the time with no hard surface under it... the thermal protections kept shutting it down leading to corruption of the OS... they ended up getting a new laptop because they didn't want to pay the cost of a new CPU and fan with the associated labor needed to gain access the it for the repair...
"You get more air close to the ground," said Angalo. "I read that in a book. You get lots of air low down, and not much when you go up."
"Why not?" said Gurder.
"Dunno. It's frightened of heights, I guess."
User avatar
wkitty42
 
Posts: 9146
Joined: Fri Feb 20, 2015 4:46 pm
Location: central NC, USA
Callsign: wk42
Version: git next
OS: Kubuntu 20.04

Re: FlightGear permanently damages the performance of comput

Postby Hooray » Tue May 19, 2015 6:02 pm

sorry, but I am not in the mood to have again this kind of discussion with you - there is a remarkable history of architecture related bugs that were recently fixed, and if you think that it's more important to deal with everything like it's rendering/graphics related and like our end-users are incompetent at using/configuring FlightGear, please be my guest - for now, I am the one to remove myself from the thread, because I have neither the time nor the inclination for this ... like I said previously, you may very well be right, but I do think that you are doing a disservice to the project by approaching all performance related bug reports like this.

And honestly, there is a large share of core developers who are quite aware of such architectural shortcomings and who have been working towards fixing those, so I'd rather not disregard all that work, just because graphics/rendering happens to be your pet peeve and you look at everything with your own background/expertise in mind.

PS: the view dependence would even be there in a FlightGear release from 18+ months ago, containing all 3-4 recently fixed bugs - so just because you may be right, doesn't necessarily mean that there are no underlying bugs that may be masked by certain factors.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: FlightGear permanently damages the performance of comput

Postby Thorsten » Tue May 19, 2015 6:12 pm

if you think that it's more important to deal with everything like it's rendering/graphics related and like our end-users are incompetent at using/configuring FlightGear, please be my guest


If you think that's a helpful statement...

I repeat - I gave a wrong preliminary assessment of a bug once - I didn't even claim to have understood the cause, I voiced a suspicion and asked for follow-up tests. I do not treat all bugs like they're rendering related, but I only post if I am reasonable sure I understand an issue, so a large fraction of things I respond to smells like either one of my subsystems or rendering related - I simply don't respond to other things.

I didn't say anything about incompetence of end users either - neither here nor elsewhere. Why you would argue that remains your mystery, except that you rather consistently spin the story here in the forum that developers do things the wrong way, use the wrong tools, don't code like you would approve and in general try very hard to create a rift between developers and users.

And the fact of the matter is that I can on two different computers get dramatic performance differences by changing config settings - so why you'd close that avenue up-front by turning a suggestion to re-configure into allegations of user incompetence remains another mystery.

PS: the view dependence would even be there in a FlightGear release from 18+ months ago, containing all 3-4 recently fixed bugs - so just because you may be right, doesn't necessarily mean that there are no underlying bugs that may be masked by certain factors.


Can you distinguish between 'I think the issue you're seeing here is X' and 'I think there is nothing ever wrong with FG except X'? What is the point of arguing like this? I never claimed there could be nothing else going wrong - I claimed the issue described here looks like a choking vertex shader. Nothing more and nothing less. What is wrong with you?
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am


Return to Development

Who is online

Users browsing this forum: No registered users and 10 guests