Board index FlightGear Support Graphics

Increase CPU usage to more than 15%

Graphics issues like: bad framerates, weird colors, OpenGL errors etc. Bad graphics ar usually the result of bad graphics cards or drivers.
Forum rules
In order to help you, we need to know a lot of information. Make sure to include answers to at least the following questions in your initial post.

- what OS (Windows Xp/Vista, Mac etc.) are you running?
- what FlightGear version do you use?
- what graphics card do you have?
- does the problem occur with any aircraft, at any airport?
- is there any output printed to the console (black window)?
- copy&paste your commandline (tick the "Show commandline box on the last page of FGRun or the "Others" section on the Mac launcher).
- please upload a screenshot of the problem.

If you experience FlightGear crashes, please report a bug using the issue tracker (can be also used for feature requests).
To run FlightGear on old computers with bad OpenGL support, please take a look at this wiki article. If you are seeing corrupted/broken textures, please see this article.

Note: If you did not get a reponse, even after 7 days, you may want to check out the FlightGear mailing lists to ask your question there.

Re: Increase CPU usage to more than 15%

Postby Thorsten » Fri Jan 31, 2020 8:59 am

Do You realize that Advanced weather visibility limit is 250 km ?


Do you realize that this is the about visibility limit in clear air based on scattering on Nitrogen molecules?

But anyway, it's not a hard limit, you can easily change it if you go to sub-orbital altitudes:

Image

So you won't see the end of the world, I'm afraid, this works reasonably well. :D
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Increase CPU usage to more than 15%

Postby V12 » Fri Jan 31, 2020 9:13 am

Nice. But OP solving problem with his HD4000 graphics. That piece of the hardware is on limits on default FG settings.

You can see EOW in case of LOD<AW vis. limit. Ofcourse without active EarthView.
Fly high, fly fast - fly Concorde !
V12
 
Posts: 2757
Joined: Thu Jan 12, 2017 5:27 pm
Location: LZIB
Callsign: BAWV12

Re: Increase CPU usage to more than 15%

Postby Thorsten » Fri Jan 31, 2020 11:05 am

But OP solving problem with his HD4000 graphics.


If you firmly believe that answers should be limited to the first question, it really begs the follow-up question why you posted a picture of a Concorde - because that was totally unasked for,

Anyway - the point of my post was to correct wrong information which you (unfortunately)) have been spreading.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Increase CPU usage to more than 15%

Postby V12 » Fri Jan 31, 2020 12:52 pm

What incorrect is on my info about LOD < visibility limit and user will see end of the world ?
What incorrect is on my statement, that FG can't fully utilize modern CPUs ?
What incorrect is in my statement with picture from FL520 on HD4000 with default FG settings ?

Again, after upgrade my PC I have not significant benefit from more powerfull CPU and GPU in FG. For example, in Blender, I have huge performance benefit. My old machine was not able handle P3D v4.5. This new without significant problems. In 32 bit FSX I had FPS gain significant larger than in FG. This is reality.
Last edited by V12 on Fri Jan 31, 2020 12:59 pm, edited 1 time in total.
Fly high, fly fast - fly Concorde !
V12
 
Posts: 2757
Joined: Thu Jan 12, 2017 5:27 pm
Location: LZIB
Callsign: BAWV12

Re: Increase CPU usage to more than 15%

Postby D-ECHO » Fri Jan 31, 2020 12:57 pm

V12 wrote in Fri Jan 31, 2020 12:52 pm:What incorrect is [...]?

This e.g. is incorrect :)
It is clear evidence that FG uses only one CPU core, no matter of setting prop:/sim/rendering/multithreading-mode.
D-ECHO
 
Posts: 2458
Joined: Sat May 09, 2015 1:31 pm
Pronouns: Bea (she/her)
Version: next

Re: Increase CPU usage to more than 15%

Postby V12 » Fri Jan 31, 2020 1:00 pm

OK, correction :
FG can't use more than 2 physical CPU cores. OK ?
Fly high, fly fast - fly Concorde !
V12
 
