20,741
edits
FlightGear benchmark: Difference between revisions
Jump to navigation
Jump to search
m
no edit summary
No edit summary |
mNo edit summary |
||
| Line 8: | Line 8: | ||
{{FGCquote | {{FGCquote | ||
|3.2 switched the base-package scenery to the | |3.2 switched the base-package scenery to the high-resolution (i.e. memory-intensive) version, with the result that FG on default settings hangs my system (4GB memory, Intel graphics, no swap). | ||
high-resolution (i.e. memory-intensive) version, with the result that FG | |||
on default settings hangs my system (4GB memory, Intel graphics, no swap). | It becomes usable after reducing the bare LOD range, but one needs to 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 to this. | |||
It becomes usable after reducing the bare LOD range, but one needs to | |||
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 | |||
to this. | |||
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32784078/ | |{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32784078/ | ||
|title=<nowiki>Re: [Flightgear-devel] Download size, | |title=<nowiki>Re: [Flightgear-devel] Download size, | ||
| Line 23: | Line 19: | ||
}} | }} | ||
}} | }} | ||
{{FGCquote | |||
| | |||
* we appear to be single-thread-CPU bound (and if we are on my machine, we probably are on most) | |||
* terrain mesh (bare LOD range) costs memory, instanced objects (random *s) and the first shader step cost frame rate, unique objects (complex airports/aircraft) cost both | |||
* texture format makes little difference to either main memory use or frame rate (but note that global-png and global-dds are probably not a fully like-for-like comparison) | |||
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32792620/ | |||
|title=<nowiki>[Flightgear-devel] Performance tests</nowiki> | |||
|author=<nowiki>Rebecca Palmer</nowiki> | |||
|date=<nowiki>2014-09-03</nowiki> | |||
}} | |||
}} | |||
{{FGCquote | |||
|<nowiki>Except as stated: current 3.3 with my locked-listener patch (see earlier today), c172p stationary on KSFO 28R, --timeofday=noon --disable-real-weather-fetch --disable-ai-traffic (for consistency), Terrasync scenery, LOD range 1.5/9/12km, regional textures, random buildings/objects/vegetation and precipitation/3D clouds on, shader level 1, default (looks about 1024x730) window size. | |||
Fresh run for each setting, Intel i5-3230M with integrated GPU, Ubuntu 14.04 64-bit, memory/CPU measured with System Monitor (may not include GPU memory, 25%=one core fully loaded)</nowiki> | |||
* baseline: 19fps 1.3GB memory 24% CPU | |||
* unlocked listener (the old, crash-prone way): 18.5fps 1.3GB 24% | |||
* polling (current next): 12fps 1.3GB 24% | |||
* global-png textures: 20fps 1.2GB 23% | |||
* global-dds textures: 18.5fps 1.2GB 23% | |||
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32792620/ | |||
|title=<nowiki>[Flightgear-devel] Performance tests</nowiki> | |||
|author=<nowiki>Rebecca Palmer</nowiki> | |||
|date=<nowiki>2014-09-03</nowiki> | |||
}} | |||
}} | |||
[[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.]] | [[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.]] | ||