Increase CPU usage to more than 15%

[wkitty42]

Just recently I discovered that turning on AWS actually doubled my frame-rate: from 30 fps to a solid 60fps.
Amazing to see but it shows that the shaders to their job.

Erik

(Makes you wonder why it isn't on by default these days).

AWS? Active Weather System? it is on by default in the sim if you enable it in the launcher... it used to be that you had to specifically enable it in the sim and then it would start when you hit the [OK] button...

[wlbragg]

Some users still have GPU's that can't handle shaders?

[Praxxus]

I don't post very often but -

a) I dug my old PC out the other day ( AMD 7750 BE ; 9600 GSO's SLI'd with GT620 PhysX proc [192 cores total]) and mid settings gave 7-12 fps so cut back the eye candy and managed 25-32 fps which was fine for solo flight.

b) This was because my main gaming rig decided to kill its mobo, gpu & cpu; which I've never encountered before so I got new mobo & cpu ( i5 9600k + Asrock Z390 pro ) and the onboard gpu was better than 'a)'

c) I've borrowed a GTX 950 which runs FG quite satisfactorily, the original GTX 980Ti was very, very ample indeed.

d) Why the hell do you Two fight ALL the time ffs ? V12 - if you prefer FSX or what ever - piss off over there and stop negging FG, 4christsake. Thorsten, don't rise to this idiot.

e) If you get far enough into orbit (or space) ; you will only see the half of the Earth facing you, which is only relevant to orbital craft NOT atmospheric craft.

f) Some people can run FG on laptops, me personally have tried it with quite good rendering fps *but* I didn't like it because of lags and stuttering, they are not designed for it.

Yours faithfully,

Praxxus

NB I'll sort my sig. out when I get GFX card sorted....

[Hooray]

Some users still have GPU's that can't handle shaders?

A while ago, Erik implemented support for Graphics Card Profiles.

So, it would be possible to take this concept and add to it, what's needed in order to support startup modes with dynamic feature scaling in mind: http://wiki.flightgear.org/Feature_Scaling

That way, FlightGear could detect what's available in terms of GPU support during startup and pick a suitable default profile.
This should also work pretty well with the Compositor: http://wiki.flightgear.org/Compositor

Thanks to the property-rule subsystem, we already have the machinery in place to fine-tune parameters as needed - it's primarily a matter of hooking up things together, which is an idea that Stuart and James discussed on several occasions, i.e. using a PID controller to tweak settings as needed to target a certain frame rate/spacing

Longer term, for FlightGear to be able to make progress in the graphics department (using more modern OpenGL), it will inevitably have to get rid of legacy OpenGL code (2D panels, HUD, PUI to name a few) - and short of having a team of volunteers to port such legacy functionality, it will make sense to introduce a mechanism to safely phase out functionality over time, i.e. by making it optional in certain "startup modes", so that new modes can be supported, runtime modes that can make safe assumptions about legacy code simply being out of the loop - a number of people have independently worked on mode specific functionality anyway, such as features that specifically target "developers" (developer mode) or modes that specifically certain types of aircraft (think combat, spacecraft, helicopter vs. fixed wing) - we even have non-aircraft vehicles (think vessels) - sooner or later, the enormous flexibility of FlightGear as a platform means that such diverging functionality will need to be identified, and wrapped in dedicated "modes" - even if just to get rid of redundant UI items (think all aircraft-related UI dialogs that make little sense in a spacecraft context or vice versa) - thus, the introduction of mode-specific UI items (think menubar, GUI dialogs) would make sense - and that means, identifying more and more use-cases/resources that are mutually exclusive, which may even pertain command line arguments: http://wiki.flightgear.org/Startup_Modes

Again, this has already been happening over the course of the last few years, it's just not something that is being worked on in any orchestrated fashion, but it is becoming clear that for FlightGear as a platform to make progress, it will need to address the challenge that it is being used for mutually-exclusive purposes, and that getting rid of certain hard-coded assumptions does make sense, which will also provide an excellent opportunity to get rid of tons of legacy code in a backwards compatible fashion, at the mere cost of introducing new "startup profiles" that declare certain features obsolete, so that these can be safely disabled (and ignored!) while remaining in the source tree/binary - releasing a new FlightGear version will then include agreeing on the default startup profile to be used.

