Board index FlightGear Release candidates

FlightGear 3.6.0 RC Frame Rate and Graphics Experience

Release candidate testers are encouraged to post their feedback here. Please read the introduction topic for details.
Forum rules
Please read the introduction topic for details.

Re: FlightGear 3.6.0 RC Frame Rate and Graphics Experience

Postby Hooray » Wed Oct 28, 2015 6:17 pm

Thorsten wrote in Wed Oct 28, 2015 6:18 am:feel free to blame everything to Nasal in any particular case without investigation, but don't expect too many people to be impressed.



To be fair, I wasn't (see my original response) - equally, you may want to give me the benefit of the doubt that I actually belong to the tiny group of people who understand Nasal internals, including the GC scheme.
Which is not to say that your statement is wrong, but the Nasal GC is one fairly prominent culprit and there are fairly good test-cases to see if that's the case here.
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: 11292
Joined: Tue Mar 25, 2008 8:40 am

Re: FlightGear 3.6.0 RC Frame Rate and Graphics Experience

Postby rogerx » Thu Oct 29, 2015 3:45 am

Just read the "Garbage Collection" section within flightgear/Docs/Nasal-doc.pdf and found it a good quick read.

Then grepped some Nasal code, and found the following. Am I correct, people are using the Nasal update/timer to check something 5 times a second? Since the timing seems consistent across many files, I presume I'm misinterpreting something.

$ fgrep aircraft/ -r -e update -i

./747-400_20141113/747-400/Systems/744_nd.xml: <update-interval-secs
type="double">0.1</update-interval-secs>

./727-230_20140909/727-230/Nasal/tyresmoke.nas:UPDATE_PERIOD = 0.3;
UPDATE=0.3 (~3 times per second?)

Some events every frame

./747-400_20141113/747-400/Systems/744_pfd.xml: <update-interval-secs
type="double">0.05</update-interval-secs>

./747-400_20141113/747-400/Models/Cockpit/Instruments/EICAS/primary.nas:
settimer(func me.fast_update(), 0.05);

# 5 updates per second are good enough
settimer(func { BrakeSys.update(); },0.2);
rogerx
 
Posts: 65
Joined: Sun Jan 08, 2012 9:39 am
Location: Conneaut, Ohio

Re: FlightGear 3.6.0 RC Frame Rate and Graphics Experience

Postby Thorsten » Thu Oct 29, 2015 5:59 am

To be fair, I wasn't (see my original response) - equally, you may want to give me the benefit of the doubt that I actually belong to the tiny group of people who understand Nasal internals, including the GC scheme.


I believe you're quite able to understand when the GC is the culprit when you analyze a system thoroughly - however there's close to no reliable data posted in this thread, so the turn that we blame it all on Nasal GC seems premature to me. That's really all I'm saying. I was never able to observe a Nasal GC bottleneck myself unless I forced the issue by doing a ridiculous number of operations per frame (even on my old computer), but as you say, they're fairly high powered so that may not be representative. I was able to observe ample variation of frame spacing using a 'no Nasal running' environment on all of my machines though, so other (non-Nasal) culprits seem to be able to even affect a gaming rig.
Thorsten
 
Posts: 10243
Joined: Mon Nov 02, 2009 8:33 am

Re: FlightGear 3.6.0 RC Frame Rate and Graphics Experience

Postby rogerx » Thu Oct 29, 2015 3:21 pm

Although I tend to agree using older hardware shows bottlenecks or slowness more readily (ie. Running Java or Python on older i686 or slower computers), just using the f16 flight model last night and today, shows my frame rates pegged at 59-60 FPS. Using the default Cessna C172P flight model, I can definitely see slowness to 35 FPS just sitting on the airport runway. Now whether this is due to looking through transparent glass or Nasal Garbage Collection, shrugs. But my past experience with simgear bugs when compiling within anything higher than -o2 or debug, I'm tending to sway towards Nasal code issues. In other words, the f16 3D cockpit model seems very basic, versus the more feature rich C172P default model. (ie. More switches and gauges, using Nasal code.)

Looking at on-screen statistics, I'm seeing brief Event spikes and mainly GPU/DRAW significant spikes during drops in frame rates using the F16 model at the default runway. If I increase the field of view to maximum, (120 fov, right click and mouse scroll wheel), I can permanently peg the drop in frame rates when using the f16 model and using external view to 35-40FPS. The on-screen statistics show GPU/DRAW being heavily utilized, while most other values are nominal or nothing. Currently, I'm on external (Model) view looking at the f16 model and the entire airport. Now if I get a code tracer and reproduce this effect, I'll be able to see the code function calls causing these spikes in GPU/DRAW usage. (ie. Maybe airport lighting. AI are disabled.)

Screen shot of Flightgear exhibiting extremely intermittent frame rate delay when using f16 model. (The significant frame rate delay can be permanently stuck to 30-40FPS when view settings are set to something similar within my screen shot.)
Image

About the only thing I'm seeing moving, besides nothing within the GL display, is within the internal properties /sim/rendering/eye-altitude-m is constantly fluctuating between 1.08289, errr, seems to be constantly increasing from the sixth digit to the right of the decimal.
rogerx
 
Posts: 65
Joined: Sun Jan 08, 2012 9:39 am
Location: Conneaut, Ohio

Re: FlightGear 3.6.0 RC Frame Rate and Graphics Experience

Postby Hooray » Thu Oct 29, 2015 6:13 pm

timers and listeners are the methods used by Nasal code to create "subsystems" in scripting space.
there are basically subsystems in the main loop where timers/listeners can be invoked - either by "timing out" or by setting/changing a property.

