20,741
edits
FlightGear Newsletter September 2014: Difference between revisions
Jump to navigation
Jump to search
m
FlightGear Newsletter September 2014 (view source)
Revision as of 21:59, 13 September 2014
, 13 September 2014→forum2wiki
(→Aircraft are moved to SVN: +- heading; + subheadings; etc) |
m (→forum2wiki) |
||
| Line 57: | Line 57: | ||
=== Background === | === Background === | ||
For our aircraft developers who usually don't read the mailing list (I hope they doesn't exist but just in case), please read this topic: https://sourceforge.net/p/flightgear/mailman/flightgear-devel/thread/DUB127-W168600DE27B42094E5263EC3C10%40phx.gbl/#msg32809711 | For our aircraft developers who usually don't read the mailing list (I hope they doesn't exist but just in case), please read this topic: https://sourceforge.net/p/flightgear/mailman/flightgear-devel/thread/DUB127-W168600DE27B42094E5263EC3C10%40phx.gbl/#msg32809711 | ||
== Understanding FlightGear Performance Issues == | |||
Several FlightGear users have pointed out inexplicable FG "slowness" that originally seemed related to the property rules subsystem - which is a subsystem that Torsten originally wrote/ported, so he investigated a little and managed to track this down to a pretty serious bug in the effects subsystem that may end up registering thousands of identical listeners, despite effects/shaders not even being in use necessarily. | |||
So the property rules code wasn't even the culprit but obviously it deals with properties, so easy to mis-identify as the troublemaker. | |||
As some of you may know from working with Nasal code: listeners are not in and of themselves expensive, but running identical listeners over and over again each frame is getting unnecessarily expensive quickly. This doesn't just apply to scripting space, but also to C++ space - here, it's the sheer performance offered by native C++ code that makes it much harder to identify such problems, because code that would bring the simulator down to its knees in Nasal may very well still be "fast enough" for most people with fast computers, despite being still very much "broken", and plain wrong. | |||
As can be seen on the devel list, Torsten has been spending the last weeks troubleshooting the effects system, which isn't exactly straightforward because its original developer is not currently involved in FlightGear, and the code is pretty sophisticated and even multi-threaded (which means that parts of the code may be running concurrently on different CPUs) - however, Torsten did report pretty significant performance improvements recently - he's just pushed his work to a new branch so that other developers (and people building from source!) can have a look and test his changes and report feedback/issues - this will probably mean that it may take a few weeks until all the feedback has come in and implemented - but performance should be improved significantly by then - which also addresses the whole "when will 3.2 be released" question. | |||
Also, Hooray recently built fg on a dual-core netbook with Intel GMA graphics (1gb RAM) to see if/how well Canvas is supported there (some people reported white RTTs due to lack of FBO support) - it is true that doing this more regularly would probably help identify certain issues much earlier - it seems that a few contributors are still trying to spin up FG once in a while on their old computers - Thorsten repeatedly mentioned doing that for regression testing purposes when testing his own work. | |||
But FG would indeed be in a better shape if had some way to do this more often, possibly automatically on some kind of headless build/regression testing server - which kinda is what a few people have been working towards: | |||
* [[FlightGear Headless]] | |||
* [[Testing]] | |||
Things like the recently discovered listener issue in the effects subsystem or massive memory leaks would stand less of a chance of going unnoticed if we had more people testing FG on old hardware - but it's a chicken/egg problem because you need to be pretty familiar with FG to make it work at all, so most people don't bother - and as a coder you tend to prefer writing code over testing obviously, so given the lack of feedback, FG is leaning more towards power users with the latest GPUs and 1+ gb of VRAM unfortunately - simply because that's where all the testing manpower typically is. | |||
People wanting to change that, need to roll up their sleeves and get involved, and PLEAE provide feedback. | |||
'''All''' testing on, and development for, such systems would benefit FG in the long term, because hardware support/compatibility would increase over time - which would also make it possible to target other architectures, i.e. gaming hardware, Rasberry Pi and so on: [[Howto:Optimizing FlightGear for mobile devices]]. | |||
And here some initial observations based on running FlightGear on an underpowered Netbook with integrated Intel GMA graphics: | |||
* our existing GUI truly sucks: whenever a PUI dialog is opened, the frame rate is becoming single-digit | |||
* once the dialog is closed, it will spike up to ~30 fps, with the Canvas/REPL window still shown (!) | |||
* hiding the PUI menubar further helps increase frame rate and improve frame spacing | |||
* hiding the menubar AND closing the REPL dialog, I am getting ~45-50 fps using the minimal startup profile, frame spacing is then roughly in the 60s | |||
* the navcache is a huge resource hog for people on such systems - initializinig/rebuilding the cache is taking ages (10-20+ minutes here !) | |||
* it would make sense to refactor the navcache and turn it into a library, so that we can prebuild the navcache - and either do so while packaging a release, or alternatively, during installation (plenty of time there!) | |||
* in addition, threading would make sense probably, when the navcache was being rebuilt, the 2nd core was idling all the time while 1 core was at 100% | |||
* Canvas/RTT (FBOs) actually work here (which is a good thing for FGPanel/FGCanvas usage) | |||
* there are a bunch of default options that will "break" FG for users on such systems, including a number of options that will trigger OpenGL/OSG errors early on | |||
Hooray is hoping to do further testing, using the system monitor and the built-in profiler - keep in mind that this still is the code that contains some pretty severe performance bugs. | |||
If we had more people doing this kind of testing, we could definitely identify, and hopefully eliminate, quite a few performance issues that would not be noticeable on a typical developer's machine. | |||
So this could be a worthwhile thing to do, and it would help FG in the long term - i.e. even benefit power users who have 2048 MB of VRAM and 8 cores/12 gb of RAM. | |||
The really interesting "benchmark" here is running osgviewer and fgviewer as comparison, because what FG is doing here isn't much different functionality-wise, and it's using the same technology stack (i.e. OSG), so should provide similar performance. | |||
Unofortunately, we generally don't have many people who do a lot of testing, troubleshooting - or even just provide feedback via the issue tracker - it is definitely true that the Canvas GUI is much faster here, despite containing a ton MORE Nasal code, and despite being MUCH more dynamic/flexible than our existing PUI dialogs. | |||
It would really be awesome to find a handful of people with access to old/slow hardware interested in testing and maybe troubleshooting things - while it would be great if those people knew how to build from source, and how to use git/gitorious, I don't think that's even necessary - we can definitely provide a lot of infrastructure and advice, but most of us don't typically have access to these kinds of computers. And while some of us admittedly aren't bothered by it, it is very true that FlightGear as a whole will benefit from teasing out certain bugs/issues, no matter if those are slowing things down due to CPU/GPU or RAM/VRAM utilization. | |||
But we really need more people willing to do this kind of testing and who can provide feedback regularly - and start yelling once something that previously worked, stops working or is becoming unnecessarily slow - there are a bunch of issues that should have never made it into the code, but which went unnoticed for months (or even years), because it's really only power users/contributors and developers who do this kind of testing, and as I am seeing right now, certain issues are pretty well "masked" on an 8-core, 10 gb, 2gb VRAM machine obviously ... | |||
We've been hoping to create some kind of "benchmark" for years - and this is one of those things that would truly help FlightGear in the long term, because we'd get quantifiable data over time, so that we can easily tell how a certain startup/run-time feature behaves in correlation with how it behaved previously, i.e. compared to updated dependencies (OpenAL, PLIB, OSG) - but also changes to the C++ code in SG/FG itself. | |||
People are generally quick to point at Nasal and its known GC issues, but are usually not experienced enough to look behind the scenes, and the amount of existing C++ code that is doing things in a slow fashion, code that's been lurking in the source tree for years more often than not. Creating some kind of simple benchmark would help all of us, no matter the kind of hardware we have: [[FlightGear_Benchmark]]. | |||
If you're interested in getting involved with testing FlightGear and improving compatibility for older/slow systems, please get in touch with Hooray on the forum. | |||
<gallery mode=packed widths=230px heights=230px> | |||
Fgfs 3.2 on a dual-core netbook.png|FlightGear 3.2/Canvas working on a dual-core Netbook with Intel GMA graphics showing the [[Interactive Nasal Console]] dialog | |||
Comparing Native Canvas GUI Performance over PUI.png|A native [[Canvas]] window showing the new [[Aircraft Center]] dialog (good performance) | |||
System-monitor-on-netbook.png|Screen shot showing a number of performance issues in a handful of FG subsystems, especially the PUI GUI | |||
Pui slowness.png|The old PLIB/PUI GUI is shown here rendering a Canvas Widget with a [[MapStructure]] layer, a few users have reported that PUI is significantly slowing down the simulator | |||
MapStructure self test over embedded PUI widget.png|And for comparison a native Canvas window also using the [[MapStructure]] framework,without going through PUI (better performance) | |||
</gallery> | |||
== Interview with a contributor == | == Interview with a contributor == | ||