Longer term, this may even mean that controversial features like Nasal can be entirely disabled by providing a startup mode that never runs any Nasal interpreter at all, which could be a great starting point for people wanting to tinker with alternate scripting environment (think FGPythonSys) - equally, this approach will provide the flexibility to tinker with totally new schemes for scenery/terrain (think safely including osgEarth in a dedicated "osgEarth startup mode" without risking breakage), but also to support planetary simulation - as per bugman's idea: http://wiki.flightgear.org/Reaching_for_the_stars

Note that this is perfectly in line with the ongoing work to make FlightGear more modular by allowing subsystems to be disabled at startup/runtime - as well as the ongoing cppunit work, for better regression tests.

In addition, having dedicated support for "Startup modes", will also mean that it will be easier for people to create "benchmarks" just for regression testing purposes: http://wiki.flightgear.org/FlightGear_Benchmark

Again, this has been happening for years already, it's just something that nobody ever talked about, but the logical next step is formalizing the introduction of startup modes, so that different people/teams can work on different features without stepping on anyone's toes, and without cluttering our UI unnecessarily - think about having a dedicated menubar for spacecraft, vessels or for people wanting to use FlightGear as an IG (image generator) only.

The concept is also pretty sound, because we're already using the concept of PropertyList/XML overlays in several places - the most recent example being the addon system, which supports its own dedicated menu items and GUI dialogs. If this work were to be generalized, "startup modes" would primarily boil down to being sub-folders in $FG_ROOT, with their own sets of options.xml, menubar.xml and gui/dialogs

Over time, this will help clean up FlightGear enormously, while also providing a sandbox for people wanting to tinker with new functionality, without it having to fit into the bigger picture of "flight simulation".

And once you think about it, this scheme would nicely fit when it comes to supporting different renderers/pipelines, too

And yes, you could also have the equivalent of $FG_ROOT/Startup Profiles/Headless without stepping on anyone's toes !
Such profiles (folders) could then be used as template for people wanting to implement new profiles, akin to docker images - think about a Python mode based on headless, just for regression testing purposes.

[V12]

Praxxus :
I don't negging FG.
If someone ask "Why my CPU runs on 15% and GPU on 20% with lag and stutters", there is only one answer - FG can't fully utilize new CPU. And this is simple fact. Another fact - there is no plan to change it. And it is not good, because there is not room to add new features without significant performance drop.

[Thorsten]

If someone ask "Why my CPU runs on 15% and GPU on 20% with lag and stutters", there is only one answer - FG can't fully utilize new CPU. And this is simple fact.

No, there are in fact multiple alternative possible answers (some of which you could know by reading the thread).

* the device could be in power-saving mode
* the GPU could create a bottleneck
* the OS could deny resources to FG for some reason

The problem about your 'facts' usually is that they're just your biased opinion.

[GinGin]

Praxxus :
I don't negging FG.
If someone ask "Why my CPU runs on 15% and GPU on 20% with lag and stutters", there is only one answer - FG can't fully utilize new CPU. And this is simple fact. Another fact - there is no plan to change it. And it is not good, because there is not room to add new features without significant performance drop.

You had several answers there from guys with same symptoms, and a different answer about than yours. Be careful with exclusive affirmation like that . Try to be factual , not emotional . Not really helpful.
And Don’t start again that endless core debate please..

Plus some people work or at least does test on core thing etc
I don’t understand your point either

You already forgot the previous debate about that ?

https://forum.flightgear.org/viewtopic.php?f=37&t=36233&start=90


In case of the author, it became clear GPU is bottlenecking through those examples / analysis

[V12]

Gingin :
GPU bottleneck ? Are You sure ? Please compare visuals provided by DCS, P3D, FSX etc with FG. In P3D I have visibility limit 180 km, clouds rendering distance 190 km, with ActiveSky + CloudsArt my GTX 1060 can do 30 fps with clouds from horizon to horizon and resource heavy PMDG737. When I make similar setup in FG with resource heavy A320 or 777, I can't reach 10 fps. Yes, bottleneck exists, but I'm still not sure it is in the GPU.

