Board index FlightGear Development

questions about performance with openscenegraph

FlightGear is opensource, so you can be the developer. In the need for help on anything? We are here to help you.
Forum rules
Core development is discussed on the official FlightGear-Devel development mailing list.

Bugs can be reported in the bug tracker.

questions about performance with openscenegraph

Postby cain071546 » Thu Sep 04, 2014 6:55 pm

I am seeing a very noticeable difference in frame rate with openscenegraph 3.2-3.3 as apposed to my install of 3.0

I am compiling flightgear 3.3 against OSG 3.2 and 3.3

i am seeing Frames rates of about %50 of what i see in 3.0 uniformally Everywhere

i have read a few posts regarding low frame rate with OSG 3x ,there are posts on OSGs forum as well

there seems to be a known issue with OSG 3x and a performance drop for people

best thread i found -------- http://forum.openscenegraph.org/viewtopic.php?t=13059

http://marc.info/?l=flightgear-devel&m=122757257104245

i am using the Ubuntu/Debian script

https://www.gitorious.org/fg/fgmeta/raw ... compile.sh

the script allready has CMAKE_BUILD_TYPE=Release

it is allready in the script so its not a issue with debugging symbols

so i will just drop some questions here at the end

should i just wait for the actuall 3.2 release to drop?

has anyone had any luck improving performance with OSG 3x?

are there any differences beetween OSG 3.0 and 3.2 that would prevent me from compiling FG 3.2 or 3.3 against OSG 3.0?

is this only a issue with the copy of OSG i am compiling? will a pre-packaged binary have better performance?
two wrongs never made a right but two wrights made a airplane
cain071546
 
Posts: 111
Joined: Wed Sep 29, 2010 10:55 pm
Location: Washington USA
Callsign: cain
IRC name: cain
Version: 3.2
OS: Linux

Re: questions about performance with openscenegraph

Postby Hooray » Thu Sep 04, 2014 7:19 pm

Hi & welcome !

I think we've seen a handful of postings confirming this - if you're able to build from source and don't mind using development looks like the built-in profiler, it would be interesting to see comparison of both builds - ideally using a simple test case with everything else disabled - you could use a pre-recorded flight and/or a flight recorder type to come up with a "test flight". From our standpoint, it would help tremendously if all features that don't seem to have an effect could be completely disabled, including complex aircraft and scenery/locations. In other words, if you can reproduce the problem using "bare" minimum settings, the resulting log file will be much easier to process.

There's a built-in profiler which you can use to create these profiles: http://wiki.flightgear.org/Built-in_Profiler
You would then want to use two different build directories, where SG/FG build settings would be identical, but using an older version of OSG: http://wiki.flightgear.org/Building_usi ... irectories

For the sake of simplicity there's a so called "minimal startup profile" that you can use: http://wiki.flightgear.org/Howto:Debugg ... up_profile
While unlikely, it would be great if the issue could be reproduced that way - but more likely than not, you'll have to re-add a few features and change a few settings, e.g. by using a different location.

Like I said, you could then use the replay system to create an test flight than can be easily reproduced - to get going more quickly, you can also use the built-in route manager to create a simple flight plan and fly the whole thing on autopilot: http://wiki.flightgear.org/Instant_Replay

You can use time warp mode to speed up simulation time and finish more quickly.

Admittedly, all this may seem a bit intimidating and tedious, but once you have such a setup working, you can reuse it over and over again for different startup profiles and provide profiling logs for each.
We do have a number of people interested in adding features to support benchmarking/profiling workflows natively:

http://wiki.flightgear.org/FlightGear_Benchmark
http://wiki.flightgear.org/Testing

If that's something you'd like to pursue, feel free to get in touch - it is definitely a worthwhile thing, even regardless of any OSG specific issues, as it will also help with unrelated performance issues.
Obviously, there's a bit of a steep learning curve involved, which is why it's normally only core developers that build multiple versions against different OSG versions and run the profiler.
But once you are able to build from source, you have already completed the most difficult step - everything else is fairly straightforward in comparison - as as you can probably tell, creating test flights using the route manager and/or flight recorder also isn't exactly rocket science.

