Feature Scaling

From FlightGear wiki
Jump to navigation Jump to search
This article is a stub. You can help the wiki by expanding it.
Note  In its current form, this section/article is largely based on quotes collected from various related discussions/channels (devel list, forum etc) using the Instant-Cquotes script. Wiki users and other contributors are encouraged to help rewrite/edit contents accordingly to help get rid of unnecessary quoting (i.e. while the wiki is not intended to be a collection of quotes, quotes are sometimes the best/easiest way to bootstrap new articles, while also providing a good way to link back to related discussions in the archives).

While rewriting usually only entails changing first person speech to 3rd person. However, please try to retain references/links to the original discussion whenever possible.

Gallery


Background

Cquote1.png It does not seem to be a technical problem - to query a string from the property tree is easy, to write a routine which sets other properties based on what the string says is equally easy. The problem is the meat of it - someone has to know what settings are likely to run on what graphics cards. And someone has to write the routine that does it. Then it's done.
— Thorsten (Feb 7th, 2016). Re: Review of FG on reddit: xpost.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png I wonder if it would be possible to create configuration files based on OpenGL capabilities to set certain options, mucht like a joystick configuration file but instead for video cards. The glxinfo utility shows an awful lot of information which probably be used for tuning the default setup.
— erik (Feb 6th, 2016). Re: Review of FG on reddit: xpost.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png I was more referring tot the scene rendering when first starting FlightGear.

And the option to turn on specific ALS options for certain OpenGL renderers. For instance mine is "GeForce 9600 GT/PCIe/SSE2" which can have almost anything set to on without much hit on frame-rate except for procedural 3d textured cities which hurts performance badly.

But it does not allow to set the densities much higher than default.
— erik (Feb 6th, 2016). Re: Review of FG on reddit: xpost.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png The only thing I want to do is detect the video card and based on the GL renderer name turn on ALS (or not), turn on water shader (or not), turn on the 3d city shader (or not), etc. The default would not be touched but based on the detected video card certain options would get enabled, making the first impression much more pleasant (for first time users).
— erik (Feb 7th, 2016). Re: Review of FG on reddit: xpost.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png For the more general question of what to enable by default, what we could really do with is a way to automatically adjust to the hardware.
— Rebecca N. Palmer (Aug 13th, 2015). [Flightgear-devel] Defaults Re: Basic Weather.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png I suggested automatically changing the LOD range according to available memory (which would probably be easier), but never got around to actually working on it.
— Rebecca N. Palmer (2015-02-05). Re: [Flightgear-devel] FlightGear on low (<=4GB) memory systems.
(powered by Instant-Cquotes)
Cquote2.png


Cquote1.png FlightGear's defaults don't scale very well at the moment. But to be honest, backward compatibility has never been a real priority ...
— Hooray (Mon Dec 10). Re: Help needed - market research for FG.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png what's really needed is a form of dynamic feature scaling that can check the features supported by a platform and then find a working set of features which still provide reasonable performance and a good experience, all of this taking place during start-up.
— Hooray (Mon Dec 10). Re: Help needed - market research for FG.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png it was stuart who mentioned this a while ago: This could be implemented by using a Nasal script to monitor a handful of properties and by adjusting some other parameters dynamically.

That shouldn't require any C++ modifications.


Cquote2.png
Cquote1.png We already have a number of examples doing a simple form of feature-scaling by monitoring certain parameters and then adjusting internal behavior accordingly. The local weather system already uses such heuristics for example. And "property rules" could be easily used to come up with additional rules.
— Hooray (Thu Feb 21). Re: Flightgear-specific benchmark.
(powered by Instant-Cquotes)
Cquote2.png


Cquote1.png anything that can be controlled at runtime via a property can theoretically be also adjusted ("feature-scaling") by watching critical properties like the fps counter or frame spacing latency. You would need to check the rendering settings dialog if your settings are listed there, and extract the corresponding properties, then register a timer that watches frame rate & frame spacing and detects lag (spikes in frame spacing) and throttle down features. That's basically 5-7 lines of trivial Nasal code, trivial even to people who never looked at Nasal before, once you want to apply some filtering, things get a bit more sophisticated, but still do-able.
— Hooray (Sat Dec 07). Re: FPS dependent AA and AF.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png Currently, we are spending resources without having any clue how much we have left - no matter if it's CPU or RAM/VRAM, our tools are pathetic and not well-developed to help with this sort of thing, as has been brought up numerous times by other before.


