View source for User:Hooray/SandBox/FlightGear Performance and Run-Time Footprint Debate

{{WIP}}

== Background == 
{{FGCquote
  |Thorsten and I, well, we're both sitting in front of hardware worth $2k-3k US (~18 months ago), with ~10+ gb of RAM, 2 gb of VRAM, 8 cores etc and I'll be the first to admit that this may very well kinda "mask" such issues, and that end-users may run into issues that we may not perceive as critical, or that we may never even notice at all.<br/>
<br/>
It is true that probably 99% of our end-users will not find the proper technical terms, and that they usually find the wrong cause and suggest the wrong solution to a particular problem, but that's why  we have contributors here who can process, filter and analyze such discussions, to get to the meat of the problem.<br/>
<br/>
This is not some random/uninformed bug report like "ALS is too reddish" or "Rembrandt is too slow" - it is about a key issue that may affect many people, and that even regardless of its manifestation, would -if address- benefit the community as a whole, i.e. better bug reports, more focused optimizations etc<br/>
<br/>
Right from the beginning, I suggested that we shouldn't restrict our focus to a single cause (like v2.0 scenery in this case) but look at the bigger picture, i.e. what needs to be done to identify certain issues earlier (regardless of their manifestation), but also to enable non-contributors to make better, and more informed, bug reports.
  |{{cite web |url={{forum url|p=214201}}
     |title=<nowiki>Re: How can I retire from the forum?</nowiki>
     |author=<nowiki>Hooray</nowiki>
     |date=<nowiki>Sun Jul 06</nowiki>
   }}
}}

{{FGCquote
  |Yes, there are issues. FG isn't perfect, it's rough around the edges, the GUI is far from optimized,... <br/>
<br/>
But we won't ever resolve them by saying 'The project is going into a bad direction.' The only way to solve them is constructively - establish the facts of what is actually going wrong. Trying to understand whether things can be fixed in the current framework, whether existing settings need to be exposed better, whether we lack information, or whether new development is needed. If it's the latter, make a good case for that new development and convince the people who matter. Document in the wiki what you found out can be done. Blanket-bashing the project won't help. Complaining that X is broken without providing the info necessary to fix it won't help. Making claims that feature X is causing a problem without having any evidence won't help. Ascribing opinions to developers which never have been said won't help. 
  |{{cite web |url={{forum url|p=214060}}
     |title=<nowiki>Re: How can I retire from the forum?</nowiki>
     |author=<nowiki>Thorsten</nowiki>
     |date=<nowiki>Fri Jul 04</nowiki>
   }}
}}

{{FGCquote
  |The lesson I take from all this (and related discussions) that I will be in the future very careful to make any rendering code available on GIT which isn't guaranteed fool-proof and might lead to less than perfect visual sometimes. If the general mood is that we bash the project for a release early, release often policy, then I will stop with it. 
  |{{cite web |url={{forum url|p=214060}}
     |title=<nowiki>Re: How can I retire from the forum?</nowiki>
     |author=<nowiki>Thorsten</nowiki>
     |date=<nowiki>Fri Jul 04</nowiki>
   }}
}}