Posts: 2757
Joined: Thu Jan 12, 2017 5:27 pm
Location: LZIB
Callsign: BAWV12

Re: Increase CPU usage to more than 15%

Postby bugman » Fri Jan 31, 2020 1:33 pm

If you can code, you could potentially make FG use more cores. But the result of the interprocess communication for synchronising the property tree would be devastating for the frame rate.

Regards,
Edward
bugman
Moderator
 
Posts: 1808
Joined: Thu Mar 19, 2015 10:01 am
Version: next

Re: Increase CPU usage to more than 15%

Postby Hooray » Fri Jan 31, 2020 1:43 pm

bugman wrote in Fri Jan 31, 2020 1:33 pm:If you can code, you could potentially make FG use more cores. But the result of the interprocess communication for synchronising the property tree would be devastating for the frame rate.


synchronization/concurrency at the property level is not logical, most of FlightGear's code base would have to be restructured to benefit from that - even if we had a thread-safe property tree implementation already. The generally agreed upon consensus among core developers on the devel list has been subsystem-specific property trees holding subsystem-specific state in their own trees and publishing that in a read/write fashion (akin to having a single global tree, with "mount points" for individual subsystems that may run in their own threads or processes).

You end up with a LDAP-like hierarchy of trees, that would by default by run in the single sequential main loop, but that could also be easily run outside the main loop.

Basically, suitable SGSubsystem instances would become "servers" hosting their own equivalent of a susbystem-specific property tree that deals with get/set and notification/subscription requests. At that point, you don't run into concurrency issues - and such subsystems would reach out other subsystems to fetch relevant state (think FDM, autopilot).

Do note that this is very much in line with the long-standing idea of workings towards HLA/RTI adoption, but even "just" an Emesary-based approach would work well enough.

Some of the really low-hanging fruits would be stuff like the AI system, which already uses its own dedicated branch in the global property tree.

Each property tree would be hosted by the owning sgsubsystem and it would provide a GET/SET and PUBSUB mechanism, with very few (but well-defined) synchronization points.

At that point, it would be pretty straightforward to move such SGSubsystem instances into their own SGThread instance or even a dedicated process, as repeatedly suggested by David Megginson, Erik Hofman and others: http://wiki.flightgear.org/Remote_Properties

Another really obvious candidate to tinker with this concept would be the "fgtape (instant replay)" subsystem, because it's not much more than a property recorder - so it merely needs to get/copy property from the global tree and process them internally, thus it could be trivially made to run outside the main loop.

Given how much legacy code lives in FlightGear, concurrency at the data structure level (property tree) is unlikely to provide any long-term benefits, other than demonstrating what a piece of crap FlightGear is from an architectural point of view - identifying a handful of low-hanging fruits, i.e. SGSubsystems with straightforward property tree dependencies is likely to provide much more bang for the buck, without introducing ugly threading issues.

Additional background info, with a focus on threading out the Canvas system using the same approach, is to be found here: Running Nasal in a separate thread for better performance

Besides, look at Erik's recent comments in the HLA/RTI thread (01/2020):

https://sourceforge.net/p/flightgear/ma ... /36901371/
Erik wrote:The main problem, after reading up on it a bit lately, would be the way
the property tree is used. This needs cleaning up: Every federate needs
a clean separation layer from the rest of the code. Including not
looking up properties from other modules using the property tree.

So the first thing is to determine what modules to use. My take so far:

1. Visual System
3. Input System
3. FDM
4. AI Traffic
5. Weather System
6. ATC
7. Sound System(*)

So the first stab would be to create a private property tree for all
these modules and create an interface to synchronize it with the other
modules. Once that is done you could use these interfaces for HLA.


And now look at the following posting from 2016:
https://sourceforge.net/p/flightgear/ma ... /35134122/
Erik wrote:I wanted to setup a remote property tree where several
instances of FlightGear could synchronise a subset of the property tree
over the network.


And here's the original topic dating back to 2004:

https://www.mail-archive.com/flightgear ... 28870.html
Erik wrote:I have been working on extending the property code to add an SGRemoteProperty class to access properties on a remote host instead of locally. Most of the tree is cached locally, but queering the value of the end-node is done through a socket connection.

