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 V12 » Sun Feb 16, 2020 5:45 pm

Interesting reading. I have idea - let's make FG like database (MySQL, Firebird, PostgreSQL etc) :
- database server with database containing property tree data
- modify FDM from prop tree to access database
In result :
- db server runs as process 0
- FDM runs as process 1, read / write data to the database
- weather system runs as process 2
- AI manager as process 3
- sound server
- Nasal (or any replacement, best solution is use compiler, not interpreter)
- bla bla bla
- OSG (or Vulkan or something other) render read data from db, do all render related jobs and send data to GPU

This solution should work better than actual, where is impossible that all thread simultaneously works with same memory location with stored prop-tree data. All processes should work parallel.
Is this possible ?
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 Hooray » Sun Feb 16, 2020 6:15 pm

See the following wiki articles, some of which were written by core developers like James Turner (leading core developer):

http://wiki.flightgear.org/Distributed_ ... FlightGear
http://wiki.flightgear.org/Distributed_ ... Simulation
http://wiki.flightgear.org/Modularizing ... FlightGear

Regarding compilation of Nasal, feel free to search the forum for "llvm + nasal": search.php?st=0&sk=t&sd=d&sr=posts&keywords=llvm+nasal
Speaking in general, compilation/interpretation is not the bottleneck for the time being.

Regarding the AI component, see: http://wiki.flightgear.org/FGTraffic

Regarding OSG concurrency, there is too much legacy OpenGL code in FG which would need to be phased out, also the current viewer setup/architecture isn't prepared for additional concurrency, the project would need to adopt/switch to PagedLOD and CompositeViewer:

http://wiki.flightgear.org/PagedLOD
http://wiki.flightgear.org/CompositeViewer_Support

Speaking in general, the FlightGear project has been hoping to adopt HLA/RTI for better modularization and concurrency support using processes instead of threads: http://wiki.flightgear.org/High-Level_Architecture

I don't think there is a Vulcan related article for the time being, but as you can surely see by now many of the people "in the know" have already discussed some of FlightGear's actual shortcomings, including ways to possibly address those over time

It would seem like a good idea to read up on what's been previously said in the context of the performance debate.

You could also create some of your own benchmarks to help with testing/profiling FlightGear so that actual hot spots can be identified:

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

As you can see, there are plenty of resources to form an informed opinion about FlightGear's performance and issues related to that.

Admittedly, it may take a while to look up what's been previously said and done in the context of this discussion, but it will at least help you get a more comprehensive picture of all the variables involved in the equation.

The other issue being, that it simply isn't realistic to expect that a single person is going to single-handedly re-architecture FlightGear as a whole based on random ideas like those tossed around in your previous posting. The OSG/HLA debate/effort have been ongoing for over 10 years meanwhile. Also, the GUI2Qt transition is another project where the timescale and expectations has been massively undeestimated by some folks.
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 bugman » Sun Feb 16, 2020 11:45 pm

It's even simpler than that ;)

  • If your problem is a serial operation, e.g. step 3 requires the output of step 2, and step 2 requires the output of step 1, parallelisation and running on multiple cores will absolutely always be slower.
  • If you have a parallel operation, e.g. you can run A, B, and C independently, running on multiple cores may or may not make the execution faster. You have two counteracting concepts:
    • Firstly is the granularity of the problem. Do you run A, B and C seperately, do you run different subparts of these seperately, or do you run batches of A, B, and C together?
    • Secondly is IPC (interprocess communication). If you ever get your hands dirty with parallelisation, you'll quickly find that your best parallelisation designs are destroyed by IPC costs. You have to try a number of designs, starting from scratch each time, to test and see if a design will actually improve execution speed.

As I have mentioned before, I had a problem in my day job that was partly parallelisable. But after 4 attempts with different granularity and designs, I had to write off 1 entire year worth of work as all 4 attempts were slower parallelised than the standard serialised calculation. This was after 3 very successful parallelisations in other projects, with close to 100% parallelisation efficiency. Some problems are simply not solved faster by throwing more cores, CPUs, or nodes at it.

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 V12 » Mon Feb 17, 2020 11:09 am

Thank You for explanation.
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 Hooray » Mon Feb 17, 2020 4:48 pm

unfortunately, it's not such a black/white issue at all - when it comes to non-trivial applications with dozens of subsystem that were not designed with concurrency in mind, you will rarely run into situations that are strictly parallel or strictly sequential - rather, it is much more likely that you will run into non-obvious dependencies, some of which may be subject to change at runtime - for instance, a set of subsystems may depend on another set of subsystems given certain constraints only, but once those change - the whole relationship/dependency chain is also affected - this applies in particular to a legacy code base like FlightGear, which has been growing for over 2 decades meanwhile.

Thus, bugman's example is only useful in a textbook situation - otherwise, you will need to re-architect/partition the simulation according to parallel vs. sequential dataflow dependencies. Absent that, you end up wasting months, and possibly years, optimizing an ill-understood problem.

Adding multi-threading or concurrency to an application well after the fact, is unlikely to work too well - it makes only sense to look at specific edge cases to see if/how those /might/ benefit from such an effort
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 bugman » Tue Feb 18, 2020 6:58 pm