In turn, a corresponding Nasal callback (=function) will be invoked

Nasal memory is not explicitly managed, but there is a handful of memory pools for different "objects" (numbers, strings, functions, vectors, hashes) - whenever that memory is running out, all active objects will be searched/marked, and unreferenced objects will be freed subsequently, as well as new objects allocated/created if needed.

The search/mark phase can be particularly heavy, i.e. is directly proportional to the number of total objects and references to them, so can also be influenced by a certain coding style - i.e. to reduce "GC pressure".

In general, it would make sense to disable other subsystems/features and see if the issue persists or not (or even just if it is affected).

However, none of the data that you posted so far is conclusive - so far, we don't know if your problem is related to Nasal or not. Which is ironically because people don't understand how to gather useful statistics, even though others still object to expose the corresponding metrics to the property tree ....

But if you are building from source, you can patch simgear using a snippet of code provided by ThorstenB, which dumps GC metrics to the console, and which shows if the GC is running or not - so fairly easy to match with any "stuttering".

Alternatively, you could come up with a reproducible test case (e.g. using a flight plan or flight recorder tape) and then disable everything else, while running fgfs inside gdb - once frame spacing is increasing, you can CTRL+C to interrupt execution and get a backtrace of what was going on at the time.
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: 11292
Joined: Tue Mar 25, 2008 8:40 am

Re: FlightGear 3.6.0 RC Frame Rate and Graphics Experience

Postby rogerx » Thu Oct 29, 2015 7:10 pm

The small snippet/patch enabling Nasal Garbage Collection tracing and/or dumping was posted here:

Re: [Flightgear-devel] Efficient Nasal coding (was: Stuttering at 1 Hz rate)
ThorstenB Sat, 02 Apr 2011 08:25:35 -0700
http://www.mail-archive.com/flightgear- ... 31762.html
rogerx
 
Posts: 65
Joined: Sun Jan 08, 2012 9:39 am
Location: Conneaut, Ohio

Re: FlightGear 3.6.0 RC Frame Rate and Graphics Experience

Postby Hooray » Fri Oct 30, 2015 7:19 am

yeah, but Thorsten is right - Nasal is only one potential culprit, and even if you should identify this to be the case here - you would still want to try different combinations of startup/runtime settings to ensure that this is generally the problem, and not some issue specific to a single airport/location or aircraft.

Also, we have patches to help identify problematic Nasal callbacks, i.e. in terms of dumping the GC pressure to the console (or logging it to a property), so that before/after metrics can be gathered, including the run-time of the GC, and the number of recurring allocations - e.g. temporary stuff.

But it makes only sense to explore all this, once you have confirmed that it is Nasal contributing to the lag you are seeing - like Thorsten said, there's a plethora of other potential factors, with Nasal being one of the most likely candidates, but certainly not the only one.

In general, it would make sense for us to expose these statistics and metrics at the property tree level, so that people can directly open a dialog and look at such Nasal related numbers (number of objects, references and frequency/duration of GC invocations, but also Nasal callbacks/modules contributing to GC pressure).

That would enable people to provide much more accurate data when posting bug reports - analogous to how the help/about dialog displays OpenGL/graphics related info.

However, the "no Nasal environment" mentioned by Thorsten above is an imaginary thing - as long as you don't exclude $FG_ROOT/Nasal entirely but also any $FG_AIRCRAFT related scripts that may be invoked - which frankly is a complicated issue, and problematic approach.

And as far as I am aware, I am the only one to succeed at coming up with a fgfs main loop without any Nasal running at all - which was necessary for being able to initialize Nasal much earlier - decoupled from the conventional main loop:

http://wiki.flightgear.org/Initializing_Nasal_early
Image

This kind of thing would make it possible to start up FG with Nasal disabled at the C++ level, so that the GC cannot run - and it would still be possible to use Nasal for startup-analogous to how rc.d boot scripts work on *nix, but don't have any runtime footprint once the corresponding run-level is reached.

In other words, you could tell people to start up fgfs with --disable-nasal and ask them if they're still seeing the same issues or not
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: 11292
Joined: Tue Mar 25, 2008 8:40 am

Re: FlightGear 3.6.0 RC Frame Rate and Graphics Experience

Postby rogerx » Fri Oct 30, 2015 10:37 am

If there's any possibility Nasal Garbage Collection could be an issue, there should be inline debugging for debugging Nasal Garbage Collection, versus having to manually patch the sources.

If it were my code, I would always have an option for debugging anything.

(One would think running Gentoo would make applying patching easier.)
rogerx
 
Posts: 65
Joined: Sun Jan 08, 2012 9:39 am
Location: Conneaut, Ohio

Re: FlightGear 3.6.0 RC Frame Rate and Graphics Experience

Postby Hooray » Fri Oct 30, 2015 7:33 pm

this has nothing to do with Gentoo, it will inevitably involve patching/rebuilding sg & fg.
The corresponding stats are currently not exposed at the property tree level, some of those don't even exist in C++ space yet - also, the number of people around here who understand, what needs to be exposed, and how is fairly low - and the number of those able to properly interpret such stats is even lower.

If you are interested in this kind of stuff, it would be a good idea to check out the devel list.

Or these wiki articles:
http://wiki.flightgear.org/Towards_bett ... leshooting
http://wiki.flightgear.org/Resource_Tra ... FlightGear
Image

In the meantime, you may want to file a feature request.
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: 11292
Joined: Tue Mar 25, 2008 8:40 am

Previous

Return to Release candidates

Who is online

Users browsing this forum: No registered users and 0 guests