I have this sort of working (but need more debugging). Unfortunately I got detracted by political issues (which went great BTW. It looks like my local airport is saved) and didn't do much programming ever since.

Next to the SGRemotePropertyNode I've also been considering queering multiple properties in one shot, instead of one by one.



Basically, the idea has been around for 15+ years now, including even working code - it just never got committed apparently.
But the concept is sound and absolutely in line with the HLA/RTI and Emesary efforts.
Last edited by Hooray on Sat Feb 01, 2020 9:27 am, edited 1 time in total.
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: Increase CPU usage to more than 15%

Postby Thorsten » Fri Jan 31, 2020 2:11 pm

What incorrect is on my info about LOD < visibility limit and user will see end of the world ?


Well, read the thread, then you know - your statement is incorrect because configurable parameters are not limits in any sense.

What incorrect is in my statement with picture from FL520 on HD4000 with default FG settings ?


It is a picture of a Concorde with no relation to the topic of the thread.

Again, after upgrade my PC I have not significant benefit from more powerfull CPU and GPU in FG. For example, in Blender, I have huge performance benefit. My old machine was not able handle P3D v4.5. This new without significant problems. In 32 bit FSX I had FPS gain significant larger than in FG. This is reality.


Well, I on the other hand am enjoying 60 fps solid with settings maxed out on my gaming rig, and I consistently see improvements over my less powerful computers, so... FG evidently can run fast on high-performance computers, if you don't see any of that, chances are you have configured a bottleneck somewhere.

But, well, you've stated more than one time that you want to enjoy P3D, and you consistently bad-mouth FG, often being factually incorrect, so...