Sure, you can investigate performance issues, depending on your background you may even be skilled and successful - but that requires a conscious effort, having an integrated system that monitors CPU/RAM usage isn't uncommon at all in complex software - I'm pretty sure that even your browser has a corresponding "task monitor" - not to mention your OS, these tools are there for a reason - and any educated software engineer will tell you that you can only develop software up to a certain point until you need to have access to such details, or things are likely to bite you sooner or later ...


— Hooray (Sat Feb 08). Re: fg3.0rc1 memory usage.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png I did give this a try a while ago and ran into a problem.

Let's say, I set my minimum-fps setting to 20. The script will disable features. One at a time, until the fps are 20. However, you do want to have those features enabled again when your fps allows it. Problem is then that you end up in a circle. Once the fps is 30, 3D clouds are enabled, making the fps to drop below 20. Therefore, 3D clouds are disabled again, pushing the fps to 30 again. Which is enough to enabled 3D clouds, etc. etc. So the implentation isn't just a matter of auto enabling/disabling features based on framerates. Some other people might have better ideas/ways than I had though


— Gijs (Thu Apr 22). Re: feature .
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png Yes - feature scaling isn't likely to work when the granularity of the feature's effect on FPS is so high, e.g. 3D clouds.

One thing you can do to help, if you haven't already, is to use a low pass filter on the FPS input. That will help smooth out any intermittant drops in FPS without disabling loads of features.


— stuart (Thu Apr 22). Re: Feature Poll.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png In my opinion, scaling up is not going to be as difficult as scaling down - and for that reason, I would love FG to start up with an extremely minimal startup profile, and dynamically determine if there's hardware available to do more resource-hungry things, such as using shaders, multiple cores, many GBs of RAM etc.

Meanwhile, we have reached a point, where it's become a real piece of work to start FG on old computers, or even on Intel-graphics based computers.
Admittedly, I do not expect to be able to run X-Plane or MS FSX on such computers, but yeah - I would love to be able see FG running on such computers, because it also means that we're doing something right here. Keep in mind that there are probably more users using FG because of its "cost" (i.e. being free), and not because they expect the latest eye-candy.


— Hooray (Sat Feb 08). Re: fg3.0rc1 memory usage.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png Being able to start up FG using a "safe" subset of enabled features would be great for people with older/underpowered hardware - but it would also be great for us, i.e. from a troubleshooting standpoint, but also from a benchmarking perspective, because we could dynamically scale up settings-based on what's available.
— Hooray (Sat Feb 08). Re: fg3.0rc1 memory usage.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png At least starting with a minimal profile should be trivial to implement: Define a property /sim/use-minimal-profile at startup, have a Nasal script check whether that property is set, and if yes, have it execute a batch of setprop() statements forcing all config options to minimal. No need to bother users with modern hardware, well-defined starting point for users with older hardware.


I don't believe in dynamical up-scaling, because you can't know what people want. I'm quite cool with 20 fps, Mathias has made it quite clear that anything below a steady 60 fps isn't acceptable for him, I see people fly with 10 fps still. Airliner pilots would prefer large visibility over having detailed trees, helicopter pilots usually ask for better (=more memory-intense) trees. This has to be done by the user who wants certain things done.

At the same time, I think dynamical automatic upscaling would be technically complicated, and I think the limited manpower would better be spent doing other things.


— Thorsten (Sat Feb 08). Re: fg3.0rc1 memory usage.
(powered by Instant-Cquotes)
Cquote2.png


Cquote1.png the first step is providing built-in means to gather system statistics at run-time (analogous to a task/process monitor), to see how CPU/RAM/GPU/VRAM are utilized when certain features are active, so that we can better identify subsystems and features that are resource hogs, e.g. because they eat up RAM or frame-rate. The next step is to either introduce feature-scaling then, or make such features entirely optional.

With a focus on RAM, the basic idea is summarized at: Subsystem-level_Memory_Tracking_for_FlightGear But the same thing could be done for CPU/GPU utilization.


— Hooray (Sun Jun 08). Re: Slope line patterns.
(powered by Instant-Cquotes)
Cquote2.png


Cquote1.png exposing internal stats to the property tree would still seem useful, especially for people wanting to make bug reports, or even just for dynamic "feature-scaling" using Nasal and/or XML-Property Rules.
— Hooray (Wed Aug 22). Re: .
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png The neat thing about writing such stats directly to the property tree would be that we could use Nasal scripts to watch those values and change things on demand or issue warnings to the console, for example to implement feature scaling This is a link to the FlightGear forum..


