Board index FlightGear Support Graphics

CPU vs GPU Bound (split from other topic)

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.

CPU vs GPU Bound (split from other topic)

Postby V12 » Sat May 23, 2020 4:44 am

Half year ago I upgraded my old i5-2550K with GTX750 to R7 3700X and GTX1060. Performance gain over extremly dense OSM scenery is very low.
Then I tested i7-9700K oc to 5 GHz, result was bit better. I was very curious, when I got i3-9100K, results was very similar to R7 3700X. But in P3D was results very different, i7 @5GHz was significant faster than my R7 @4.2 GHz, i3 was too weak for serious flying with PMDG 737 or FSL A320.
Fly high, fly fast - fly Concorde !
User avatar
V12
 
Posts: 2042
Joined: Thu Jan 12, 2017 4:27 pm
Location: LZIB
Callsign: BAWV12

Re: FG using 90%+ on 3600X, GTX1060, 64GB RAM... ? Multicco

Postby stuart » Sat May 23, 2020 8:56 am

It’s off-topic, but it’s generally considered that the old FS-X core that P3D uses is CPU bound. FlightGear is generally GPU bound.
G-MWLX
User avatar
stuart
Moderator
 
Posts: 1603
Joined: Wed Nov 29, 2006 9:56 am
Location: Edinburgh
Callsign: G-MWLX

Re: FG using 90%+ on 3600X, GTX1060, 64GB RAM... ? Multicco

Postby Icecode GL » Sat May 23, 2020 9:56 am

The CPU load is low in the fgfs thread and almX ost zero in the other threads. There is a ton of RAM available. I wonder why it stutters ? GPU card running out of memory and having to swap ?


You have to consider that the CPU "feeds" the GPU every frame, i.e. the GPU won't work by itself. As soon as one frame takes longer that usual, the GPU is gonna be left hanging and waiting for something to do. What I mean is that there has to be a conscious effort by the developers to have 100% uptime on both the CPU and the GPU, it's not something trivial that happens automatically. Unfortunately FG is not very good at this (mostly because of its underlying rendering engine, OSG).

FlightGear is generally GPU bound.


Assuming a semi-decent discrete GPU (something like a nvidia gtx 660 from 8 years ago), FG is CPU (single-core) bound. The GPU is mostly idle all the time waiting for the next frame draw calls.
Icecode GL
 
Posts: 633
Joined: Thu Aug 12, 2010 12:17 pm
Location: Spain
Callsign: icecode
Version: GIT
OS: Fedora

Re: FG using 90%+ on 3600X, GTX1060, 64GB RAM... ? Multicco

Postby Hooray » Sat May 23, 2020 10:15 am

Icecode GL wrote in Sat May 23, 2020 9:56 am:Unfortunately FG is not very good at this (mostly because of its underlying rendering engine, OSG).



To be fair though, both fgviewer and standalone osgviewer are much better at providing good, and consistent, frame rates/performance that fgfs is.
Mathias has repeatedly pointed out that the FlightGear code base still contains so much legacy code that it isn't very good at leveraging OSG fully, and properly.

Thus, there is still quite a bit of optimization potential left in OSG space, even without having to migrate to a different scene graph (say Vulcan). Implying the opposite is ignoring the fact that FlightGear's code base is pretty archaic and that its rendering architecture is particularly outdated, i.e. only just in the process of being significantly updated - most thanks to Mathias' original OSG port (which never got completed), Tim's effects/cameragroup work and most recently, thanks to your ongoing compositor work.

But even with these features/systems in place, there still remains a large share of legacy code that cannot be considered to be compatible with modern OSG, i.e. all the stuff using raw/fixed-function GL code.

OpenSceneGraph is much better at leveraging modern hardware than FlightGear is, suggesting that FlightGear's performance challenges are due to OSG would be deluding ourselves :lol:
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: 11971
Joined: Tue Mar 25, 2008 8:40 am

Re: FG using 90%+ on 3600X, GTX1060, 64GB RAM... ? Multicco

Postby Icecode GL » Sat May 23, 2020 10:23 am

OpenSceneGraph is much better at leveraging modern hardware than FlightGear is


Personally I don't think that's the case. Poor support for async compute, fixed multithreaded scheme whose performance depends entirely on the distribution of cull and draw times, reliance on the OpenGL compatibility profile, no support for command buffers, several core features that completely rely on hardcoded shaders, no default material system outside legacy GL ambient/diffuse/specular etc. etc.