Anyway, to my knowledge X-Plane manages to utilize all CPUs by running real FDMs for AI-traffic (translation - it basically just wastes computation cycles for something you won't really ever see much) - it gives you the cozy feeling that your computer is fully utilized, but doesn't really render anything faster.

I suppose it'd be easy to add an option to make FG just add 'waste' threads which don't really do anything - then we could skip all questions about CPU utilization.

Translation: You're assuming a full CPU load means that something reasonable is being done - that however isn't always the case.
Thorsten
 
Posts: 12490
Joined: Mon Nov 02, 2009 9:33 am

Re: Increase CPU usage to more than 15%

Postby wkitty42 » Fri Jan 31, 2020 3:24 pm

V12 wrote in Fri Jan 31, 2020 8:14 am:wkitty42 :
Do You realize that Advanced weather visibility limit is 250 km ?

is it clamped to that distance?

V12 wrote in Fri Jan 31, 2020 8:14 am:And bare LOD in FG higher than 2018.X.Y is only 200 km.

is that one clamped as well?

V12 wrote in Fri Jan 31, 2020 8:14 am:You should not set AW visibility limit higher than bare LOD, because in perfect clear weather You will see "end of the world".

here's the active settings i use in my fg-370km-horizon.rc file...
Code: Select all
# visibility is in meters
--visibility=370000
# haze-factor is in kilometers
--prop:/local-weather/config/ground-haze-factor=370
# vis-range is in meters
--prop:/sim/rendering/clouds3d-vis-range=370000
--prop:float:/sim/rendering/clouds3d-density=0.25000000

# set scenery LODs
# we're using the deltas so each number is added to the previous one
# in the sequence: detailed + rough + bare
# these are in meters
--prop:float:/sim/rendering/static-lod/detailed=3704.0
--prop:string:/sim/rendering/static-lod/detailed-description=0m to 3704m (2.0nm)
--prop:float:/sim/rendering/static-lod/rough-delta=51856.0
--prop:string:/sim/rendering/static-lod/rough-delta-description=3704m (2.0nm) to 55560m (30.0nm)
--prop:float:/sim/rendering/static-lod/bare-delta=314400.0
--prop:string:/sim/rendering/static-lod/bare-delta-description=55560m (30.0nm) to 370000m (199.8nm)
# set the old properties as well because some things still use them
--prop:float:/sim/rendering/static-lod/rough=55560.0
--prop:float:/sim/rendering/static-lod/bare=370000.0


V12 wrote in Fri Jan 31, 2020 8:14 am:And how altitude for maximum possible visible Earth surface ?

dist=earth's radius divided by tan (AOV/2)
where AOV is vertical angle for FOV (horizontal AOV is much larger)

Answer is simple - theoretically in infinity distance. But practically for standard human AOV cca 70 degs without head and eye movement it is around 9100 km. This is distance, where Earth will fill Your field of view vertically and You can observe surface with with maximum possible details.

i think i understand what you're saying... i forget the numbers i posted and you didn't quote them so it is hard to see what they were compared to what you posted... not a big deal, though...

it was a rhetorical thought question that i'm still not sure i phrased correctly... basically, i'm curious how high one needs to be to see the entire half of the earth facing them... i mean, you cannot see past the most extent edge so at what altitude do you have to be when the extent edge is visible on both of your left and right visual limits...

i ask the question because all of the formulas i find will tell you the distance to the horizon... there is no point where they stop growing because your as your altitude increases, the distance to the horizon also increases even if the horizon span is equal to the earth's radius... it is also probably a better thought discussion for another area instead of this topic...
"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: Increase CPU usage to more than 15%

Postby bugman » Fri Jan 31, 2020 3:27 pm

@Hooray: I've looked at such things with the test suite (in a number of my branches). The issue though is that you could spend a lot of time implementing the private property tree and synchronization method, only to find out that the data transfer between threads is a bottleneck that causes things to run slower than without threads. This issue is quite important and causes developers to battle through many failed threading attempts (e.g. In one of my RL projects, I attempted 4 different parallelizations with different techniques and granularity, and all were much slower than serial execution, so I had to abandon this effort after a year of work).

Plus this is more interesting for developers - what users want is higher framerates, which threading the CPU in most cases will not do.

Regards,
Edward
bugman
Moderator
 
Posts: 1808
Joined: Thu Mar 19, 2015 10:01 am
Version: next

Re: Increase CPU usage to more than 15%

Postby erik » Fri Jan 31, 2020 3:36 pm

Thorsten wrote in Fri Jan 31, 2020 2:11 pm:Well, I on the other hand am enjoying 60 fps solid with settings maxed out on my gaming rig.

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).
Current: Parachutist, Paraglider, Pterosaur, Pilatus PC-9M and variants, ERCO Ercoupe, Fokker Dr.1, Fokker 50, Fokker 100
Less active: Cessna T-37, T-38, Santa Claus. Previous: General Dynamics F-16. Worked on: Wright Flyer
erik
 
Posts: 2244
Joined: Thu Nov 01, 2007 2:41 pm

Re: Increase CPU usage to more than 15%

Postby Hooray » Fri Jan 31, 2020 3:47 pm

bugman wrote in Fri Jan 31, 2020 3:27 pm:@Hooray: I've looked at such things with the test suite (in a number of my branches). The issue though is that you could spend a lot of time implementing the private property tree and synchronization method, only to find out that the data transfer between threads is a bottleneck that causes things to run slower than without threads. This issue is quite important and causes developers to battle through many failed threading attempts (e.g. In one of my RL projects, I attempted 4 different parallelizations with different techniques and granularity, and all were much slower than serial execution, so I had to abandon this effort after a year of work).

Plus this is more interesting for developers - what users want is higher framerates, which threading the CPU in most cases will not do.


Right, that is the "data flow/dependencies" part mentioned previously - it only makes sense to look at factoring out certain subsystems, i.e. those that are primarily about properties and that don't don't do much else in terms of calling out other subsystems/APIs.

In other words, the power of the "private property tree" only comes into play if it can be trivially implementing by getting rid of the hard-coded property tree assumption, and using a private/local one that is specific to the owning subsystem instance. For instance, having a private property tree for the autopilot, the AI system or the canvas is relatively straightforward - because these systems are already primarily property-driven, i.e. that's what they use as their inputs - and ideally, the output of the subsystem should also be just/primarily "properties", too - which applies to things like the FDM, the autopilot, the route manager - and the AI traffic system (because it's basically just a multiplexer on top of a pseudo-fdm/autopilot and route manager).