{{FGCquote
  |(Originally, there actually was a conceptual separation i.e. WRT to master/next branches, but this hasn't  been used in years, despite having been established by Tim Moore as such.<br/>
But these days, we're simply lacking the  manpower to do so.)<br/>

  |{{cite web |url={{forum url|p=214064}}
     |title=<nowiki>Re: How can I retire from the forum?</nowiki>
     |author=<nowiki>Hooray</nowiki>
     |date=<nowiki>Fri Jul 04</nowiki>
   }}
}}

{{FGCquote
  |Poor performance doesn't necessarily have to do much with graphics - what you are describing are fluctuations in frame rate and frame spacing (latency, the time required to create a single frame). And here, it's frequently a bunch of other subsystems that are the culprit, or that at least contribute to the whole issue in a combined fashion. While it is true that many things can be disabled or customized, this doesn't apply to all features - and there  are many non-optional features/subsystems that cannot be easily customized or disabled yet, but it's something that will happen over time. However, while it's "graphics" that many people tend to consider the cause, it's more likely to be a sympton, because that's what people perceive to be slow, and the problem. Utlimately, frame rate and frame  spacing are really just symptoms though - there are many other subsystems that contribute to performance issues.<br/>
<br/>
And it isn't helping that we don't provide any good tools to tell how certain features, subsystems and settings perform in terms of CPU/RAM and GPU/VRAM utilization.<br/>
<br/>
I'd agree that we do have a real problem, but I'd say it's not necessarily in the graphics department - but ultimately, we really need to add better diagnostics, i.e. some kind of '''task monitor''' that tells us where time/horse power and RAM are spent.
  |{{cite web |url={{forum url|p=213965}}
     |title=<nowiki>Re: How can I retire from the forum?</nowiki>
     |author=<nowiki>Hooray</nowiki>
     |date=<nowiki>Thu Jul 03</nowiki>
   }}
}}

== Symptoms ==
{{FGCquote
  |Why do I have frame-rates of 8 - 60 sometimes, depending (mostly) on local weather and all settings to maxx. And here comes the part I mean to talk about: Why does my GPU jumps to 70°C in a minute or so, while my 2CPUs run gently with 50% usage each. (threading : auto)<br/>
<br/>
I understand, much of the computations are purely for optical reasons, and that's what a GPU is there for. But why not take some of it, and put it to idle CPU's? I'm running on a dual-core machine, knowing of this, I'd expect on the same hardware, but with a 8core CPU the same results; just because I have 8 CPU's running on 12% instead of 2 running on 50% doesn't seem to take any load off the GPU. Theoretically - and as I understand things.
  |{{cite web |url={{forum url|p=181564}}
     |title=<nowiki>Can FG computations be made more balanced?</nowiki>
     |author=<nowiki>chris_blues</nowiki>
     |date=<nowiki>Thu Apr 18</nowiki>
   }}
}}

{{FGCquote
  |The problem isn't completely on my hardware, but mostly on the consumption of most features in FG. <br/>
One day the game runs fine, then a 777-S is added and there goes my 4 GiB of RAM. It's a very nice aircraft but it consumes too much ram, not even the 777 PMDG consumes that amount.<br/>
But mostly I didn't bother too much with this, so I compiled again from git and then my fps goes to 3 even while flying the 737. I would assume it's something related to the scenery, but I don't know much about anything. It stays at 3 for dozens of seconds then goes to 40-50, but then after a few seconds it drops again to 3-5 and stays there.
  |{{cite web |url={{forum url|p=213961}}
     |title=<nowiki>Re: How can I retire from the forum?</nowiki>
     |author=<nowiki>junior-s</nowiki>
     |date=<nowiki>Thu Jul 03</nowiki>
   }}
}}

{{FGCquote
  |I'd love to have the money to buy a new pc and use it for many things and Flightgear, but I don't. I also don't think most people flying a free Simulator have the required computer power to run the game as it's requesting since about 2 years ago, but since I have a choice of either spending lots of money to buy a new PC just for Flightgear (because all of my other 54 games run fine at High settings) or buy a payware simulator, I chose to buy a simulator that runs fine with my current hardware.
  |{{cite web |url={{forum url|p=213961}}
     |title=<nowiki>Re: How can I retire from the forum?</nowiki>
     |author=<nowiki>junior-s</nowiki>
     |date=<nowiki>Thu Jul 03</nowiki>
   }}
}}

{{FGCquote
  |I don't need to max everything in order not to be able to play it. The default settings by themselves are enough to make the game unplayable, at least on Linux. FG's memory consumption is high and the scenery is too detailed. Either that, or it's a combo of mistakes that make the game not work for everybody. For instance, I saw a picture in this forum showing  a part of the scenery: it was formed of what, little squares of 40x40cm? Even smaller? That might be OK in short distances but the screenshot (for what I can remember) showed the scenery as quite far. No one gives that much attention to ground level details, no one will zoom out till they can see ants on the ground.
  |{{cite web |url={{forum url|p=213977}}
     |title=<nowiki>Re: How can I retire from the forum?</nowiki>
     |author=<nowiki>junior-s</nowiki>
     |date=<nowiki>Thu Jul 03</nowiki>
   }}
}}

{{FGCquote
  |In fact I tested X-Plane and it works so well I couldn't believe, because the developers say "use 16GB of RAM and multiple processors". That's not quite the case, as I spoke to one of it's developers he/she said the game auto-adjusts itself to the hardware it's been run on. But even so, I didn't notice any difference from the ad videos they put up on Youtube.
  |{{cite web |url={{forum url|p=213978}}
     |title=<nowiki>Re: How can I retire from the forum?</nowiki>
     |author=<nowiki>junior-s</nowiki>
     |date=<nowiki>Thu Jul 03</nowiki>
   }}
}}

== v2.0 Scenery ==
{{FGCquote
  |The numbers say that without any doubt, 2.0 scenery is what uses all the memory, nothing else - not hires textures, not trees. 
  |{{cite web |url={{forum url|p=214100}}
     |title=<nowiki>Re: How can I retire from the forum?</nowiki>
     |author=<nowiki>Thorsten</nowiki>
     |date=<nowiki>Sat Jul 05</nowiki>
   }}
}}

{{FGCquote
  |Do not use the 2.0 scenery (because it is an early, imperfect  work in progress release) and watch the issues disappear. I confirmed with my 'Yeah, pretty much' that I recommend putting up a warning that you need lots of memory to use the 2.0 scenery and that I would recommend stay with 1.0 if you don't have that.
  |{{cite web |url={{forum url|p=214050}}
     |title=<nowiki>Re: How can I retire from the forum?</nowiki>
     |author=<nowiki>Thorsten</nowiki>
     |date=<nowiki>Fri Jul 04</nowiki>
   }}
}}

{{FGCquote
  |I don't think it's fair to blame any particular subsystem for these issues. The fact is, the project has to keep evolving and transforming in order to remain relevant, and this means things can sometimes break in the process, regressions rear ugly heads, some users become unhappy, but overall the project is moving forward and commits are regularly made by core contributions, which I think at some point becomes essential to maintain confidence in the future of the project, as we can see in many other open-source code bases, rather than stagnate and become increasingly irrelevant in today's fast moving market, as it's never a good idea to throw away perfectly good opportunities for progress, even though it could inspire distrust and even drive away some potential users, as long as the core contributors are kept reasonably satisfied and are not compelled to move away from the project.
  |{{cite web |url={{forum url|p=214281}}
     |title=<nowiki>Re: How can I retire from the forum?</nowiki>
     |author=<nowiki>adrian</nowiki>
     |date=<nowiki>Mon Jul 07</nowiki>
   }}
}}

{{FGCquote
  |The scenery doesn't have a LOD system yet, yes. I gather the philosophy was we need a viable scenery first before we can simplify it down to implement a LOD system - so we have the first step done, and the second is in progress. What you're upset about is that the second step isn't done yet and the scenery team was stupid enough to listen to people like me and gave us what they had so far. But people needed to start with the first. <br/>

  |{{cite web |url={{forum url|p=214074}}
     |title=<nowiki>Re: How can I retire from the forum?</nowiki>
     |author=<nowiki>Thorsten</nowiki>
     |date=<nowiki>Fri Jul 04</nowiki>
   }}
}}

{{FGCquote
  |There's nothing wrong with FG as far as I know - it will probably run fine on your computer and deliver quite decent visuals if you customize it. There's a lot wrong with the way the information how to customize it to your needs is documented and transmitted. And this is where the republic of heaven thing could come in - rather than complain and write support PNs for the kingdom to come, you (all) could help to assemble, improve and spread this information.
  |{{cite web |url={{forum url|p=214074}}
     |title=<nowiki>Re: How can I retire from the forum?</nowiki>
     |author=<nowiki>Thorsten</nowiki>
     |date=<nowiki>Fri Jul 04</nowiki>
   }}
}}

{{FGCquote
  |I had banned myself from KSFO because I would get to swap even before seeing anything and now I tried and fgfs starts and is usable in my 32 bit debian system with <span style{{=}}"font-size: 150%; line-height: normal">2GB of RAM</span>. Simple planes and no multiplayer though, but is really great improvement.
  |{{cite web |url={{forum url|p=214113}}
     |title=<nowiki>Re: How can I retire from the forum?</nowiki>
     |author=<nowiki>sa7k</nowiki>
     |date=<nowiki>Sat Jul 05</nowiki>
   }}
}}

{{FGCquote
  |You do not need to buy a new computer or more memory to have very pleasant visuals of FG if you have a halfway decent GPU. I have plenty of forum screenshots in the old scenery to demonstrate that.<br/>
<br/>
But to run the 2.0 scenery in its current state (which is, as I repeatedly said, an early work in progress release which the scenery team was reluctant to do) you do, and my recommendation is to stay clear of it till the issues (zero area triangles, LOD,...) are resolved.
  |{{cite web |url={{forum url|p=214050}}
     |title=<nowiki>Re: How can I retire from the forum?</nowiki>
     |author=<nowiki>Thorsten</nowiki>
     |date=<nowiki>Fri Jul 04</nowiki>
   }}
}}

{{FGCquote
  | The scenery people know that. It needs way too much memory, especially the line features (roads, rivers,...) eat it like mad. A third to half is zero area triangles which could be culled. There's no LOD system yet. People are working on it.<br/>
<br/>
The 2.0 is an early release of a work in progress because we specifically asked for it to be released, no matter the state. It is nevertheless stunning and a big improvement over the 1.0 in level of detail - I really enjoy flying Grand Canyon these days. Once you see it as work in progress which you can use optionally if it runs for you, it has lots of merit.<br/>
<br/>
But it matters what is actually wrong with the 2.0 scenery - you still can't say that it's made of 40x40 cm squares, because that is not its problem. You can't say that X is wrong with it when it's in fact Y just because something is wrong.
  |{{cite web |url={{forum url|p=214050}}
     |title=<nowiki>Re: How can I retire from the forum?</nowiki>
     |author=<nowiki>Thorsten</nowiki>
     |date=<nowiki>Fri Jul 04</nowiki>
   }}
}}

{{FGCquote
  |You can use 1.0 scenery and lots of visibility (4 GB will buy you 200 km if you de-activate trees and buildings). You can use hires scenery and lower visibility (4 GB will perhaps buy you 40-50 km). And anything else. Obviously, if you're flying an airliner, your choice might be different than if you're flying a single prop.<br/>
<br/>
It'd be nice to have that choice made semi-automatically (I'd still like to customize it), but the question remains - FG allows you to focus on what is important for you. Whether you see an issue or not depends on what choice you're trying to make and how it is supported by hardware.
  |{{cite web |url={{forum url|p=214050}}
     |title=<nowiki>Re: How can I retire from the forum?</nowiki>
     |author=<nowiki>Thorsten</nowiki>
     |date=<nowiki>Fri Jul 04</nowiki>
   }}
}}

{{FGCquote
  |revert to the 1.0 scenery. On a by now 6 year old 32bit computer with 4 GB memory, I could run that with shader settings at what is now medium quality and visibility ranges of 120 km with 20+ fps.<br/>
<br/>
Using the 2.0 scenery (or in fact any scenery) is '''optional'''. And you should in fact ''not'' do it if you think you're low on memory. I think that recommendation is now all over the place in the forum, on the FG site and on the mailing list. We still provide the 1.0 lowres scenery for download and probably will continue to do so for a while. And if memory is the bottleneck (an extended period of low framerate jumping back to 50 sure looks like the system starting to use swap...) you can use high graphics settings and create lots of details procedurally.
  |{{cite web |url={{forum url|p=213972}}
     |title=<nowiki>Re: How can I retire from the forum?</nowiki>
     |author=<nowiki>Thorsten</nowiki>
     |date=<nowiki>Thu Jul 03</nowiki>
   }}
}}

{{FGCquote
  | the 2.0 scenery is heavy - FG 3.2 really isn't. You're confusing the framework with the data - FG is just the framework, its resource dependence crucially depends on what data you feed it with, i.e. what scenery you use or what aircraft. FG 2.0 would be just as memory-consuming with the new scenery and the most recent top-notch aircraft (if it would run that is, there was a format change for the scenery).<br/>
<br/>
The 'simulator that runs fine with your current hardware' has probably just the same feature - if you would feed it hires data for terrain and aircraft, it'd consume more resources than you have.
  |{{cite web |url={{forum url|p=213972}}
     |title=<nowiki>Re: How can I retire from the forum?</nowiki>
     |author=<nowiki>Thorsten</nowiki>
     |date=<nowiki>Thu Jul 03</nowiki>
   }}
}}

{{FGCquote
  |An obvious case is scenery 2.x. Yes it is heavy, yes it is released early (understandably as Thorsten argues), yes one can warn people to revert to 1.x temporarily. But do not leave it at that. Maybe there is being worked hard at smart solutions, but that is not really becoming obvious to people that read the forum. Understandably they get frustrated by that.
  |{{cite web |url={{forum url|p=214004}}
     |title=<nowiki>Re: How can I retire from the forum?</nowiki>
     |author=<nowiki>KL-666</nowiki>
     |date=<nowiki>Thu Jul 03</nowiki>
   }}
}}

{{FGCquote
  |For the scenery issue, and actually every issue, i think it is important for a developer to ask himself: "what would a user want/need". I fly high fl300-400, so i might need some 200+ mi visibility to see some earth. Hardware (memory) wise i can only set some 60 mi visibility, so at altitude i fly in plain fog. At low altitude one has a horizon of maybe 20 mi, so the heavy scenery is not a problem at whatever visibility setting. But at high altitude one gets more tiles. The current problem is that the tiles are as detailed as at low altitude, which is totally unnecessary. So the logical second step after the early release of scenery 2.x would be to load lower res tiles in memory at high altitude. I am quite sure that such solution is also used by x-plane, which explains the better experience there.<br/>
<br/>
Well maybe there is already being worked on this kind of optimization. 
  |{{cite web |url={{forum url|p=214004}}
     |title=<nowiki>Re: How can I retire from the forum?</nowiki>
     |author=<nowiki>KL-666</nowiki>
     |date=<nowiki>Thu Jul 03</nowiki>
   }}
}}

{{FGCquote
  |There's a story to that, and that is that for years we (certainly I and many others) have been asking the scenery team again and again to release something of the new world scenery, even if it's not perfect, so that we have something to work with. They've finally done so - and we got something that's not very perfect - with zero-area triangles, possibly too high details on roads, heavy on memory,...  so now that's a base to improve upon.<br/>
<br/>
But of course, now everyone finds that it's not perfect and complains that it's not perfect. And then, I feel compelled to speak up, because I specifically asked to release early even if there'd be problems. And in my book, that voids any right to complain. <br/>
<br/>
Because if I had been asked to release something early, knowing it's not 100% ready, and I had done so and would face the reaction I'd now get from the user base, I'd feel pretty pissed, and I'd pack my stuff and leave.<br/>
<br/>
The story of course continues, because in their infinite wisdom, the powers to be made the 2.0 scenery the default via terrasync and did in fact for some undisclosed reason not insert a statement into the release announcement that it's heavy on memory, and I've been spending tens of hours by now to make that bit of info more widely known. So the whole way the 3.0 release went with the 2.0 scenery and the information about potential problems was a royal clusterf*&amp;^% 
  |{{cite web |url={{forum url|p=213983}}
     |title=<nowiki>Re: How can I retire from the forum?</nowiki>
     |author=<nowiki>Thorsten</nowiki>
     |date=<nowiki>Thu Jul 03</nowiki>
   }}
}}

{{FGCquote
  |I'm getting seriously frustrated about the whole scenery thing. About the release management which discarded all the good evidence about memory issues. About users who can't find it in them to cut the scenery people some slack and acknowledge that the 2.0 scenery is a step towards something better - not the end product, but something to work with while something new is rolled out, and that using 1.0 apparently isn't an option. About the misinformation that is spread because people can't be bothered to verify information. About long term contributors who run around and claim that we have a huge problem in the code, when in fact all investigations have shown that most issues go away when reverting to 1.0 scenery. And about the general notion that nobody would care about the whole thing, when in fact plenty of people are working on the issues.
  |{{cite web |url={{forum url|p=213983}}
     |title=<nowiki>Re: How can I retire from the forum?</nowiki>
     |author=<nowiki>Thorsten</nowiki>
     |date=<nowiki>Thu Jul 03</nowiki>
   }}
}}

{{FGCquote
  |Making scenery is a completely different branch of coding from rendering scenery. Even if I would not add any more rendering options, I would have zero qualification working on scenery. You can't simply assume that you can reassign people to any task - a 3d modeler isn't going to be a coder if you ask him to, a graphics artist isn't going to become a rendering specialist. Within each area of specialization, people do fix bugs before adding options.
  |{{cite web |url={{forum url|p=213983}}
     |title=<nowiki>Re: How can I retire from the forum?</nowiki>
     |author=<nowiki>Thorsten</nowiki>
     |date=<nowiki>Thu Jul 03</nowiki>
   }}
}}

== Memory Footprint ==
{{FGCquote
  |Memory footprint has been a recurring theme on the mailing list and Rebecca has demonstrated it to be almost exclusively relate to the scenery. The scenery team is busy getting rid of extra zero area triangles for the next scenery release. James has pushed the changes to the tile cache for better memory footprint. People are working on a terrain LOD scheme. Prior to the 3.0 release, you can find my messages pushing for a clear statement that the 2.0 scenery as is is rather memory intense and that we recommend it should only be used on systems with plenty of memory and that we should keep the 1.0 scenery available. There are forum messages by yours truly all over the place explaining that the first measure in case of any trouble with FG 3.0 out of the box should be to revert to the old scenery.
  |{{cite web |url={{forum url|p=213983}}
     |title=<nowiki>Re: How can I retire from the forum?</nowiki>
     |author=<nowiki>Thorsten</nowiki>
     |date=<nowiki>Thu Jul 03</nowiki>
   }}
}}

== CPU vs. GPU work ==
{{FGCquote
  |If you have a halfway decent GPU, when you ask a rendering task (texture lookups, vector transformations, matrix multiplications,...) , the additional performance of 8 CPUs is pretty negligible. The GPU does these tasks in lightning speed.<br/>
<br/>
Just to give you a sense of scale, some colleagues of mine run relativistic fluid-dynamics computations (which needs vector transformations, matrix multiplications,...) and have started to move these computations from CPUs to GPU clusters - which according to their benchmarks makes it 100 times faster. GPUs are massive parallel machines with hard-wired support for what is needed for rendering. The most powerful supercomputing machines in the world use arrays of graphics cards.<br/>
<br/>
So it's unlikely that utilizing your idle CPUs for rendering would make more than a dent - especially if you imagine the data flow back and forth you create. Just try running FG with software rendering only and see how your 8 cores keep up with the performance of the  GPU :-) Or, if the above benchmark is true, you could run at 108% max. instead of 100% - not really that impressive, is it? 
  |{{cite web |url={{forum url|p=181606}}
     |title=<nowiki>Re: Can FG computations be made more balanced?</nowiki>
     |author=<nowiki>Thorsten</nowiki>
     |date=<nowiki>Fri Apr 19</nowiki>
   }}
}}

{{FGCquote
  |on a high-end GPU (which I assume you have), the single determining factor for the framerate seems to be the vertex count of clouds, buildings and trees (in this order). So rendering overcast sky makes a huge difference to rendering clear sky, rendering a city worth of random buildings makes a huge difference to rendering a desert, and rendering dense forests makes a difference to rendering a few patches of green. With all details to max, we probably burn 99% of the total computational load in rendering (it's about 1200 lines of instructions per pixel 30-60 times per second), all other flight related tasks like computing aerodynamics are small in comparison.
  |{{cite web |url={{forum url|p=181606}}
     |title=<nowiki>Re: Can FG computations be made more balanced?</nowiki>
     |author=<nowiki>Thorsten</nowiki>
     |date=<nowiki>Fri Apr 19</nowiki>
   }}
}}

{{FGCquote
  | the only thing that I can identify as affecting my framerate is the vertex pipeline. Currently, with the rest I can pretty much do what I like. The Concorde with it's gazillions of systems runs as fast as a glider. The high-fideltity (or at least quite complex FDM) T4T Spitfire runs as fast as any other plane. Switching background Nasal on and off makes no bloody difference for anything. Only what enters the vertex pipeline does. Or lots and lots of semi-transparent stacks in the fragment pipeline - they can eventually kill as well.<br/>
<br/>
So you can move the rest wherever you want - since it's not determining my framerate in its 'bad' structure now, it will not determine my framerate in an optimized structure either. That may not be the situation on the machine Mathias is on, and Mathias may not be interested in the same rendering setup as I am - but that's how it works on my machine right now
  |{{cite web |url={{forum url|p=181608}}
     |title=<nowiki>Re: Can FG computations be made more balanced?</nowiki>
     |author=<nowiki>Thorsten</nowiki>
     |date=<nowiki>Fri Apr 19</nowiki>
   }}
}}

{{FGCquote
  |The vast majority of the computing load is generated due to rendering, i.e. if you have GPU support (as with any modern graphics card) it doesn't touch the CPU at all. The framerate is usually determined exclusively by the GPU capability - distributing CPU load across several cores may be elegant conceptually, but doesn't make anything run faster.<br/>
<br/>
The graphics card on the other hand has parallel rendering pipelines in the first place. 
  |{{cite web |url={{forum url|p=153266}}
     |title=<nowiki>Re: [SUGGESTION] Multi-core FlightGear support</nowiki>
     |author=<nowiki>Thorsten</nowiki>
     |date=<nowiki>Thu Mar 15</nowiki>
   }}
}}

{{FGCquote
  |Thorsten's system is unfortunately not representative of the overall situation for all users - because not everybody has a $ 3k workstation-style laptop at home with 8 64 bit cores (hyperthreading included), 16gb of RAM and a NVIDIA 670M 2gb SLI configuration. We need to be careful not to compare apples and oranges here, I have no doubt that Nasal code or poorly coded C++ code doesn't really show up on such a system.<br/>
<br/>
Which doesn't really mean that anybody in particular would be wrong here, but originally the FG main loop was designed to be a single sequential loop that scaled roughly with the frequency of the CPU - which is why someone running FG on a "high-end" gaming computer today may very well have the impression that FG's architecture is not the problem, especially because of the number of background threads already added over time and now working behind the scenes, which ALREADY make use of additional cores to reduce the footprint of the main loop.
  |{{cite web |url={{forum url|p=181613}}
     |title=<nowiki>Re: Can FG computations be made more balanced?</nowiki>
     |author=<nowiki>Hooray</nowiki>
     |date=<nowiki>Fri Apr 19</nowiki>
   }}
}}

{{FGCquote
  |performance issues like these are not obvious on high-end machines, no matter if it's framerate, frame spacing or the Nasal garbage collector - on a 3-4 ghz multicore system, there's usually enough horsepower available to make up for architectural shortcomings - but that only hides the real problem. And it's a well-known issue that computers used by developers are usually high-end machines, which end up masking problems encountered by end users, who may very well use much less powerful hardware.<br/>
<br/>
If we all had access to 10ghz machines, we would all be having the impression that FG's architecture is rock-solid and that GPUs are the main problem  :lol: <br/>
<br/>
There's a reason why software companies tend to keep lots of hardware around, to do tests and benchmarks on old/common hardware.
  |{{cite web |url={{forum url|p=181613}}
     |title=<nowiki>Re: Can FG computations be made more balanced?</nowiki>
     |author=<nowiki>Hooray</nowiki>
     |date=<nowiki>Fri Apr 19</nowiki>
   }}
}}

== Our Main Loop & HLA ==
{{FGCquote
  | have heard on these forums from various people that FG does not utilise all the resources available to it very effectively.<br/>
<br/>
Now before I start, I am well aware that FG can run quite fast on a decent computer but there are still little annoyances even when there are still plenty of resources for FG to use.<br/>
<br/>
FG developers have made very GREAT advancements (and I thank them for enhancing FG) in terms of graphics rendering, plane realism, etc but there has been a lack in multi-core support. <br/>
<br/>
I am certainly no developer myself but I understand that it would take a mammoth effort to modify FG's core to better support multi-cores and other resources effectively.<br/>

  |{{cite web |url={{forum url|p=153262}}
     |title=<nowiki>[SUGGESTION] Multi-core FlightGear support</nowiki>
     |author=<nowiki>Vinura</nowiki>
     |date=<nowiki>Thu Mar 15</nowiki>
   }}
}}

{{FGCquote
  |Basically, your GPU is a massively parallel special-purpose cluster of "CPUs" (depending on the hardware, hundreds of tiny cores) that can do certain mathematical computations extremely well/fast by partioning the task at hand and handing each job to another work queue, which may be processed by hundreds of "dedicated cores sitting on the GPU" in parallel. Basically, your GPU is super computer (certainly when compared to the computing power of the 80s or 90s).<br/>
<br/>
On the other hand, not all things can be easily run on a GPU (GPGPU aside for now) - and many parts of FG are simply not rendering-related, and cannot easily be moved to the GPU. <br/>
<br/>
So your CPUs and idle cores are still relevant to handle all non-rendering related jobs, and other computations that are not appropriate for the GPU (ATM). Things like AI traffic, the FDM, autopilot computations, Nasal code - these all run in the main loop, before the final frame is created and rendered. So depending on how long each step takes, frame rate/spacing may fluctuate - which is less likely to show up on really fast systems like Thorsten reported.
  |{{cite web |url={{forum url|p=181613}}
     |title=<nowiki>Re: Can FG computations be made more balanced?</nowiki>
     |author=<nowiki>Hooray</nowiki>
     |date=<nowiki>Fri Apr 19</nowiki>
   }}
}}

{{FGCquote
  |the idea is not to use idle CPU cores for rendering related stuff - but rather optimize the FG&lt;-&gt;OSG pipeline such that more main loop resources become available, so that certain tasks can be offloaded onto other cores. For example, OSG is able to run certain rendering-related optimizations asynchronously, outside the main loop. But that requires a paradigm change, because of the way FG makes currently use of OSG in a fairly sub-optimal fashion, even though Thorsten is right in saying that this particular issue doesn't show up on extremely fast systems with high-speed CPUs. 
  |{{cite web |url={{forum url|p=181613}}
     |title=<nowiki>Re: Can FG computations be made more balanced?</nowiki>
     |author=<nowiki>Hooray</nowiki>
     |date=<nowiki>Fri Apr 19</nowiki>
   }}
}}
{{FGCquote
  |The point of the whole FGViewer/HLA effort is having a pure renderer and moving everything not rendering related to separate entities, that may run in separate threads or processes, without affecting the visualization of the simulation. That is a key technique used in professional full motion simulators, and in the simulation industry in general. Even without fully understanding the benefits, you will certainly come to appreciate the fact that you will be able to run many computations that don't directly affect frame rate or frame spacing/latency anymore.<br/>
<br/>
At the moment, we simply have unused optimization potential because of the way FG uses OSG/OpenGL, i.e. not following the proper coding patterns.
  |{{cite web |url={{forum url|p=181607}}
     |title=<nowiki>Re: Can FG computations be made more balanced?</nowiki>
     |author=<nowiki>Hooray</nowiki>
     |date=<nowiki>Fri Apr 19</nowiki>
   }}
}}

{{FGCquote
  |I think HLA is a great idea for many reasons, because it addresses many unnecessary sources of bottlenecks. But I don't think it addresses all bottlenecks, in particular I don't think it addresses mine. Mathias has made it abundantly clear that he's not interested in high-end shader effects, but that he cares for multiple display setups and similar things. It's also become quite apparent to me that he doesn't really follow how our high-end effects actually are implemented and what they do. So my impression is that HLA will be a good thing for many purposes - when you're CPU limited for any reason, for MP, for multi-display setups,..., but I don't see how it will address situations where the bottleneck is shader code.
  |{{cite web |url={{forum url|p=181608}}
     |title=<nowiki>Re: Can FG computations be made more balanced?</nowiki>
     |author=<nowiki>Thorsten</nowiki>
     |date=<nowiki>Fri Apr 19</nowiki>
   }}
}}

== About Testing ==
=== Lack of Feedback from End Users ===
{{FGCquote
  |From where I stand, we're mainly lacking willingness of users to actually run tests under guidance. If people can't be bothered to report their system specs or what they're actually doing in detail, then I can't see how they'd report more internal diagnostics.
  |{{cite web |url={{forum url|p=214050}}
     |title=<nowiki>Re: How can I retire from the forum?</nowiki>
     |author=<nowiki>Thorsten</nowiki>
     |date=<nowiki>Fri Jul 04</nowiki>
   }}
}}

{{FGCquote
  |many people don't even  know how to get/deploy and use a nightly snapshot, let alone actually provide useful/actionable data, "useful" in the sense that developers can actually act upon that data
  |{{cite web |url={{forum url|p=214064}}
     |title=<nowiki>Re: How can I retire from the forum?</nowiki>
     |author=<nowiki>Hooray</nowiki>
     |date=<nowiki>Fri Jul 04</nowiki>
   }}
}}

{{FGCquote
  |The mechanism as such is clear and sound: We have the Jenkins nightly GIT binaries on distribution, we distribute release candidates, these should lead to test data on a wide set of systems, which them comes back and enables people to take action.<br/>
<br/>
One problem is that GIT these days isn't treated as the experimental stuff it is where things can break overnight and where people diagnose issues and report back (if that is done, for instance in the case of the JSBSim zero altitude bug crossing into the ocean, things get fixed quickly). But rather, GIT gets treated as release-quality code, people complain that potentially unstable code gets committed to the repo (where else is it supposed to be tested?).<br/>
<br/>
So, rather than getting meaningful and actionable feedback from GIT users, we're seeing more and more non-actionable complaints that the version which is intended for testing and experiments isn't fully tested.
  |{{cite web |url={{forum url|p=214050}}
     |title=<nowiki>Re: How can I retire from the forum?</nowiki>
     |author=<nowiki>Thorsten</nowiki>
     |date=<nowiki>Fri Jul 04</nowiki>
   }}
}}

{{FGCquote
  |I don't know - personally, I believe we simply couldn't deal with the results: Just look at some of the recent developments in this area,  such as the integrated "Crash Reporting" system: We've been seeing dozens of users making extensive use of this - and then it became obvious that the SINGLE recipient of all these bug reports simply couldn't deal with the sheer number of reports, because we never established any mechanism to process all the feedback at a larger scale. Or look at the issue tracker and the number of "critical" bugs there - which I think kinda proves the point that we, as a project, cannot deal with too much feedback. Even though that may not necessarily apply to other contributors, like yourself. But the few people who do not just have 2-3 "pet projects", but who maintain the whole simulator, cannot deal with the sheer amoung of feedback.<br/>
Thus, I think that built-in diagnostics and automated regression testing would help us more in the long term, i.e. kinda like the whole "benchmark" debate we've been seeing for years. The final result could then be a "flight recorder tape" that includes important run-time info, i.e. stats but also log files.
  |{{cite web |url={{forum url|p=214064}}
     |title=<nowiki>Re: How can I retire from the forum?</nowiki>
     |author=<nowiki>Hooray</nowiki>
     |date=<nowiki>Fri Jul 04</nowiki>
   }}
}}

{{FGCquote
  |Case in point - it'd be interesting to find out ''why'' FG in junior-s system can drop from 50 fps down to 5. I've never ever seen this, I don't know anyone who has, it'd be important to find out what's the issue and see whether we can address it - but rather than a structured bug report, or anything I could try to help to diagnose, what I see of this is 'FG is becoming unusable, how do I retire from the forum'.<br/>
<br/>
With a user-side attitude like 'If it's broken, let someone else figure it out, not my job' we can't do it. We don't have an array of different computers at home so that we could do specific testing - I have my laptop to test, and that's it. We rely on users entering an issue tracking process, making systematic tests under guidance, reply to questions.<br/>
<br/>
Whenever this happens, the chance is perhaps 80% that there is a fix at the end. Whenever this doesn't happen, the chance is perhaps 5% that by random chance things will improve. <br/>
<br/>
It is simply ''not'' true that such things go unnoticed. I made a report about 2.0 scenery resource consumption to the devel list prior to the 3.0 release. There have been many discussions on memory consumption.
  |{{cite web |url={{forum url|p=214050}}
     |title=<nowiki>Re: How can I retire from the forum?</nowiki>
     |author=<nowiki>Thorsten</nowiki>
     |date=<nowiki>Fri Jul 04</nowiki>
   }}
}}

=== Poor Quality of Bug Reports ===
{{FGCquote
  |I'm not a developer so, please, don't expect me to give the detail you want. I'm an end user, that's all. What I know is that there ***IS*** something wrong with FG because it's getting slow over time. What I do know is that a plane with a level of detail of the 777-S should NOT eat that much ram. What I do know is that there are other simulator which renders a lot more scenery than FG and yet they don't eat too much RAM. What I do know is that sims like FSX will make the scenery as low detail as possible when you get far from it. Hell, if you're 500m from a mountain it'll start to get such low polygon count it'll actually look like a 90's game. Does it matter? No, because probably most people don't pay much attention to what's far.
  |{{cite web |url={{forum url|p=214062}}
     |title=<nowiki>Re: How can I retire from the forum?</nowiki>
     |author=<nowiki>junior-s</nowiki>
     |date=<nowiki>Fri Jul 04</nowiki>
   }}
}}

== Proposals ==
{{FGCquote
  |In cases of flightgear being heavy on resources, i have often seen comments like: "lower the settings". Often and surely temporarily that can be a valid solution. But in some cases i think: do not leave it at that statement, because surely a smart solution can be found.
  |{{cite web |url={{forum url|p=214004}}
     |title=<nowiki>Re: How can I retire from the forum?</nowiki>
     |author=<nowiki>KL-666</nowiki>
     |date=<nowiki>Thu Jul 03</nowiki>
   }}
}}

=== FlightGear light ? ===
{{FGCquote
  |Moreover, I've always been in favour of trying to clearly propose the user a low-end and a high-end version of FG, evolving with the ongoing versions. And I mean clearly, not by having to spend time understanding sliders
  |{{cite web |url={{forum url|p=214283}}
     |title=<nowiki>Re: How can I retire from the forum?</nowiki>
     |author=<nowiki>f-ojac</nowiki>
     |date=<nowiki>Mon Jul 07</nowiki>
   }}
}}

{{FGCquote
  |we simply don't have the manpower to really "produce" too many different versions - people have also been suggesting to come up with versions featuring less complex scenery/aircraft, or possibly an aircraft/scenery-specific "mod", e.g. "HeliGear" or "CombatGear". The thing is, these ideas are good in theory, but they are tying up a lot of manpower.<br/>
<br/>
However, what could work is making more and more FlightGear default settings and subsystems entirely optional, so that FlightGear becomes increasingly run-time configurable - which would allow the same fgfs binary to be used for hugely different purposes. Zakalawe has been working on this as part of better run-time re-initialization, where fgcommands/Nasal APIs can be used to dynamically disable and enable whole subsystems, which are then "booted" (or shut-down) on demand. This works already for roughly a dozen of subsystems, but the real resource hogs are not yet optional.
  |{{cite web |url={{forum url|p=214286}}
     |title=<nowiki>Re: How can I retire from the forum?</nowiki>
     |author=<nowiki>Hooray</nowiki>
     |date=<nowiki>Mon Jul 07</nowiki>
   }}
}}
{{FGCquote
  |I don't quite see how we could come up with different versions, binaries and packages of FG easily - but we could certainly prepare the main binary to become increasingly configurable, so that it can be used for such purposes - it would even be possible to use built-in FG dialogs in an external window, running in a standalone process - e.g. for an instructor console, but also for a Canvas-driven TerraGear GUI.
  |{{cite web |url={{forum url|p=214286}}
     |title=<nowiki>Re: How can I retire from the forum?</nowiki>
     |author=<nowiki>Hooray</nowiki>
     |date=<nowiki>Mon Jul 07</nowiki>
   }}
}}

{{FGCquote
  |I looked at the "FGCanvas" branch I started last year to see how many subsystems can be easily made optional these days. Primarily with a focus on aircraft &amp; scenery subsystems - the idea is to put those into dedicated subsystem groups, so that resource utilization can be OPTIONALLY tracked per group. This would make it possible to overload operator new at the SGSubsystem/Group-level to track most allocations and provide /some/ stats.<br/>
<br/>
And the results are pretty encouraging actually: {{forum link|p=214262|text=Subject: FGCanvas Experiments &amp; Updates}}
  |{{cite web |url={{forum url|p=214286}}
     |title=<nowiki>Re: How can I retire from the forum?</nowiki>
     |author=<nowiki>Hooray</nowiki>
     |date=<nowiki>Mon Jul 07</nowiki>
   }}
}}
=== Resource Utilization Tracking === 
{{FGCquote
  | I don't think it's fair to all "blame" it all on more TerraGear progress - the underlying issue is a known one, and we've seen recurring patterns here long before World Scenery 2.0, it's just the concrete manifestation that differs over time, but otherwise the culprit is that we 1) don't provide any optional diagnostics to tell what's going on in terms of CPU/GPU/RAM/VRAM utilization, and 2) that we don't do any headless regression testing when adding new features. So I can kinda relate to people feeling "locked out". We're certainly far from being user-friendly, if people have to be around for half a decade to turn FG into a usable piece of software
  |{{cite web |url={{forum url|p=213986}}
     |title=<nowiki>Re: How can I retire from the forum?</nowiki>
     |author=<nowiki>Hooray</nowiki>
     |date=<nowiki>Thu Jul 03</nowiki>
   }}
}}

{{FGCquote
  | I also find it more "exciting" to do some fancy Canvas display than fixing the Nasal/GC - and that seems to apply to roughly half a dozen of people around here who obviously have the mental capacity and expertise to address such issues,  no matter if it's an alternate Nasal/GC scheme, or an improved threading architecture - still, we're all motivated by things having to be fun, and there's really only a single guy who seems to "enjoy" doing the unglamorous work of fixing other people's ugly code all over the place, and that guy is kinda busy with allowing aircraft to be switched at run-time 
  |{{cite web |url={{forum url|p=213986}}
     |title=<nowiki>Re: How can I retire from the forum?</nowiki>
     |author=<nowiki>Hooray</nowiki>
     |date=<nowiki>Thu Jul 03</nowiki>
   }}
}}

{{FGCquote
  |that's basically a matter of providing some kind of dedicated monitoring function, analogous to the existing system monitor, which also tracks other resources, such as RAM/VRAM - at least optionally.
  |{{cite web |url={{forum url|p=213986}}
     |title=<nowiki>Re: How can I retire from the forum?</nowiki>
     |author=<nowiki>Hooray</nowiki>
     |date=<nowiki>Thu Jul 03</nowiki>
   }}
}}

{{FGCquote
  | don't agree at all that the question whether we need '''integrated''' monitoring mechanisms is a matter of "strategy" as long as we're expecting non-developers to make GOOD bug reports.<br/>
Obviously someone familiar with Nasal, GLSL and C++ doesn't need such tools, but these people can usually also provide good bug reports without any hand-holding. But the instant we expect our end-users to make useful bug reports, we need to integrate and provide optional diagnostics - analogous to the system/performance monitor or the OSG on-screen stats, otherwise we'll keep on having these discussions for another 5+ years probably. <br/>
To be honest, I find your whole point about "not needing a debugger/profiler" kinda moot actually - you are without doubt referring to your own work here, which you're highly familiar with. Then again, I am sure that our degree of improving performance issues in FG would be much better if we had access to such tools, because it would no longer necessarily involve all the manual work,  and we'd be much more likely to look at areas that we didn't write ourselves originally. I've really only seen 2-3 guys around here who regularly roll up their sleeves and try to "debug" Nasal-induced performance issues reported by end-users. And even core developers keep emphasizing how the lack of a debugger is making Nasal less appealing
  |{{cite web |url={{forum url|p=214064}}
     |title=<nowiki>Re: How can I retire from the forum?</nowiki>
     |author=<nowiki>Hooray</nowiki>
     |date=<nowiki>Fri Jul 04</nowiki>
   }}
}}

{{FGCquote
  |I am not interested in providing end-user support, or in dealing with poor bug reports, I am interested in providing people with means to provide us with good information that we can act upon, and I don't want this to be specific about a single technology, let alone a single subsystem like AW/ALS etc, or even require the people who originally wrote the code to be around to make sense of an issue. But I never said anywhere that I wanted to integrate a profiler or debugger necessarily - those are fairly low-level tools and most end-users couldn't deal with them either. <br/>
In fact, there's an integrated profiler, which while optional, is being used by fellow coders - and I was the one who provided the corresponding patch. Yet, I fully realize that is has not much of a merit when it comes to dealing with end-users.
  |{{cite web |url={{forum url|p=214076}}
     |title=<nowiki>Re: How can I retire from the forum?</nowiki>
     |author=<nowiki>Hooray</nowiki>
     |date=<nowiki>Fri Jul 04</nowiki>
   }}
}}

{{FGCquote
  |I find it kinda short-sighted to limit, or even just associate, the whole debate with TerraGear and scenery development. Anybody who's been around for a few years, knows that we've had a plethora of non-scenery features that ended up gobbling memory, even though I do agree that mentioning random buildings in this context was probably not very smart, I just did so, because it's a feature that has basically zero to do with TG. In other words, we're having issues regardless of TG, and I don't think it's fair to really blame it all on TG, which is a huge, complex and intimidating code base, so I don't envy the few people involved in working with it.<br/>
<br/>
I do think that my whole point about troubleshooting code that we also didn't write originally still holds true - I've worked with code like AW and Bombable, and quite a few other non-trivial scripts/applications, and here, having OPTIONAL tools to help diagnose issues (CPU/RAM utilization) is the most essential time-saver, and basically the motivator and key-prerequisite  to actually consider such attempts.
  |{{cite web |url={{forum url|p=214076}}
     |title=<nowiki>Re: How can I retire from the forum?</nowiki>
     |author=<nowiki>Hooray</nowiki>
     |date=<nowiki>Fri Jul 04</nowiki>
   }}
}}

=== Feature Scaling ===
{{FGCquote
  |Well why can we use a profile systems for users like me? ...<br/>
Example..at the start a option to put all FG options in basic.<br/>
another option better grafics but a limit of 2 Gb RAM (example).<br/>
Another option more resources, almos 4 GB RAM, etc.<br/>
And finally the moster option for i7 more than 8 GB all render options on, etc
  |{{cite web |url={{forum url|p=214287}}
     |title=<nowiki>Re: How can I retire from the forum?</nowiki>
     |author=<nowiki>Prometeo 2013</nowiki>
     |date=<nowiki>Mon Jul 07</nowiki>
   }}
}}

{{FGCquote
  | the main challenge is that FlightGear was never designed to do any form of explicit memory management, as per Stuart's comments here:<br/>
<br/>
{{forum link|p=165125|text=Subject: Random Buildings}}<br/>
{{cquote|I think it also opens up a larger question of how we do memory management in FG, and whether we should be doing things such as more aggressively freeing up terrain tiles.  At one level, removing entire terrain tiles from memory earlier if memory occupancy becomes a concern would be a better management strategy than just stopping generating new buildings.<br/>
<br/>
-Stuart}}
  |{{cite web |url={{forum url|p=214289}}
     |title=<nowiki>Re: How can I retire from the forum?</nowiki>
     |author=<nowiki>Hooray</nowiki>
     |date=<nowiki>Mon Jul 07</nowiki>
   }}
}}

{{FGCquote
  |Thus, while the idea to scale features up/down, depending on available resources, the majority of the legacy code in FG (especially anything unrelated to OSG/rendering) would need to be explicitly re-architected to 1) track memory allocations &amp; freeing, and to also adjust subsystems and their features accordingly. <br/>
<br/>
It's not something that can be simply suggested, the code  needs to know 1) how much it is using (which needs to be implemented for each supported platform), 2) where/how it is using it (specific subsystems), and 3) how to deal with situations like "not enough memory" vs. "sufficient memory: give me more features" - some data structures can be safely freed, while others would be critical for the simulator to work properly.
  |{{cite web |url={{forum url|p=214289}}
     |title=<nowiki>Re: How can I retire from the forum?</nowiki>
     |author=<nowiki>Hooray</nowiki>
     |date=<nowiki>Mon Jul 07</nowiki>
   }}
}}

=== OpenCL Support ===
{{FGCquote
  |Also, eventually adopting {{forum link|hilit=opencl|p=140065|text=OpenCL support}} would be a great way for some projects like local weather to parallelize more and more code.<br/>
<br/>
Thorsten mentioned {{forum link|p=93223|text=quite a while ago}}, that the local weather system has some code that would be trivially parallelizable:<br/>
<br/>
{{cquote|Most weather tasks parallelize almost trivially:<br/>
<br/>
* expensive setup calls use Monte Carlo techniques - which require to run the same routine ''n'' times - whether in parallel or sequentially doesn't matter<br/>
<br/>
* drifting clouds means performing position updates on a large array of objects - if that array is split into several parts which are processed in parallel or sequentially doesn't matter<br/>
<br/>
and so on - the main question is if the interaction with the Flightgear core (i.e. terrain info calls or writing into the property tree) can be structured such that parallel computation is useful.}}
  |{{cite web |url={{forum url|p=144679}}
     |title=<nowiki>Re: A local weather system (v1.36 available)</nowiki>
     |author=<nowiki>Hooray</nowiki>
     |date=<nowiki>Mon Dec 12</nowiki>
   }}
}}

=== Moving some Nasal code to other cores ===
{{FGCquote
  |some people have repeatedly expressed an interest in eventually running a weather simulation asynchronously from the main loop, i.e. either multi-threaded or in a separate process (the HLA interface was mentioned by Mathias and Torsten). <br/>
<br/>
Now, what I have recently been looking into is something conceptually similar to Torsten's FGPanel code. What Torsten did, was taking some existing FG source code and creating a new project from it, so that instruments could be rendered separately, in a separate process - while being driven by a master FG instance.<br/>
<br/>
So what I have been looking into recently is basically the same idea, but with a twist to it: running a dedicated Nasal instance in a separate process that communicates with FG via sockets. There are some obvious challenges here, such as running certain commands and making listeners etc work properly. <br/>
<br/>
But basically, you'd end up with a Nasal interpreter that is no longer frame rate limited.<br/>
<br/>
Overall, that would probably be one of the simpler options to run local weather asynchronously, without introducing explicit parallelism/threading.<br/>
<br/>
Obviously, that would require some thinking, because the Nasal code running asynchronously could no longer directly instantiate scenery objects (clouds etc), but would instead have to make a "network call" to the Nasal interpreter running inside the FG process instead. But I am pretty confident that this could eventually be solved by a workaround like the compat layer, i.e. by using a wrapper layer that redirects commands accordingly.
  |{{cite web |url={{forum url|p=146518}}
     |title=<nowiki>Re: A local weather system (v1.4 available)</nowiki>
     |author=<nowiki>Hooray</nowiki>
     |date=<nowiki>Tue Jan 03</nowiki>
   }}
}}

== Feature Scaling ==

{{FGCquote
  |This isn't the first person/contributor to state pretty clearly that they're kinda disappointed with the way FG has evolved over the years, some others stated pretty clearly that even a recent version of X-Plane looks and works better than FG 3.x using the same hardware - so I guess we should take this for what it is, i.e. feedback demonstrating that people no longer know how to scale down FlightGear's features. Admittedly, I also find myself  having to do quite a bit of tweaking these days, despite having fairly powerful hardware. Stating that all these are optional features and that people "merely" need to disable those, is as short-sighted as the whole multi-threading debate that we've been having since ~2006 ... Obviously, the "minimal startup profile" should still work for people, and it should easily provide ~60 fps, but that's not what people want FG to look like, and there are other products that simply provide a better experience. 
  |{{cite web |url={{forum url|p=213974}}
     |title=<nowiki>Re: How can I retire from the forum?</nowiki>
     |author=<nowiki>Hooray</nowiki>
     |date=<nowiki>Thu Jul 03</nowiki>
   }}
}}

{{FGCquote
  |So, I'd say we do have a problem, but what people consider the problem is usually just a symptom and not the real culprit. <br/>
But that should be understandable, most non-coders cannot easily understand all the factors involved here.
  |{{cite web |url={{forum url|p=213974}}
     |title=<nowiki>Re: How can I retire from the forum?</nowiki>
     |author=<nowiki>Hooray</nowiki>
     |date=<nowiki>Thu Jul 03</nowiki>
   }}
}}

{{FGCquote
  |To see for yourself, start up in a place without any scenery, keep FG running for several hours and then see the valgrind report (one of those tools that you refuse to use), while it's true that valgrind outupt is misleading in the context of OSG's ref_ptr's (smart pointers, that manage memory), we do have a number of memory-leaking features, including particles and even effects. <br/>
<br/>
If you know about any way to obtain this kind of low-level information without using the tools that you refuse to use, I'd be intrigued to learn more. <br/>
But ´for now, we're obviously talking about hugely different things, and one of us refuses to accept that end-users may have a point, even without having to be familiar with FG internals and all the lingo involved.
  |{{cite web |url={{forum url|p=214111}}
     |title=<nowiki>Re: How can I retire from the forum?</nowiki>
     |author=<nowiki>Hooray</nowiki>
     |date=<nowiki>Sat Jul 05</nowiki>
   }}
}}

{{FGCquote
  |Things like a slow Nasal/GC scheme are those that you cannot easily track down, without using tools like a profiler, debugger or leaks checking tool.<br/>
<br/>
Again, I never said that any of those had to be integrated - I just said, that /we/ may have to use them at times, and that we should probably strive to OPTIONALLY provide certain diagnostics at run-time to enable end-users to provide us with better information/bug reports. It's the difference between having a systime() API in Nasal, and not having one: 99% of our users may never use it, but people like you, may use it to tell what's going on.
  |{{cite web |url={{forum url|p=214111}}
     |title=<nowiki>Re: How can I retire from the forum?</nowiki>
     |author=<nowiki>Hooray</nowiki>
     |date=<nowiki>Sat Jul 05</nowiki>
   }}
}}

{{FGCquote
  |I never even questioned that our current issue is scenery related, I just said that we've been seeing other issues, and I pointed out that a few of us provided patches to recognize such issues much earlier (the v2.0 scenery issue was RANDOMLY identified by Atlas core developer Brian Schack if you remember). Had we integrated the corresponding resource tracking patches that we discussed (and posted) 4+ years ago, we would have had a much better chance of detecting  such issues - even regardless of them being specific to scenery, the Nasal GC or whatever.
  |{{cite web |url={{forum url|p=214196}}
     |title=<nowiki>Re: How can I retire from the forum?</nowiki>
     |author=<nowiki>Hooray</nowiki>
     |date=<nowiki>Sun Jul 06</nowiki>
   }}
}}

== Optional Features ==
{{FGCquote
  |All it takes to run the recent FG version on old hardware is to not use optional features and dial down the configuration. The project is most definitely not going into any direction making it impossible for some people to use FG - there's huge concern over backward compatibility on the devel list.
  |{{cite web |url={{forum url|p=213960}}
     |title=<nowiki>Re: How can I retire from the forum?</nowiki>
     |author=<nowiki>Thorsten</nowiki>
     |date=<nowiki>Thu Jul 03</nowiki>
   }}
}}

{{FGCquote
  |I mean, in that context FG is just a platform which runs the data you throw at it. Someone decided to develop that 777-S at high detail, and then it consumes more memory. Should the devel team veto detailed aircraft based on the notion that they might not run on all systems? Or could we perhaps trust users to select aircraft based on what runs on their system and what they want to have?<br/>
<br/>
Maxing out all options together (most detailed aircraft, most detailed scenery, high graphic detail,...) is intended for people with gaming hardware. Asking to be able to run that on every bit of hardware is unreasonable.
  |{{cite web |url={{forum url|p=213972}}
     |title=<nowiki>Re: How can I retire from the forum?</nowiki>
     |author=<nowiki>Thorsten</nowiki>
     |date=<nowiki>Thu Jul 03</nowiki>
   }}
}}

{{FGCquote
  |I agree wrt to valgrind, specifically if you want to profile, use callgrind and see in pretty colours how much time a piece of code takes to run. Requires lots of patience though.
  |{{cite web |url={{forum url|p=214112}}
     |title=<nowiki>Re: How can I retire from the forum?</nowiki>
     |author=<nowiki>adrian</nowiki>
     |date=<nowiki>Sat Jul 05</nowiki>
   }}
}}