Registering a Nasal based listener to watch a property and log a warning to the console saying "Warning: The Nasal system takes too long to update, there is probably a rogue script running".


— Hooray (Thu Sep 02). Re: Enabling multiprocessor support.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png having some kind of standardized "API" for feature-scaling would be good - on the other hand, I do believe that we first of all need a way to really "look under the hood" and see which features are expensive in terms of CPU/GPU, RAM and VRAM utilization - otherwise, it is far too easy to keep pointing out how poorly some aircraft perform, without giving aircraft developers the right tools to actually tell what's going on in terms of performance, i.e. regarding textures, 3D models, scripts etc
— Hooray (Mon Jun 23). Re: What to expect from FlightGear 3.2?.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png I do think that such a benchmark could probably be implemented directly in FlightGear, just by using Nasal scripting and some custom XML files.


This would be pretty much related to the idea of "feature scaling" which was discussed in the other thread#p75961 the idea of "feature scaling" which was discussed in the other thread This is a link to the FlightGear forum..

One would only need a way to create a default situation (i.e. like a custom preferences.xml file) and a way to dynamically toggle FlightGear features on/off and tweak them at runtime.

This should be pretty straightforward to do, at least for those features (configuration properties) that are already using listeners or that are read every frame. This applies to most of the recent graphics additions (i.e. shaders), because these can be dynamically enabled, disabled and configured.


— Hooray (Thu Apr 22). FlightGear Benchmark.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png SGTimer/maketimer() API would ideally also allow for a callback to be specified in case framerate/performance is too bad to run the timer at the interval specified.

sort of like a notification callback that would get called if necessary - that would standardize the various feature-scaling attempts we have, i.e. down-grading features according to frame rate/latency.

setlistener/settimer are way too low-level for most fgdata contributors, because they require manual management and explicit design to prevent certain bugs/issues, such as having identical callbacks running concurrently, even though the programmer really only wanted a single instance of a callback/loop to be active.

I would also think an option to automatically release listeners/timer objects during sim-reinit would be useful - this should probably be enabled by default.
That would probably solve 90% of timer/listener issues we have in fgdata.


— Hooray (Sun Nov 10). Re: Listener objects.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png this is often called "feature scaling".If anybody is really interested in this, I think this could be rather easily done by using a Nasal script that dynamically enables, disables and tweaks various settings at runtime, I am willing to provide help if you have trouble getting started doing this in Nasal.
— Hooray (Thu Apr 22). feature .
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png Even a very simple benchmark could be useful for feature-scaling purposes, and if it's implemented in a non-interactive fashion, it could even help with regression testing. Ideally, a benchmark would start out with the bare minimum settings and then dynamically change settings on the fly to determine their effect on frame rate and frame spacing, to come up with a list configuration settings that work properly, while ensuring a satisfying simulator experience.


We already have various building blocks in FG to do most of this, it's really just a matter of combining and integrating existing features to provide such a simple benchmark.

From a troubleshooting perspective this could in fact also be useful, because we could ask users to open a certain dialog and run a certain benchmark and report the results here.


— Hooray (Thu Feb 21). Re: Flightgear-specific benchmark.
(powered by Instant-Cquotes)
Cquote2.png


Cquote1.png it's commonly called "feature scaling", and has been discussed at lengths here. But for the time being, it would be as straightforward to implement as changing your FDM in-flight by adjusting engine/wing foil parameters - I am sure your FDM was never designed with such requirements in mind, and that also applies to most of the legacy FG code that's been around for over 15 years now.

Feature scaling involves not just reading a value/variable once, but either polling it (updating it permanently at frame rate) or acting upon events if some variable has changed, to reset/re-init or adjust the corresponding system - most people didn't/don't write their code that way, because it takes more time - see the XML discussion we had with Stiglr a few days ago: [2] This is a link to the FlightGear forum.


— Hooray (Thu May 15). Re: Dev and test environment.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png "Feature scaling" is a long-standing feature request, and it simply involves making things better configurable, which also happens to be a key ingredient for runtime benchmarking, i.e. "in-game" profiling, which is another thing I am interested in supporting sooner or later. Not so much to have 1:1 benchmarks, but rather to do regression testing in an automated fashion, so that certain problems can no longer go unnoticed.
— Hooray (Sat Apr 26). Re: Available to everyone...or is it?.
(powered by Instant-Cquotes)
Cquote2.png