Don't get me wrong, OSG is not that bad for a 20+ year old library, it's just that the real time rendering paradigm has changed a lot since the 00s. FG indeed has a lot of legacy stuff to deal with, but it doesn't help that the entire base for the simulator has its issues as well. Most FG performance-related problems can't be solved trivially because OSG is not flexible enough to allow trivial fixing. And again, this is not OSG's fault, it was just made on a different time when different things were a priority.

i.e. all the stuff using raw/fixed-function GL code.


Apart from PUI and the HUD I can't remember any other pieces of technology that rely on direct GL calls anymore.
Icecode GL
 
Posts: 633
Joined: Thu Aug 12, 2010 12:17 pm
Location: Spain
Callsign: icecode
Version: GIT
OS: Fedora

Re: FG using 90%+ on 3600X, GTX1060, 64GB RAM... ? Multicco

Postby Hooray » Sat May 23, 2020 10:50 am

See: 2D panels, any hard-coded od_gauge based instruments (agradar, wxradar, navdisplay), also we've added our own hard-coded PUI widgets (think map-widget)
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: 11971
Joined: Tue Mar 25, 2008 8:40 am

Re: FG using 90%+ on 3600X, GTX1060, 64GB RAM... ? Multicco

Postby Icecode GL » Sat May 23, 2020 10:52 am

Well I don't think those are exactly holding FG back in terms of progress. :)
Icecode GL
 
Posts: 633
Joined: Thu Aug 12, 2010 12:17 pm
Location: Spain
Callsign: icecode
Version: GIT
OS: Fedora

Re: FG using 90%+ on 3600X, GTX1060, 64GB RAM... ? Multicco

Postby Hooray » Sat May 23, 2020 11:20 am

Over the years, one of the most cited reasons for holding back FlightGear vs migrating/adopting OSG fully was actually lack of PagedLOD adoption (which I do realize is no longer the case), but also migrating to a CompositeViewer based renderer (which I do know you are aware of due to your previous work involving a custom Canvas view element, porting/generalizing the view manager, and your comments in the context of migrating the CameraGroup infrastructure for work with the Compositor)

But like you're alluding to, as long as a legacy feature is optional and not automatically running in the main loop, it's probably a no-brainer.

With the ongoing adoption of the compositor based approach, and some additional hooks/integration with effects/shaders + canvas, it's increasingly likely that this will have a massive impact on other rendering features, e.g. all the autogen stuff (think PixelCity) we've been talking about for years, could all of a sudden be implemented by fgdata contributors, simply by using a combination of XML, effects, shaders and some Nasal/Canvas adapters.

Also, we've seen so many attempts at coming with a new/improved scenery/terrain LOD scheme, as well as ideas to support other planets (the sky no longer is the limit ... :lol: )

Which is to say, there still is quite a bit of leeway to be had just by making existing legacy functionality optional, and going with OSG for quite some time.

Of course, it depends on your goals - but as long as osgviewer/fgviewer can provide significantly better performance when rendering a 3D model/terrain mesh, there is also optimization potential left, even without adopting a totally novel scene graph implenentation.

That being said, in the aftermath of the OSG migration (~2006) Mathias has actually been promoting encapsulating OSG specifics, which is something that he repeatedly discussed with other senior contributors like Tim, who didn't quite see his point at the time - but Mathias was definitely foreseeing the need to eventually migrate again, and didn't want to have to deal with another plate of spaghetti code :wink:

https://www.mail-archive.com/flightgear ... 22638.html
Tim Moore wrote:
Mathias Fröhlich wrote:from my point of view. I would prefer to have these.
The reason is to have something self contained here.
Sure we already rely on osg at many places. But if I build an aplication on
simgear, I hope to have simgear classes there. SGProperties are simgear
classes, and if you use the property system you may not want to rely on osg.


... also from my past experience switching to an other scenegraph, I would
prefer to see no osg::.. references at all in flightgear - except some few
viewer related stuff. But the simulation part of FlightGear should not need to
know that the viewer runs on osg/OpenGL.
So looking at SimGear as a utility library for simulation applications, this
make sense from my point of view ...

So, even if you will need some more glue code, I would prefer to avoid osg
classes in simgears parts that are not scenegraph related.


Seriously, I didn't realize that reducing dependencies on OSG in simgear is a
design goal. That's fine, but I would really prefer to not think about whether
I need to pass an SGVec3d or an osg::Vec3d to a function, or whether a smart
pointer should be an osg::ref_ptr or an SGSharedPtr or...

