Re: [Flightgear-devel] Sea color
Thorsten Does the problem go away if you set local-weather/dynamics-loop-flag=1 from the property browser *after* Advanced Weather is started? Does the problem go away if you set local-weather/timing-loop-flag=1 from the property browser *after* Advanced Weather is started? Does the problem go away if you set local-weather/effect-loop-flag=1 from the property browser *after* Advanced Weather is started? Does the problem go away if you set local-weather/interpolation-loop-flag=1 from the property browser *after* Advanced Weather is started? Does the problem go away if you set local-weather/housekeeping-loop-flag=1 from the property browser *after* Advanced Weather is started? Does the problem go away if you set local-weather/tile-loop-flag=1 from the property browser *after* Advanced Weather is started? Tested extensively today, and the short answer is no. There is some improvement as the flags are successively set to 0, but Advanced Weather never becomes as smooth as Basic Weather (and that's not without staggers of its own). The longer answer is that the symptoms are readily seen in the System Performance Monitor. There are large differences between the worst and average frame rates, exceeding 50%. In contrast, the Basic Weather difference is approximately 10%, with some occasional excursions beyond this. Switching from Basic Weather to Advanced, I see that the submodule events changes dramatically. With Basic Weather, the numbers in this submodule are consistent with other submodules. With Advanced, events stands out from the rest: not only are the numbers much larger than any of the others but they fluctuate wildly from sample to sample. The total time spent in event during a sample are 3 times that spent in the next largest,flight which is the FDM. It is my understanding that submodule events is where much of the work for nasal is done: listeners, loop timers and the like. I have placed todays test results here: http://dl.dropbox.com/u/57645542/stagger-data.htm What can be done? I cannot speak authoritatively here - perhaps some expert can jump in. Personally I would try trading in some framerate for smoothness, and let all loops run at maximum frame rate. I think at least some of the problem is load variation as various loop cut in. Loops with diverse time intervals must coincide from time to time; perhaps we are seeing that. I did try starting loops at random intervals in AI Models at one time, but that seemed to make things worse. We know that for loops do not help, perhaps those loops can be advanced on index per frame. We know we have problems with Garbage Collection. I suppose the bottom line is that this just might beyond what Nasal was designed for, and we need to migrate to C++. HTH Vivian -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Sea color
Tested extensively today, and the short answer is no. There is some improvement as the flags are successively set to 0, but Advanced Weather never becomes as smooth as Basic Weather (and that's not without staggers of its own). (...) I suppose the bottom line is that this just might beyond what Nasal was designed for, and we need to migrate to C++. The problem with that consequence is: As you switched all loops off, the Nasal part of Advanced Weather ceased to run completely and all that's left is the same cloud-generating functionality which is responsible for Basic Weather (C++ and shader work). If killing all Nasal did not solve the problems, then they can't be caused by Nasal, and porting to C++ will not fix them. * Thorsten -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] The (never ending) story about Berlin-Brandenburg airport
I'm not sure wether that's funny or sad - at least it's extremely rare ;-) http://foxtrot.mgras.net/bitmap/FGFS/EDDB-NT.png Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Sea color
On 11.05.2012 10:21, Renk Thorsten wrote: The problem with that consequence is: As you switched all loops off, the Nasal part of Advanced Weather ceased to run completely and all that's left is the same cloud-generating functionality which is responsible for Basic Weather (C++ and shader work). If killing all Nasal did not solve the problems, then they can't be caused by Nasal, and porting to C++ will not fix them. Not quite true. A significant part of Nasal-related frame rate impact is caused by garbage collection. Its delay/jitter only depends on the number of Nasal objects and their references which need to be searched. Increasing the number of Nasal objects (code+data) existing in memory also increases the delay. The amount of Nasal code which is actually being executed only influences the g/c frequency, i.e. whether the effect is visible every few seconds vs several times per second. This is why we are loading large Nasal modules, like advanced weather, on demand only (= only when feature enabled). We're not unloading objects when disabling a feature though - this usually requires restarting fgfs. This should be remembered when comparing such features (i.e. restart fgfs after disabling advanced weather etc). cheers, Thorsten -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [SPAM] Re: Sea color
On Fri, 11 May 2012, ThorstenB wrote: Not quite true. A significant part of Nasal-related frame rate impact is caused by garbage collection. Its delay/jitter only depends on the number of Nasal objects and their references which need to be searched. Increasing the number of Nasal objects (code+data) existing in memory also increases the delay. It might be interesting to try my old patch that adds a separate thread that tries to run the Nasal GC when the main loop is doing other things and see if that gives any improvement. (It runs the GC for every frame which is rather wasteful, but I have idle cores here anyway.) http://sleipner.gidenstam.org/users/anders/FlightGear/sg-gc-3.diff http://sleipner.gidenstam.org/users/anders/FlightGear/fg-gc-3.diff It doesn't solve the bigger problem of the current Nasal GC needing to run uninterrupted and in mutual exclusion - but I see very few GC runs in the main loop here (the patch prints ** Nasal GC in main thread ** in the console when that happens) except during startup. IIRC it does not report when a main loop Nasal context has to wait for the GC thread to finish a GC pass but I could look into adding that when I have time - it would be interesting to know. As far as I know the code has not been tested on Windows. Cheers, Anders -- --- Anders Gidenstam WWW: http://gitorious.org/anders-hangar http://www.gidenstam.org/FlightGear/ -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [SPAM] Re: Sea color
On 11 May 2012, at 19:59, Anders Gidenstam wrote: It doesn't solve the bigger problem of the current Nasal GC needing to run uninterrupted and in mutual exclusion - but I see very few GC runs in the main loop here (the patch prints ** Nasal GC in main thread ** in the console when that happens) except during startup. IIRC it does not report when a main loop Nasal context has to wait for the GC thread to finish a GC pass but I could look into adding that when I have time - it would be interesting to know. As far as I know the code has not been tested on Windows. I'd be happy to add this, especially made conditional at runtime (which looks possible) One comment is, it would be nice to use the SimGear locking / thread primitives, but that's a pretty trivial change. I did look at incremental GC for Nasal last year, but couldn't find a 'simple enough' generational algorithm. Still happy for someone else to try - the Nasal GC interface is very clean and self-contained, so quite easy to experiment with different GC schemes. James -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Sea color
ThorstenB On 11.05.2012 10:21, Renk Thorsten wrote: The problem with that consequence is: As you switched all loops off, the Nasal part of Advanced Weather ceased to run completely and all that's left is the same cloud-generating functionality which is responsible for Basic Weather (C++ and shader work). If killing all Nasal did not solve the problems, then they can't be caused by Nasal, and porting to C++ will not fix them. Not quite true. A significant part of Nasal-related frame rate impact is caused by garbage collection. Its delay/jitter only depends on the number of Nasal objects and their references which need to be searched. Increasing the number of Nasal objects (code+data) existing in memory also increases the delay. The amount of Nasal code which is actually being executed only influences the g/c frequency, i.e. whether the effect is visible every few seconds vs several times per second. This is why we are loading large Nasal modules, like advanced weather, on demand only (= only when feature enabled). We're not unloading objects when disabling a feature though - this usually requires restarting fgfs. This should be remembered when comparing such features (i.e. restart fgfs after disabling advanced weather etc). Thanks for that explanation. In the light of this I did some more testing. Switching from Basic to Advanced Weather increases the time spent in the events submodule from a stable 44 ms to over 1000 ms unstable. Setting all flags to 0 reduces this to 90 ms. Switching back to Basic, the time drops to 75. Adding more nasal loops into the equation by lowering the flaps and gear on the Seahawk, I think I can see the effect as a slight increase in the time spent in the events submodule. I'm not clear how deleterious having one submodule taking significantly more time than any other might be. If that is a problem, then large nasal script are not a good idea even if we only enable them on demand. The instability is clearly not a good thing, but is this a GC problem? If it is, then again, large nasal scripts are not good. Perhaps James can fix the GC issue, and this issue will disappear. I hope so. Vivian -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] model-combined-shader
Hi guys, Is it just me or has the model-combined shader stopped reflecting ? Moving the model slider seems to have no effect now . Syd -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
