Board index FlightGear Support Graphics

How to tell if you are CPU or GPU limited (split)

Graphics issues like: bad framerates, weird colors, OpenGL errors etc. Bad graphics ar usually the result of bad graphics cards or drivers.
Forum rules
In order to help you, we need to know a lot of information. Make sure to include answers to at least the following questions in your initial post.

- what OS (Windows Xp/Vista, Mac etc.) are you running?
- what FlightGear version do you use?
- what graphics card do you have?
- does the problem occur with any aircraft, at any airport?
- is there any output printed to the console (black window)?
- copy&paste your commandline (tick the "Show commandline box on the last page of FGRun or the "Others" section on the Mac launcher).
- please upload a screenshot of the problem.

If you experience FlightGear crashes, please report a bug using the issue tracker (can be also used for feature requests).
To run FlightGear on old computers with bad OpenGL support, please take a look at this wiki article. If you are seeing corrupted/broken textures, please see this article.

Note: If you did not get a reponse, even after 7 days, you may want to check out the FlightGear mailing lists to ask your question there.

Re: How to tell if you are CPU or GPU limited (split)

Postby hamzaalloush » Wed Sep 23, 2015 5:23 pm

Hi,

Hooray wrote in Wed Sep 23, 2015 2:19 pm:
that's really cool, if we could add the corresponding hooks to do create these kind of statistics/graphs more easily, we could grow a really useful library of regression tests, with frame rate/frame spacing really just being the start of a thorough benchmark suite.



Maybe through the use of Canvas to plot/track properties and then using a native image exporter lib(we already export PNG), that comes with FG?

Hooray wrote in Wed Sep 23, 2015 2:19 pm:
Even though I guess, that it would make sense to use the minimal startup profile (no scenery) as the baseline for all benchmarks, so that the impact of different subsystems (think AI/MP, FDM etc) can be measured against a really "lean" startup profile.



if we could initialize subsystems in order, that would be great for evaluating the impact of each, but for it to be testable, we would need a controlled environment, in the case of AI a "scenario", in the case of FDM a set of instructions to fly along a certain path within a set time-frame, that would gather the footprint for that FDM driving along a similar path, perhaps on CPU usage rather than GPU?

Hooray wrote in Wed Sep 23, 2015 2:19 pm:
Ideally, we would grow a handful of "tests" and then try those with different variables, i.e. aircraft/location.
Given the SIGAR patches we have, we can also add actual RAM/SWAP utilization into the mix, too.

...

In its current form, this is already pretty cool and informative, especially if we could create a table for different airports/aircraft to show the impact of those settings, and how they scale with things like visibility/shader quality.



It would be easier for the user, to select one of pre-recorded files to be parsed with generic "playback" protocol from a GUI, the set of circumstances to be tested is a given, but the use of the system with which to do so is a decision.

i.e using an existing feature like the FGTape, or introduce a new one?

I would like to know the advantages for FGTape, knowing that the generic protocol potentially (might have?) skipped the Nasal-based FDM of the UFO, but it still had the ability to place objects, which might have introduced some Nasal/C++ code into the test, but i don't know how it's implemented, therefore i suggest maybe a new -set.xml to remove this functionality, the UUIC flight model could be sufficient, but it wouldn't allow for different FDM's to be tested for the subsystems idea.

Hooray wrote in Wed Sep 23, 2015 2:19 pm:
To be really useful, such a benchmark should ideally wait for 30-60 seconds after booting FG, to ensure that all subsystems are up and running.



FG was kind enough to only log properties as the scene started, but there still existed the first 3 seconds in the log where the FPS was in the single digits(apparently initializing something), so per standard, all of my input were gathered from the 3-70 seconds range.

I just re-did the scenery_2 test, since that was the last test i left off from yesterday, and it's consistent with yesterday, recording an AVG of 46.27, which is pretty close! :)

Hooray wrote in Wed Sep 23, 2015 2:19 pm:
My suggestion would be to set up a table of startup settings on the wiki (.fgfsrc), so that people can more easily reproduce "scenery 0...x". Alternatively, we could add a directory to $FG_ROOT, e.g. $FG_ROOT/Profiles and patch FG to load .fgfsrc files from there. That would help ensure that people are actually running the same startup settings.



all my tests were done with the same fashion,

Code: Select all
--prop:/sim/menubar/visibility=false --prop:/sim/ai-traffic/enabled=false --visibility=20000 --disable-clouds --disable-clouds3d --prop:/sim/rendering/draw-mask/clouds=0 --generic=file,in,30,flight.out,playback,repeat --fdm=external


the first part before the protocol, is very important to maintain consistency, since these would be the ones to introduce random output, clouds for instance can hide the airport, while i thought the draw mask is drawn randomly, so i tried to maintain the same vertex count each time, with no PUI-elements involved.

in this case i didn't set any shader/graphics level from the command-line, but i do it manually and then restart FG to do the tests, do you know a way that i can do that from the command line or .fgfsrc?

Hooray wrote in Wed Sep 23, 2015 2:19 pm:
But I would hope that we can add more metrics, and expose those to the property tree - e.g. stuff like RAM utilization (for which we have working code), but also other stuff like Nasal GC stats, but also listener/callback overhead.



Which brings me to the question, because sometimes just after my computer starts there exists a delay that skews my testing, so does SIGAR have metric for read/write speed, etc?

Edit: What i mean by no_scenery test, is not that there is no terrain, but i was just evaluating the footprint/fps cost of my scenery models,

scenery_0(shader level 0, so model using default-eff) = - 2.55 fps cost
scenery_1(shader level 1, so model using model-combined-deferred.eff) = - 4.8 fps cost, - 7.34 total
hamzaalloush
 
Posts: 632
Joined: Sat Oct 26, 2013 9:31 am
OS: Windows 10

Re: How to tell if you are CPU or GPU limited (split)

Postby Hooray » Wed Sep 23, 2015 6:04 pm

just briefly, I would not use Nasal/Canvas for plotting, because that will only add to the mainloop overhead (Heisenberg), which will not be an issue for the non-scenery test-case that runs at >= 250 fps, but will quickly show once scenery/terrain, weather etc is running.
For the time being, Canvas (and Nasal) are strictly single-threaded, so there is really no good way to make use of OSG's concurrency support for doing this stuff asynchronously.

Thus, my suggestion would be to either use the existing property logging (CSV) mechanism, or to come up with a custom CSV-logger implemented in Nasal space that merely fopen()s a file in $FG_HOME/Export and appends() properties as CSV values to it.

Such a helper module should be straightforward to prototype in Nasal with ~50 lines of code (Philosopher would probably only need 30...)

Regarding subsystem initialization, that is possible using the "Initializing Nasal earlier" topic branch we have, but it will not be too useful here, because all the systems added in fg_init.cxx will only be appended to a vector, actual initalization happens much later - and the mainloop isn't even running then.

For tests, we need to differentiate between stationary/moving aircraft, and the moving part is best accomplished using the autopilot/route manager - which is why it makes sense to use an aircraft with an actual FDM (jsbsim/yasim) rather than a pseudo FDM scripted in Nasal.

The added benefit being that simulation time can be accelrerated, so that a 10-minute flight could be executed in 2-3 minutes.

Concerning pre-recorded flights, those should work for starters, but it does make sense to consider using the fgtape approach instead, because that can be also extended to cover other properties, including those that control other aspects of the simulator, e.g. rendering settings

So my preference would be to use what it is available right now, and only look at what needs to be extended - fgtapes could easily be taught to also capture rendering related properties.

he UUIC flight model could be sufficient, but it wouldn't allow for different FDM's to be tested for the subsystems idea.

actually it does, by changing the aircraft - but it would make sense to focus on what is possible now


for shader/effects related CLI settings, please refer to the minimal startup profile detailed on the wiki

Which brings me to the question, because sometimes just after my computer starts there exists a delay that skews my testing, so does SIGAR have metric for read/write speed, etc?


it does, in the disk I/O related "file system" module, example code at: https://github.com/hyperic/sigar/blob/m ... sigar_fs.c


What i mean by no_scenery test, is not that there is no terrain, but i was just evaluating the footprint/fps cost of my scenery models,

there are also so called "draw masks" that you can use to selectively enable/disable rendering of scenery/aircraft, AI objects etc: http://wiki.flightgear.org/Troubleshoot ... up_profile
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11375
Joined: Tue Mar 25, 2008 8:40 am

Re: How to tell if you are CPU or GPU limited (split)

Postby Hooray » Wed Sep 23, 2015 6:16 pm

I would also suggest to commit your startup profiles, and data files, to a public repository - so that we can use the data to plot different graphs.
For instance, once we find a way to add "events" as markers (time stamp) to the graph, we could also measure the impact of dynamically enabling/disabling features like rendering of AI/cloud objects, or even show events for the Nasal GC.

On Linux systems, gnuplot can also be taught to create animated GIFs and/or videos using such data: http://www.gnuplotting.org/tag/animation/

I guess that some of us will be good at coming up with different kinds of tests, while others may be able to extend FG accordingly, and even others may be pretty good at coming up with fancy gnuplot diagrams that cover several attributes, like frame rate, frame spacing and RAM usage at once (Thorsten??)

f we could initialize subsystems in order, that would be great for evaluating the impact of each


do you know what is causing those spikes in frame spacing ?
have you considered also plotting frame spacing for each time stamp ?

You can get pretty accurate stats using the performance monitor - it will write everything to the property tree. To see for yourself, open the performance monitor dialog and then use the property browser to watch the performance monitor branch in the property tree, you can learn more by inspecting $FG_ROOT/Nasal/performance_monitor/monitor.nas

As you can see there, the switch for enabling the monitor is /sim/performance-monitor/enabled (bool)

This will work regardless of the PUI dialog, and you can view/access all stats (for each subsystem!) without showing the PUI dialog (=better performance)

For a list of subsystems, go to /sim/performance-monitor/subsystems

Note that you can also use the http (browser) or telnet protocols to do this while extending the logging protocol

For each sample, "frame spacing" should be the largest value, whereas each subsystem would have a delta time that corresponds to a fraction of the total d/t
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11375
Joined: Tue Mar 25, 2008 8:40 am

Re: How to tell if you are CPU or GPU limited (split)

Postby hamzaalloush » Thu Sep 24, 2015 12:00 am

Hooray wrote in Wed Sep 23, 2015 6:16 pm:do you know what is causing those spikes in frame spacing ?
have you considered also plotting frame spacing for each time stamp ?


I'm not sure yet, but i have an idea, it might not be rendering related at all, it might just be a "gap" in the pre-recorded data that introduces a frame skipping, i tried to avoid that by recording double the frame rate, i ran FG with 15 FPS locked(an amount that i knew the graphics card would hold steady) and recorded in 30 hz to avoid this scenario for a better "sampling rate" of the path data.

The weird thing is, i still see these spikes occurring at exactly the same places even if i use the Intel integrated graphics(with terrain draw mask disabled!).

I guess i have to inspect a little further logging the performance monitor sub-systems.

edit: just briefly for today, i visually inspected the performance monitor while doing the scenery_0 test, and it seems there is a consistent frame-spacing issue (at the same spot) that happens with a 10x increase in the "events" sub-system, I’ll try to have a log by tomorrow.
hamzaalloush
 
Posts: 632
Joined: Sat Oct 26, 2013 9:31 am
OS: Windows 10

Re: How to tell if you are CPU or GPU limited (split)

Postby Hooray » Thu Sep 24, 2015 4:53 am

"events" is the subsystem that triggers/runs Nasal timers, and any Nasal code (anywhere), may trigger the GC (garbage collector) - to see if that's the case, you can use the "GC tracker" patch in the sigar code we have.

Alternatively, you can use ThorstenB's patch and set a property while the GC is running, and unset it afterwards - those properties could be shown as "events" in the diagram, i.e. to highlight the portion of the graph where the GC is executing, which is probably consistent with those spikes.

We can then also log the number of active references/objects and add those to the graph
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11375
Joined: Tue Mar 25, 2008 8:40 am

Re: How to tell if you are CPU or GPU limited (split)

Postby pommesschranke » Sat Oct 24, 2015 8:22 am

switch ALS off, open the detailed shader quality management, switch all to minimum


When I do that then my FPS drops from 18 to 9 !

all shaders to max, without ALS: 20 fps

looking to the ground: 50fps
looking at the sky: > 100fps

but as soon as the horizon comes into view: around 20fps with the UFO

how can I set the "Level of Detail" so that it does not render far away stuff ?
Do I have to restart FG after changing those ranges(detailed, rough, bare)
I do not notice any change after changing values and pressing the buttons in that dialog.

can --visibility help ?
pommesschranke
 
Posts: 1104
Joined: Sat Apr 27, 2013 7:58 pm
Location: EDLM & LJCE
Callsign: d-laser
IRC name: laserman
Version: git
OS: Linux Lubuntu 18.04

Re: How to tell if you are CPU or GPU limited (split)

Postby wkitty42 » Sat Oct 24, 2015 3:09 pm

pommesschranke wrote in Sat Oct 24, 2015 8:22 am:how can I set the "Level of Detail" so that it does not render far away stuff ?

in the sim, F10 menu->View->adjust_LOD_ranges

i have...
Code: Select all
          Detailed    Rough    Bare
Scenery       8000    24000   48000

IF i read this correctly, i start seeing details at 8000 meters from the object(s), rough details from 8000 up to 24000 meters and bare details from 24000 up to 48000 meters... anything further out than 48000 meters is "fog"...

i've tried to set mine to give me more details further out... just the opposite of what you seem to be looking for... i forget what the defaults are but they are definitely lower than my current settings above...
"You get more air close to the ground," said Angalo. "I read that in a book. You get lots of air low down, and not much when you go up."
"Why not?" said Gurder.
"Dunno. It's frightened of heights, I guess."
User avatar
wkitty42
 
Posts: 5760
Joined: Fri Feb 20, 2015 3:46 pm
Location: central NC, USA
Callsign: wk42
Version: git next
OS: Kubuntu 14.04.5

Re: How to tell if you are CPU or GPU limited (split)

Postby clrCoda » Sun Oct 25, 2015 5:07 am

Defaults are 1500, 9000, and 30000, from memory if I'm not mistaken.
Ray St. Marie
clrCoda
 
Posts: 1228
Joined: Wed Apr 07, 2010 11:04 am

Re: How to tell if you are CPU or GPU limited (split)

Postby Bug Bunny » Sun Oct 25, 2015 9:09 pm

OK, I've did some tests using FRAPS, but without testing NASAL case (I don't know this stuff), so...