However, before you do anything, I'd suggest to check first if you've possibly changed your driver, or if you can install a newer version:
Subject: OSG 3.0.1 -> 3.2.0 cuts frame rate in half

tikibar wrote:Hi Everyone,
I'm wondering if anyone has any suggestions on how to improve performance with OpenSceneGraph 3.2. I built (from source) 2 instances of FG 3.0.1, one built against OSG 3.0.1 and one with OSG 3.2.0. With OSG 3.0.1, I was getting decent frame rates (~30 fps / under 50 ms). Using the FG build with OSG 3.2, the frame rate went down to around 15 fps and best spacing was ~75 ms. All the other settings (ALS, shader levels, real weather on, aircraft) were identical. The only difference was the OSG version.

For the record:
OS Ubuntu 10.04 64bit
FG 3.0.1
nVidia GTX 550
Problem tested with 747-8i/F, 757-200 (newer git version), and 777-300ER.
In both cases, console warning to upgrade my graphics driver from 290 to 300.

I get the same frame rate problem in FG-git, since OSG 3.2 is now required.

Cheers,
tikibar

Edit: I went ahead and upgraded the driver to 304. Performance with OSG 3.0.1 is even a little better now. OSG 3.2.0 frame rate/spacing is unchanged at best, and maybe a little worse.

Edit2: Fixed it. After upgrading the nVidia driver, I had to rebuild OSG 3.2.0 from source, then rebuild SimGear and FlightGear. Now getting acceptable frame rates in FG 3.0.1 and FG-git. Carry on.
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: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: questions about performance with openscenegraph

Postby Philosopher » Thu Sep 04, 2014 9:33 pm

If you're truly running latest Git (like 2-3 days old), then yes – Torsten was working on a crash that was happening, so he pushed something that seemed to fix the crash, but resulted in worse performance, to see if it worked for others.
Philosopher
 
Posts: 1593
Joined: Sun Aug 12, 2012 7:29 pm

Re: questions about performance with openscenegraph

Postby cain071546 » Thu Sep 04, 2014 9:56 pm

Philosopher wrote in Thu Sep 04, 2014 9:33 pm:If you're truly running latest Git (like 2-3 days old), then yes – Torsten was working on a crash that was happening, so he pushed something that seemed to fix the crash, but resulted in worse performance, to see if it worked for others.


yes i compiled it on Tuesday this week

i have been expirementing between the Open-source ATI driver and the proprietary FGLRX driver
the results are startling

let me expand a little

I usually use the Open-source driver for 2 reasons

1) I get better frame rates with FG 3.0.0
2) i dont have issues with rendered TEXT ie, menus,windows,dialogues

now i have been paying attention to CPU usage and by default (when everything is running the best)
flightgear pegs 1 of my 4 cores out and leaves the other 3 idle (frames 20-60+ depending on local)
runs reasonable i get the occasional crash or freeze depending on what im doing and how long its been running but not too bad

now i have added the command arguement

/sim/rendering/multithreading-mode=DrawThreadPerContext

i get much better CPU utilization 3 cores at 20-30% and 1 at 70-80% (but lower frame rates) but over all better system stabillity, i can reload the terrain on the fly without any real slow down and so on

so for the sake of laughs i reinstalled the the FGLRX driver and now my frames are great
but the cpu usage is now slightly higher much more erratic with some cores maxing out