Hooray wrote in Mon Feb 17, 2020 4:48 pm:Adding multi-threading or concurrency to an application well after the fact, is unlikely to work too well - it makes only sense to look at specific edge cases to see if/how those /might/ benefit from such an effort


That is not my experience at all. If you can identify the ideal granularity where IPC does not squash parallelisation efficiency, then implementing threading or other parallelisation techniques is very much worthwhile. Oh, the parallelisation does have to target part of the code that takes significant CPU, i.e. a bottleneck.

In the case of Flightgear, no one has identified a point that can be beneficially parallelised. Spinning off some parts into its own thread (e.g. Nasal GC and AI) , can help a little. But there is no code point - a function or class - identified where multi-processing will have a large performance impact.

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 » Tue Feb 18, 2020 7:46 pm

you do realize that we're basically saying the same thing, are you ?
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 bugman » Tue Feb 18, 2020 9:21 pm

Pretty much. Except for the fact that adding parallelisation after the fact can actually work quite well - if done correctly and the problem is innately parallelisable. I have experience with 3 examples where after-the-fact parallelisation worked wonderfully, and one example where after-the-fact parallelisation failed miserably. And I still haven't seen one single place in FlightGear or SimGear core that would benefit from parallelisation.

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 » Tue Feb 18, 2020 9:27 pm

you mean actual examples or theoretical ones (keeping in mind dataflow dependencies) ?
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 bugman » Tue Feb 18, 2020 9:45 pm

Real examples, of course :)

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 Richard » Wed Feb 19, 2020 11:53 am

V12 wrote in Sun Feb 16, 2020 5:45 pm:Interesting reading. I have idea - let's make FG like database (MySQL, Firebird, PostgreSQL etc) :
...
Is this possible ?


Basically not possible because databases are not suitable for real time usage and so they can lock for a long time; reject updates (because of conflicts).

As I've previously said there is very little to be gained in terms of frame rate from any extra use of the CPU with more threads; and I've proved this by implementing multi-threaded rendering. Using multi-threaded rendering on the F-15 does result in a slightly higher frame rate because the multi-threading saves around 4ms per frame however the rendering is still taking 18.68ms and that is at a location without that much terrain.

Image

The best performance improvement that we can make in FlightGear is still to have levels of detail in the scenery and there is work going on to try to fix this.
Richard
 
Posts: 810
Joined: Sun Nov 02, 2014 11:17 pm
Version: Git
OS: Win10

Re: Increase CPU usage to more than 15%

Postby GinGin » Wed Feb 19, 2020 4:35 pm

Thanks for the heads up
GinGin
 
Posts: 1580
Joined: Wed Jul 05, 2017 11:41 am
Location: Paris
Callsign: Gingin

Re: Increase CPU usage to more than 15%

Postby Hooray » Wed Feb 19, 2020 7:05 pm

Richard wrote in Wed Feb 19, 2020 11:53 am:The best performance improvement that we can make in FlightGear is still to have levels of detail in the scenery and there is work going on to try to fix this.


Intriguing, but if that's indeed the case, that should in turn imply that people flying in areas without any scenery (tiles) being loaded (think atlantic/pacific ocean) should not see any performance issues, shouldn't it ?
Also, what about aircraft like the spacecraft that get away without clogging up the tile manager, using Thorsten's EarthView approach instead ?

In other words, if FlightGear's primary performance issues are scenery/terrain related, that should show up for people flying complex aircraft in locations without any scenery loaded - like the 777 or the space shuttle, both of which happen to use fairly complex cockpits and both featuring a number of MFDs

This is where draw masks can come in handy to see how much impact disabling/enabling certain scene elements actually has, including things like Canvas displays:

http://wiki.flightgear.org/Draw_masks
Image
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 V12 » Wed Feb 19, 2020 10:36 pm

Richard :
Where in the Your graphs are Nasal jobs, AI management jobs etc ?

We have Oracle database for realtime production process monitoring with write data rate around 1000 values per second. No problem. I can monitor all subprocesses via SQL queries, make online graphics visualization of material flows etc. With good commit policy You never fall into problems.
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 Hooray » Thu Feb 20, 2020 11:23 am

V12 wrote in Wed Feb 19, 2020 10:36 pm:Richard :
Where in the Your graphs are Nasal jobs, AI management jobs etc ?



Regarding your question about "Nasal jobs" and "AI management" etc, refer to the pointers I previously posted, specifically: http://wiki.flightgear.org/Howto:Use_the_system_monitor

In other words, at least for the time being, subsystem-specific performance stats are note exposed at the OSGStatsHandler/FGStatsHandler level - and that also applies to the Nasal GC specifically, which can be triggered via other subsystems, because Nasal code can be triggered via timers and listeners

In addition, what's happening behind the scenes of each Canvas-based display is also pretty obscure, because the relationship between Nasal code updating OSG textures "on the fly" by going through the property tree (via listeners) adds quite a bit of indirection/overhead (think dozens of nested groups updating hundreds of nested elements).

Background:
http://wiki.flightgear.org/Canvas_Troub ... _Osg_Stats
http://wiki.flightgear.org/How_the_Nasa ... ks#Patches
http://wiki.flightgear.org/Towards_bett ... time_stuff
http://wiki.flightgear.org/Resource_Tra ... atsHandler
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

PreviousNext

Return to Graphics

Who is online

Users browsing this forum: No registered users and 4 guests