Core i3-2120 3.3GHz / ATI Radeon HD 6870 1GB / 8GB Ram / Catalyst 15.7.1 / Win 7 SP1 64 bit / FG 3.6.0 RC (dl today)
UFO at UKON on runway (few feets above ground looking to the horizon), noon, clear sky with small distant fog, vsync is off in driver, AF off, AA off
ALS OFF/min custom shaders - 152 FPS
ALS OFF/max - 153 FPS

ALS ON/min - 176 FPS
ALS ON/max - 150 FPS

ALS ON/max/3000ft/look to horizon - 153 FPS
ALS ON/max/3000ft/look to ground - 197 FPS

Looking up into the sky in all cases increases FPS +40-50% (from 200 to 300) :)

NOTE: don't expect it that high inside in Cessna :), I have ~78FPS inside on ALS on/max settings with a default view in cockpit just after FG start. Also, in all tests Particles, Precipitation and 3D clouds were enabled.
ALSO: I've noted pretty smooth FPS variations when idle, like +/- 10 FPS (with in few seconds, smooth one, no problems really, interesting why? scene was the same, must be some background calculations :))
Bug Bunny
 
Posts: 41
Joined: Tue Feb 24, 2015 4:00 pm
Location: Ukraine
Version: 3.6.0RC
OS: Windows 7

Re: How to tell if you are CPU or GPU limited (split)

Postby legoboyvdlp » Mon Oct 26, 2015 1:53 pm

Waittt.... 300? Expect me to come to your house and kidnap your computer!
Joking, obviously :D
Nice results.
User avatar
legoboyvdlp
 
Posts: 7167
Joined: Sat Jul 26, 2014 1:28 am
Callsign: YV-LEGO
Version: 2018.3.1
OS: Windows 10 HP

Re: How to tell if you are CPU or GPU limited (split)

Postby Bug Bunny » Mon Oct 26, 2015 6:40 pm

Note, that there are no mountains, few forests (it is savanna like), not that much buildings (city nearby), big river, nice runway and no clouds :)
Bug Bunny
 
Posts: 41
Joined: Tue Feb 24, 2015 4:00 pm
Location: Ukraine
Version: 3.6.0RC
OS: Windows 7

Previous

Return to Graphics

Who is online

Users browsing this forum: No registered users and 1 guest