but im back to the flickering text =(

so now im confused

is this a OSG issue? a patch issue? or a driver issue?

and why would the driver have such an impact on the CPU utilization?

flightgear is weird sometimes...
two wrongs never made a right but two wrights made a airplane
cain071546
 
Posts: 111
Joined: Wed Sep 29, 2010 10:55 pm
Location: Washington USA
Callsign: cain
IRC name: cain
Version: 3.2
OS: Linux

Re: questions about performance with openscenegraph

Postby Hooray » Thu Sep 04, 2014 10:58 pm

it is up to the driver to decide which part of the workload is sent to the CPU or the GPU at any given time - this is how libMESA (software/CPU-driven GL) works.

Likewise, certain parts of the workload can be more easily parallelized or even prepared by the CPU while the GPU is busy.
The driver will typically try to keep the GPU busy, which may involve additional work for the CPU.

OSG itself can make use of so called worker threads to prepare data asynchronously, and only serialize things if necessary (=synchronize certain CPU/GPU state).

Thus, it is very well possible that different driver/GPU combinations may work differently for you and provide varying performance.

FlightGear itself doesn't make very much use of OSG's support for threading (background jobs), and like you've found out, certain flags need to be set to tell OSG to "try" to do things in parallel. But overall, OpenGL rendering (and thus OSG rendering) is perdominantly single-threaded. The only thing that can be done by applications like FlightGear is to use OSG infrastructure (coding patterns) that can internally be parallelized by OSG.

These OSG "coding patterns" are typically based on standard design patterns that are mapped onto OpenThreads to parallelize rendering related tasks.
Basically, as long as the proper coding patterns are used, OSG is smart enough to split up the workload for each frame and use different threads whenever possible and keep the GPU saturated.
Whenever that is not possible, everything will be done in the main thread, which means that latencies will become worse and framerate lower.

But rendering itself is still happening in a single thread usually:

https://www.packtpub.com/books/content/ ... scenegraph
Understanding multithreaded rendering
The traditional method of real-time rendering always involves three separate phases: user updating (UPDATE), scene culling (CULL), and executing OpenGL calls (DRAW).

User updating include all kinds of dynamic data modifications and operations, like changing the scene graph hierarchy, loading files, animating mesh vertices, and updating camera positions and attitudes. It then sends the scene graph to the culling phase, within which the scene is rebuilt, for the purpose of improving final rendering performance. Objects that are invisible in the viewing frustum or hidden for any reason will be removed, and the rest are sorted by rendering states and pushed into a drawing list. The list will be traversed in the final, drawing phase, and all OpenGL commands will be issued to the graphics pipeline for processing.

A single processor system would need to process all three phases serially, which may cause the one frame to be too long to fit user requirements.

In a system with multiple processors and multiple display devices, we can have more parallelizable CULL and DRAW tasks to speed up the frame rate. Especially when managing more than one rendering windows, it is necessary to have a new threading model with one CULL and one DRAW phase for each window, and execute them concurrently. This is, of course, more efficient than just using a single thread.


Much of the code comprising the FlightGear rendering pipeline was ported from PLIB/SG and hasn't been updated in years - thus, isn't yet necessarily using the right/best OSG coding patterns or protocols - which is why applications like fgviewer (or osgviewer) will typically perform better than fgfs. In addition, there's a ton of code running in the FG main loop that is adding to mainloop slowness despite not belonging into the rendering/main thread, which is why a few core developers have been working towards moving non-rendering related code out of the main loop into worker threads, and eventually also into HLA federates. "fgviewer" is all about coming up with a lightweight viewer component that doesn't run any non-rendering related subsystems at all.
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: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: questions about performance with openscenegraph

Postby cain071546 » Thu Sep 04, 2014 11:30 pm

Thank you for your highly informative answers, the more i read on the wiki the more i realize im in over my head kinda David and Goliath style
but i will try learn, The Wiki has been very helpful and i will continue read through it.

http://wiki.flightgear.org/Howto:Improve_framerates
has been insightful as well

There is alot of work to be done i don't know how you guys/gals keep up ...
Again thank you i will continue to tinker if i need anything else i will create a new topic
two wrongs never made a right but two wrights made a airplane
cain071546
 
Posts: 111
Joined: Wed Sep 29, 2010 10:55 pm
Location: Washington USA
Callsign: cain
IRC name: cain
Version: 3.2
OS: Linux


Return to Development

Who is online

Users browsing this forum: No registered users and 12 guests