[Hooray]

@V12: To be fair, you could be right, but it is hard to tell without looking at your setup specifically.

It is very well possible that the problem lies with FlightGear, it's never been particularly good at utilizing multi-core hardware properly. However, it is also true that things have become much better, especially since the pre-OSG days. It is also true that there is the knee jerk reaction among some long-term contributors pointing out just how many variables the "performance equation" may have, so there's that too.

But among the people intimately familiar with the renderer and the core architecture of FlightGear, there are also a few "holy grails" still, i.e. people like Mathias, Tim and James have repeatedly pointed out how the pure osgviewer beats fgviewer in terms of performance, and how fgviewer beats fgfs in terms of performance.

So, there are ill-understood issues that lie deep down somewhere in FlightGear.

Over time, FlightGear has become a fairly complex piece of software, with lots of cruft/legacy code, and a ton of potential pitfalls/issues, i.e. performance bottlenecks that are poorly/hardly understood by the few remaining people actively involved in the project. That is one of the reasons why people like Richard have been working to provide better built-in diagnostics, e.g. to see what is going on in the Nasal GC department.

Equally, Torsten D has identified the infamous effects cache leaking listeners like crazy - in hindsight, the whole architecture built on top of listeners and timers is fairly fragile and pretty obscure, too. You can write "correct" code, that is doing what's is supposed to do - just way too often, i.e. invoking code at frequencies/rates that the original developer never intended.

Unfortunately, for the time being, FlightGear is not very good at providing a comprehensive answer to the performance debate - what's really needed is much better tools/diagnostics, as well as a number of "benchmarks", i.e. pre-recorded flights, flight plans that can be run in a headless fashion - possibly on the build server, but also by end-users to compare how FlightGear performs for different people, on different hardware - but also how FlightGear itself fares in between different release numbers, to see if a new bug is showing up or if a long-standing issue has been fixed.

This is also why it's excellent for subsystems to be disable entirely, to see if a problem persists or not. Including even Nasal scripting itself. That way, you can do proper regression testing.
Equally, having a headless option to disable graphics to see how the sim performs then, provides a good answer about the rendering overhead vs. running just the "model" part of the sim.

This is something where FlightGear as a project is suffering from the way it ended up working, i.e. people with different motivations/roadmaps, backgrounds and schedules contributing at different points in their lives to the project in an "on and off" fashion over the course of almost 2 decades meanwhile, and the architecture never having been "planned" or reviewed/revised properly, it just kinda happened, and still "just happens" so to speak.

The last major attempt at proper architectural design was David Megginson's work in the XML/property tree and SGSubsystem/Mgr department, and not even that infrastructure has ever been fully adopted, otherwise we would today be able to save/load and resume flights - which is a feature that once worked, but got crippled by the original "presets" work, and this exemplifies architectural issues deep down in FlightGear, as has been repeatedly pointed out by longer-term core contributors hoping to fix that.

Obviously, FlightGear is far from perfect - but that is not to say that your specific problem is related to these long-standing issues.

In other words, for starters it would make sense to use the tools you have at your disposal and then report back here:

http://wiki.flightgear.org/OSG_on_screen_stats
http://wiki.flightgear.org/Howto:Use_the_system_monitor
http://wiki.flightgear.org/Built-in_Profiler

[GinGin]

Gingin :
GPU bottleneck ? Are You sure ? Please compare visuals provided by DCS, P3D, FSX etc with FG. In P3D I have visibility limit 180 km, clouds rendering distance 190 km, with ActiveSky + CloudsArt my GTX 1060 can do 30 fps with clouds from horizon to horizon and resource heavy PMDG737. When I make similar setup in FG with resource heavy A320 or 777, I can't reach 10 fps. Yes, bottleneck exists, but I'm still not sure it is in the GPU.

I was speaking about xen stada, author of the topic that asked for help with an integrated gpu, remember ? Before we once again went side road again with those completely subjective simulation comparaisons ( you need to bring back that core subject on every graphic topics ? )

Why are you speaking about your setup, and gtx 1060 etc?
It has nothing to do in the debate there, sorry.
You can’t reach 10 fps and With more than 300 km visibility and bare lod , I reach almost 50 fps at 50 kfeet, but is it useful to solve the issue ? I don’t think so.