When it comes to the canvas, the output is not "just a property (tree)" but instead a whole texture - and that in itself makes little sense to create in another process (unless you use shared memory or some other IPC to access it across process boundaries) - the thing is, all the fetching, update and texture re-creation can be done asynchronously, and that is something that OSG is pretty good at.

Given what we currently have in terms of canvas functionality, most canvas textures could be created asynchronously - we're only just about in the process of adding more complex canvas elements, that add to the complexity - e.g. texture elements/parts that render scene elements or sub-cameras.

Also, like you said, end-users care primarily about frame rate - but the other thing you forgot to mention is frame spacing, i.e. the latency needed to build a single a frame, and doing that at 30+ hz - in other words, it does make sense to free up the main loop to end up with a tight loop that primarily fetches needed resources (think textures or property state) from other subsystems that may not necessarily run inside the main loop.

The neat thing about Erik's idea of supporting "remote properties" or David Megginson's idea of using subsystem-specific SGPropertyNode _root nodes is that this setup scales pretty well without requiring a completely overhaul of FlightGear, that is, as long as you primarily deal with property-based subsystems that mainly deal with properties for their input/output needs.

Like I said, this applies to the property tree recorder subsystem (fgtape), but also things like AI traffic - to see how much of an impact these systems have on flightgear at runtime, you can simply disable/remove them completely from the main loop, and you'll be surprised to see what you are approaching a runtime profile with a rather competetive framerate and frame spacing.

And like you said, there are many other subsystems whose I/O needs are not as straightforward unfortunately, but there's at least a handful of subsystems that could be moved to worker threads by going down that path, i.e. by using subsystem-specific property trees that are used for computation purposes, so that inputs are fetched from the main/root tree (the global one) and outputs copied back into the tree after the computation has finished.

The added benefit being that you end up with a design that can also be distributed, i.e. so that multi-instance setups can share certain subsystems (think multiplayer or multi-machine setups like those commonly shown at FSWeekend/Linuxtag)

There is the remaining issue that our way of adding scripting functionality to the simulator doesn't scale at all, and whatever is currently added via Nasal to the sim, isn't easily parallelized, let alone distributed - because of the free-form nature of contributions supported by Nasal, on top of fragile concepts like timers and listeners.

One of the first steps would be examining how much is to be gained from disabling subsystems entirely, and compare frame rate/spacing accordingly.
The next step would be sampling property I/O at the subsystem level, which is unfortunately not as straightforward - but at least in the case of subsystems using their own dedicated branches in the global tree, can be done easily by tracking read/writes to that location (think multiplayer, /ai or /canvas, /logging etc)

Thinking about it, that would actually be a worthwhile addition to the built-in performance monitor: sampling property I/O per subsystem, over time - i.e. in terms node reads/writes, possibly in conjunction with listener/timer requests handled per time unit
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: Increase CPU usage to more than 15%

Postby erik » Fri Jan 31, 2020 4:08 pm

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.

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.

Erik
Current: Parachutist, Paraglider, Pterosaur, Pilatus PC-9M and variants, ERCO Ercoupe, Fokker Dr.1, Fokker 50, Fokker 100
Less active: Cessna T-37, T-38, Santa Claus. Previous: General Dynamics F-16. Worked on: Wright Flyer
erik
 
Posts: 2244
Joined: Thu Nov 01, 2007 2:41 pm

Re: Increase CPU usage to more than 15%

Postby GinGin » Fri Jan 31, 2020 4:17 pm

And bare LOD in FG higher than 2018.X.Y is only 200 km



I don't understand. Do you mean that in 2019 version, you can't set Bare Lod to whatever you want?
GinGin
 
Posts: 1580
Joined: Wed Jul 05, 2017 11:41 am
Location: Paris
Callsign: Gingin

PreviousNext

Return to Graphics

Who is online

Users browsing this forum: No registered users and 4 guests