Cquote1.png Some settings that come to mind include:
  • fog type
  • scenery visibility
  • fdm update rate (model-hz)
  • clouds (2D, 3D, visibility and density)
  • vegetation (random trees)
  • random objects
  • shaders (landmass, clouds, water)
  • shadows<
  • particles
  • precipitation

(and probably many others!)


— Hooray (Thu Apr 22). feature .
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png Many of these things can already be dynamically configured because they are driven using properties, most of these are made available in the "rendering options" dialog, so it would be straightforward to use a Nasal dialog to tweak FlightGear at runtime.

So it would be mostly a matter of using a Nasal script to optionally tune these settings automatically, maybe with some simple GUI dialog for configuration purposes.


— Hooray (Thu Apr 22). feature .
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png 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.
— stuart (Fri Aug 24). Re: .
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png That said, OSG has quite a lot of "clever" machinery to help with memory management, at least with all the rendering-related stuff.

For "problems" like excessive ram usage with random buildings and random trees, there are well-defined "standard" solutions available in OSG - but for many others, there aren't any. So rendering-related issues can be obviously addressed by using what's provided by OSG.
Thus, the issue is real two-fold: some subsystems making excessive usage of RAM, and others leaking lots of memory.
Probably, that would justify introducing a dedicated "memory management subsystem" eventually - i.e. something like a new/delete replacement that uses the boehm/weiser GC to manage resources dynamically, or a custom memory pool implementation using "placement new" for subsystems and other code allocating memory.
Manual memory management in C++ is always extremely tedious and error-prone, especially in non-trivial projects with a long history and lifespan.


— Hooray (Fri Aug 24). Re: .
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png The other LOD setting I keep debating about, is the ‘lod-bias’ feature the OSG pager has. This can be used to bias the LOD metrics arbitrarily, and in particular based on frame-rate. It would need a PID controller to drive it I think (but we have the code for one of those!), but the idea would be to bias LOD to achieve a target frame-rate; effectively ‘stuff’ which uses the OSG pager system (random building/trees, scenery models) would be unloaded if frame-rate dropped.
Cquote2.png
Cquote1.png I haven’t even made the experiments around this, but conceptually it feels nice to me - I’d much rather the system unload buildings/models to maintain a target 30fps. It would work even better with a ‘bare’ / ‘detailed’ BTG scheme of course, since we’d revert distant tiles to the bare version automatically.
Cquote2.png
Cquote1.png What I don’t know is how badly the system would hunt for the target frame-rate; i.e load in some expensive PagedLOD containing random buildings -> FPS drops -> bias increases -> PagedLOD unloads -> repeat. That’s why I assume a PID controller is needed, plus some additional logic to reset the bias on re-position. I can also imagine making a 180-degree turn changing the factors hugely (looking at Manhattan vs looking out to sea at KJFK), and the PID controller working the bias hard to deal with that. /And/ as you said above, we know loading+unloading has its own costs.
Cquote2.png
Cquote1.png Actually what I’d really be looking for here is not unloading, but simply skipping the culling+drawing - maybe that falls out from your expiry time change too.
Cquote2.png
Cquote1.png X-plane seemingly has something on firstboot that sets graphic settings according to your computer. Having this integrated into FG can prevent some users complaining about bad imagery,although what they forgot is the Rendering setting. Rough algorithm suggestion -Set settings to Lowest/off -Gradually add effects THEN shaders until we get nearest to(but more than) 25fps. Interested? Help me plan the algorithm. I think this will be in Nasal.
— Poomklao Teerawattanaprapha (Jan 14th, 2016). [Flightgear-devel] Feature suggestions:Automatic setting of Rendering.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png It's not as easy as it sounds here. First, users are different - some like 60 fps steady and don't care too much about visuals. Others want opulent visuals and are willing to go down to 10 fps. Second, effects drag the framerate when they're used, i.e. when you look at an object rendered with them. So you don't know what quality level of, say, the water effect the system can sustain at 25 fps unless you're looking at a water surface. Third, visibility influences framerate often more than quality settings - what runs find at 20 km visibility may not at 120 km. Fourth, we have different rendering frameworks to provide options - what do people want to burn their GPU cycles for? You can opt to do it for dynamical lights and shadows, then you get Rembrandt, you can opt to do it for atmosphere visuals, haes and procedural terrain texturing, then you get ALS. Fifth, I have no clue what distinction between effects and shaders you're trying to make here. We do have fixed pipeline effects which don't run any shaders, but they're sort of the lowest fallback option before declaring failure, so we can't really gradually add them. I guess in the end better explaining to users how the rendering settings can be chosen and what affects what or perhaps some more intuitive GUI tweaks may work better. My two cents... but feel free to try it - I've once toyed with an 'hold framerate' controller for how far out we render clouds, and I wasn't really happy with it.
Cquote2.png

