20,741
edits
Resource Tracking for FlightGear: Difference between revisions
Jump to navigation
Jump to search
m
Resource Tracking for FlightGear (view source)
Revision as of 21:50, 1 September 2014
, 1 September 2014→Background
m (→Background) |
|||
| Line 3: | Line 3: | ||
[[File:Patching-fg-3.2-to-make-more-subsystems-optional.png|450px|thumb|Screen shot showing a the performance monitor in a patched version of FlightGear 3.2 where subsystem initialization is made better configurable and increasingly optional by allowing subsystems to be explicitly disabled/enabled during startup. Decoupling internal subsystem dependencies means that we can more easily provide support for [[FlightGear Benchmark|benchmarking]], but also [[FlightGear Headless|headless]] regression testing - and eventually, also a standalone [[FGCanvas]] startup mode. This simplified startup mode results in roughly ~120 MB of savings in RAM. ]] | [[File:Patching-fg-3.2-to-make-more-subsystems-optional.png|450px|thumb|Screen shot showing a the performance monitor in a patched version of FlightGear 3.2 where subsystem initialization is made better configurable and increasingly optional by allowing subsystems to be explicitly disabled/enabled during startup. Decoupling internal subsystem dependencies means that we can more easily provide support for [[FlightGear Benchmark|benchmarking]], but also [[FlightGear Headless|headless]] regression testing - and eventually, also a standalone [[FGCanvas]] startup mode. This simplified startup mode results in roughly ~120 MB of savings in RAM. ]] | ||
{{FGCquote | |||
|3.2 switched the base-package scenery to the <br/> | |||
high-resolution (i.e. memory-intensive) version, with the result that FG <br/> | |||
on default settings hangs my system (4GB memory, Intel graphics, no swap).<br/> | |||
<br/> | |||
It becomes usable after reducing the bare LOD range, but one needs to <br/> | |||
know to do that; I'd like to replace the fixed defaults by something <br/> | |||
that automatically adjusts to the hardware, but haven't yet got around <br/> | |||
to this. | |||
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32784078/ | |||
|title=<nowiki>Re: [Flightgear-devel] Download size, | |||
and hardware support (was .dds textures)</nowiki> | |||
|author=<nowiki>Rebecca Palmer</nowiki> | |||
|date=<nowiki>2014-09-01</nowiki> | |||
}} | |||
}} | |||
== Background == | == Background == | ||
{{Note|for better diagnostics, and better [[Subsystem-level Memory Tracking for FlightGear|end-user bug reports]], we could consider exposing a cross-platform process and system utilities module via [[Nasal/CppBind]], such as e.g. [https://github.com/giampaolo/psutil psutil] (Windows, MacOS & BSD/Unix) {{Not done}}}} | {{Note|for better diagnostics, and better [[Subsystem-level Memory Tracking for FlightGear|end-user bug reports]], we could consider exposing a cross-platform process and system utilities module via [[Nasal/CppBind]], such as e.g. [https://github.com/giampaolo/psutil psutil] (Windows, MacOS & BSD/Unix) {{Not done}}}} | ||
| Line 46: | Line 63: | ||
}} | }} | ||
}} | }} | ||
== Problem == | == Problem == | ||
It would be great to write subsystem-specific RAM usage info to the property tree, so that it can be shown (i.e. in the performance monitor), but also used by Nasal scripts to scale down features dynamically - the degree of swap usage vs. amount of free RAM is probably one of the most important metrics here. | It would be great to write subsystem-specific RAM usage info to the property tree, so that it can be shown (i.e. in the performance monitor), but also used by Nasal scripts to scale down features dynamically - the degree of swap usage vs. amount of free RAM is probably one of the most important metrics here. | ||