[erik]

(Makes you wonder why it isn't on by default these days).

AWS? Active Weather System? it is on by default in the sim if you enable it in the launcher... it used to be that you had to specifically enable it in the sim and then it would start when you hit the [OK] button...

Usually I start from the command-line so I must have missed that change.
Good to see it being default for the average user now.

Erik

[wkitty42]

If someone ask "Why my CPU runs on 15% and GPU on 20% with lag and stutters", there is only one answer - FG can't fully utilize new CPU. And this is simple fact.

No, there are in fact multiple alternative possible answers (some of which you could know by reading the thread).

* the device could be in power-saving mode
* the GPU could create a bottleneck
* the OS could deny resources to FG for some reason

i was going to write pretty much the exact same thing

The problem about your 'facts' usually is that they're just your biased opinion.

there is that, unfortunately

[wkitty42]

AWS? Active Weather System? it is on by default in the sim if you enable it in the launcher... it used to be that you had to specifically enable it in the sim and then it would start when you hit the [OK] button...

Usually I start from the command-line so I must have missed that change.

i'm not currently sure what command line --prop(s) may need to be used to enable AWS... a quick look at the command line passed to FG from the launcher suggests

Code: Select all

--enable-real-weather-fetch
--prop:/nasal/local_weather/enabled=true
--prop:/sim/gui/dialogs/metar/mode/global-weather=false
--prop:/sim/gui/dialogs/metar/mode/local-weather=true
--prop:/sim/gui/dialogs/metar/mode/manual-weather=true
--prop:/local-weather/tmp/tile-management=METAR
--prop:/local-weather/tmp/tile-type=live


but i'm not sure which of those are explicit to causing AWS to be active when the sim starts... i suspect the nasal prop one (2nd in the list) being one of the keys...

[Hooray]

Note that since I posted the message about private property trees I've switched my view from threads in FlightGear to using multiple FlightGear processes each running it's own job (Display, FDM, AI) interconnected using some sort of network interface. Might be HLA, might be something else.

Richard's Emesary work would seem like a likely option for the time being - otherwise, there's a set of CIGI related FlightGear patches floating around that were once, but CIGI is IG specific - and Mathias ended up wrapping CIGI concepts by implementing fgviewer on top of HLA/RTI.

Also, to be fair, according to the archives and your original posting there, you already toyed with a process-based modularization strategy back in 2004 when you first mentioned your SGRemotePropertyNode experiments, actually responding to Curt who was giving soapbox speeches about the dangers of multi-threading whenever the suggestion was made

This means that a headless mode would be desirable. As well as a rendering only mode.
Which makes implementing it much easier, and possible with small steps at a time.

Do note thought that Chris Calef's work is based on patches found in the wiki, which were in turn posted by FredB back when he was working on Rembrandt, and that this patch is merely a method to DISABLE (hide) the window, but you will still need all the graphics/opengl libs, i.e. it's not a "proper" headless build for the time being, just a way to start fgfs without showing a window, i.e. so that it can be run non-interactively.

[Hooray]

The following two articles are not about FlightGear specifically, but comparing Windows vs. Linux performance on massively parallel hardware (128 cores), illustrating that design and architecture do make a difference:

• Windows 10 vs. Linux Performance On The AMD Ryzen Threadripper 3970X
• Windows vs. Linux Scaling Performance From 16 To 128 Threads With AMD Ryzen Threadripper 3990X

In other words, software not written with this kind, and degree, of parallelism and potential concurrency in mind, cannot easily benefit from such hardware.

Again, this is unrelated to FlightGear, and specifically unrelated to graphics, since this is not about GPUs but about many-core (CPU) systems. But sooner or later, your software architecture hits a bottleneck, regardless of the number of cores you throw at the problem, because the problem itself needs to be carefully formulated/rephrased to be able to benefit from such horsepower.

Depending on your startup/runtime settings, people running only the "headless" portion of FlightGear without any graphics, may still run into concurrency limits, or see cores not being utilized properly - i.e. FlightGear "lagging" despite CPU power being available.