Efforts

Cquote1.png I may also look at the Nasal side of things - because thanks to all the reset/re-init work, the C++ dependencies are fairly straightforward to decouple these days, I just made the tile manager optional in under 10 minutes, i.e. all the scenery/sky/stars is gone now - which means that FG is now utilizing less than 140 MB of RAM here using this "startup mode".

So this about more than just "FGCanvas": It will make troubleshooting so much more straightforward, and we can also explore feature-scaling and run-time benchmarking once this works. Currently, I'd even consider restructuring initialization to always boot up like this, because it's the safest possible subset of subsystems for now - i.e. roughly a dozen subsystems that basically stand no chance of "crashing" the sim. And from then on, additional initialization could be handled by Nasal obviously - and scripts could even scale up/down, depending on hardware support and features.


— Hooray (Sun Jul 06). Re: FGCanvas Experiments & Updates.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png In the near term, it would be better to extend the fgcommand-basd re-initialization mechanism that Zakalawe came up with ($FG_SRC/Main/subsystemFactor.?xx) to specifically support such initialization groups, analogous to "run-levels". That would then allow us to script initialization, without having any hard-coded stuff in fg_init.cxx that should be optional, and it would allow people to use the same mechanism to support benchmarking, feature-scaling or even regression testing.
— Hooray (Tue Jul 08). Re: FGCanvas Experiments & Updates.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png A while back, I started preparing a patch to add the corresponding diagnostics (RAM usage tracking) to FG so that we can better identify problematic features, and either fix them or at least provide feature-scaling support if necessary. Back then, this was unfortunately ignored and disregarded - recently, this is getting some more attention again, so we'll probably revisit the issue during the 3.2 release cycle. The first step really is getting "live" memory usage details, and exposing this via the property tree - so that we can tell 1) how much RAM is there, 2) how much RAM is being used by fgfs, 3) and: are we swapping ?


These three things are trivial to implement, I provided a patch doing this on Linux and it only took 20-30 minutes - so this could be done for Windows & Mac/OSX, too - and it would be straightforward.
That alone will not yet improve things - it will just show us that there is a problem.

The next step would involve doing the whole thing at a more fine-grained level, i.e. for each subsystem - so that we would have a list of subsystems, analogous to ThorstenB's system monitor, but see how much RAM is being used, allocated and freed per minute/5 minutes/10 minutes etc - analogous to how htop/top work


— Hooray (Mon Feb 03). Re: fg3.0rc1 memory usage.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png agreed, I once talked with Stuart and TheTom about also adding details about the amount of physical RAM vs. swap usage, too - having these things available in FG, would make troubleshooting around here quite a bit easier, and would also allow us to do feature-scaling, I provided a patch for this for a Linux implementation back then, and we could probably extend this for all main OS (win, mac, linux): [3] This is a link to the FlightGear forum.


As can be seen, we specifically talked about subsystem-specific RAM usage tracking (random buildings, canvas, autopilot, replay/flight recorder etc) -analogous to ThorstenB's system monitor, just with a focus on RAM (memory).

Possibly via some custom smart pointer implementation that overloads new/delete - the main issue being that we really need a way to track memory usage per subsystem, so that we can identify "rogue" features - either to fix them, or to provide hooks for feature-scaling purposes.


— Hooray (Fri Jan 31). Re: 3.0.0 MacOS first impressions.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png For Nasal space, we pretty much have a working solution that could help us identify scripts that are causing lots of new naRefs or temporaries. But C++ code is a different beast, and as can be seen in many discussions here - we have quite a few people with >= 8gb of RAM seeing crashes on 64 bit OS due to "out of RAM" errors.


There's also many other examples for this, such as the v2 scenery eating up tons of RAM without anybody noticing, until the atlas developer pointed this out: [4] This is a link to the FlightGear forum.

So for post 3.0, we should probably investigate how to track RAM per subsystem/feature and provide some "live" stats.

See: Subsystem-level_Memory_Tracking_for_FlightGear


— Hooray (Fri Jan 31). Re: 3.0.0 MacOS first impressions.
(powered by Instant-Cquotes)
Cquote2.png