Tim


And since you're currently in the process of establishing the future of FlightGear's rendering architecture, maybe some food for thought for you ? :wink:
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: 11971
Joined: Tue Mar 25, 2008 8:40 am

Re: FG using 90%+ on 3600X, GTX1060, 64GB RAM... ? Multicco

Postby V12 » Sat May 23, 2020 4:58 pm

stuart wrote in Sat May 23, 2020 8:56 am:FlightGear is generally GPU bound.

Sorry Stuart, it is not :
Image
You can see 13 fps, GPU load 27%, VRAM usage 16%, RAM load 5.2GB of 32GB, CPU load 6.35% - exactly 1 of 16 core usage with threading model CullThreadPerCameraDrawThreadPerContext
If the software is GPU bound, then GPU load should be almost 100% and CPU load very low, because CPU will wait for GPU.

P3D v4.5 with night scenery and active dynamic lighting is GPU bound, this combination can kill RTX2080 :twisted: LockheedMartin should do something with this feature...
Fly high, fly fast - fly Concorde !
User avatar
V12
 
Posts: 2042
Joined: Thu Jan 12, 2017 4:27 pm
Location: LZIB
Callsign: BAWV12

Re: FG using 90%+ on 3600X, GTX1060, 64GB RAM... ? Multicco

Postby Hooray » Sat May 23, 2020 5:26 pm

FWIW, for a number of years, the key folks in the rendering department have posted the following suggesting that on many systems, FlightGear is indeed CPU bound (obviously that may not apply to power users/contributors with dedicated gaming rigs at their disposal):

https://sourceforge.net/p/flightgear/ma ... /34811078/
TorstenD (2016) wrote:I can add two observation that I find somewhat interesting.
I just recently got a new laptop with an i7/8GB and a gtx960/4GB.
It is able to run flightgear at 1920x1080 at 30-40fps when flying around
KSFO with the c172p, ALS, all shaders max, everything else default settings.
As it is single-screen/single-camera, I see one thread running at 100% and
in nVidia-settings, I see the GPU core at 50% utilization.
Clearly CPU limited and somewhat exptected.


https://sourceforge.net/p/flightgear/ma ... /29727298/
FredB (2012) wrote:Tim and Mathias already said that we are CPU bound and I can confirm by experience.


https://sourceforge.net/p/flightgear/ma ... /29571614/
Mathias (2012) wrote:
Tim Moore wrote:The depth-pass-only pass is a well known optimization, but the fact it
is not helping implies that our bottleneck is not in fragment
processing. I've suspected for years that it lies on the CPU, and have
been trying to optimize our scene graph a bit...

It *is* on the cpu.
At least for most of the use cases. Every now and then there is an other limit
that comes up for specific stuff. But we are *mostly* draw limited. The draws
are way too small to be efficient.
James and I were talking about this some time ago.
I would go even further for the LOD's. In the meantime I have in fgviewer a
PagedLOD whole world database tree running. This is similar to osg's marble
dataset but carefully designed around our tile structure. Using this I think
we can really replace a lot of our fine structured scenery tiles with something
more croase that is used for tiles more far away.
Drawback with our current codebase: Our integration of the particle systems
need to be rethought as this contains geometry with culling disabled which
makes a pagedlod just never expire. Switching the particle systems off works
pretty good so far.


https://www.mail-archive.com/flightgear ... 35917.html
Mathias (2012) wrote:Currently OpenGL wise we are basically geometry setup bound - at least for the
models. This really means that vertices are not an issue.
That still means that for setting up that one draw with 3 triangles is about
as heavy as setting up say 500 triangles, but the conclusion of this is *not*
that you should schedule as many triangles ass possible.
The right conclusion is to collapse as many triangles as *sensible* for
culling into a single draw.

A simple help is to switch on the onscreen stats in the viewer or flightgear
and see if the yellow bar is longer than the orange one. A yellow bar longer
than the orange one means that the cpu is not able to saturate the gpu.
Again, beware this does in no way mean that you should write complicated
shaders to saturate the gpu! This rather means that the geometry setup/state
change time - the yellow one - must decrease!

[...]

Once your orange bar is longer than the yellow one, you can start to care for
the shaders and their execution.
When thinking about shaders, keep in mind that different GPU's perform very
different on the same shader.

Appart from OpenGL we spend a lot of time in scenegraph traversal. This is
mostly due to plenty of structural and often needless nodes in the scenegraph.
The reason or this is that historically the xml files did some implicit
grouping for *every* animation in the xml file. To make that reilably work I
had to introduce a huge amount of group nodes in the xml file loader. These
really hurt today as they introduce a whole lot of group nodes that just have
a single child which need to be traversed for update and for cull. Profiling
shows that Group::traverse is the most used function in flightgear.
The lowest hanging fruit could be to optimize away the redundant nodes from
the top level model that gets loaded by a database pager request. We cannot do
that recursively once a model part is loaded since the mentioned grouping
nodes might be referenced in any level in the model hierarchy above the
currently loaded model. So only the top level model could do this without
braking tons of models.

And regarding all that, even if your box already is gpu bound this does not
mean that other driver/hardware combinations are gpu bound too.

Always: As much as needed and as few as possible.

Ok, there are plenty of other aspects of performance tuning a scene graph, but
these are the ones I think are most important for flightgear as of today.


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: 11971
Joined: Tue Mar 25, 2008 8:40 am

Re: FG using 90%+ on 3600X, GTX1060, 64GB RAM... ? Multicco

Postby wkitty42 » Sat May 23, 2020 6:53 pm

V12 wrote in Sat May 23, 2020 4:58 pm:
stuart wrote in Sat May 23, 2020 8:56 am:FlightGear is generally GPU bound.

Sorry Stuart, it is not :

he said "generally" ;)

your's isn't GPU bound because you have that monster GPU card in place... others of us are not so lucky and FG is GPU bound trying to render what the CPU is shoveling at it... especially on systems with fast CPUs and weak GPUs...
"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: 6662
Joined: Fri Feb 20, 2015 3:46 pm
Location: central NC, USA
Callsign: wk42
Version: git next
OS: Kubuntu 20.04

Re: FG using 90%+ on 3600X, GTX1060, 64GB RAM... ? Multicco

Postby Hooray » Sat May 23, 2020 7:22 pm

this kind of statement simply cannot be made without also taking into account a plethora of factors - that is one of the reasons, why it would definitely make sense to work out a way to create a suite of benchmarks, i.e. by taking certain aircraft (with different complexity) and fly/replay certain patterns (fgtape) while tinkering with different startup/runtime settings, otherwise conclusive statements simply cannot be made reliably.

In a perfect world, we'd have the equivalent of $FG_ROOT/Benchmarks to keep fgtapes provided by the community using different aircraft - and then we'd only need a way to apply different scenery/environmental settings at run time to replay those flights and see how FG performs (in fact, fgtapes could probably be configured to also apply many rendering/environmental settings automatically).

In conjunctions with Erik's GPU profiles, a number of meaningful conclusions could be drawn (over time).
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: 11971
Joined: Tue Mar 25, 2008 8:40 am

Re: FG using 90%+ on 3600X, GTX1060, 64GB RAM... ? Multicco

Postby V12 » Sat May 23, 2020 8:27 pm

GTX1060 is not monster. What is RTX2080 ?
I had similar results on my previous machine with GTX750.
Fly high, fly fast - fly Concorde !
User avatar
V12
 
Posts: 2042
Joined: Thu Jan 12, 2017 4:27 pm
Location: LZIB
Callsign: BAWV12

Re: FG using 90%+ on 3600X, GTX1060, 64GB RAM... ? Multicco

Postby Icecode GL » Sat May 23, 2020 8:47 pm

your's isn't GPU bound because you have that monster GPU card in place... others of us are not so lucky and FG is GPU bound trying to render what the CPU is shoveling at it... especially on systems with fast CPUs and weak GPUs...


You have to consider that FG is an intensive 3D application, not a web browser, so it is assumed that you are trying to run FG on appropiate hardware for running 3D applications.
Icecode GL
 
Posts: 633
Joined: Thu Aug 12, 2010 12:17 pm
Location: Spain
Callsign: icecode
Version: GIT
OS: Fedora

Re: FG using 90%+ on 3600X, GTX1060, 64GB RAM... ? Multicco

Postby Hooray » Sat May 23, 2020 9:29 pm

These days, web browsers actually support Web GL, with web assembly being the next huge thing just around the corner ;-)

https://get.webgl.org/
https://webassembly.org/
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: 11971
Joined: Tue Mar 25, 2008 8:40 am

Next

Return to Graphics

Who is online

Users browsing this forum: No registered users and 0 guests