Howto:Activate multi core and multi GPU support

From FlightGear wiki
Jump to navigation Jump to search

FlightGear supports a number of different threading modes to make use of multiple CPUs or GPUs, this applies mostly to high-end multi-core or multi-GPU, multi-screen (or multi-window) setups and may improve performance (see Howto: Configure camera view windows).

Note  In its current form, this section/article is largely based on quotes collected from various related discussions/channels (devel list, forum etc) using the Instant-Cquotes script. Wiki users and other contributors are encouraged to help rewrite/edit contents accordingly to help get rid of unnecessary quoting (i.e. while the wiki is not intended to be a collection of quotes, quotes are sometimes the best/easiest way to bootstrap new articles, while also providing a good way to link back to related discussions in the archives).

While rewriting usually only entails changing first person speech to 3rd person. However, please try to retain references/links to the original discussion whenever possible.

Selecting threading modes

Note  Beginning with FlightGear 3.0, you should be careful when changing the default OSG threading settings, as enabling multi-threading seems to be an increasingly reliable way to trigger race conditions/segfaults (crashes). Also see ticket #1393 and [1]
Cquote1.png the aforementioned threading related directives are only relevant at the OSG/rendering level, i.e. will only tell the underlying OpenSceneGraph implementation to try to do certain tasks "concurrently", for a more detailed explanation, please refer to: Howto:Use_the_system_monitor
— Hooray (Sun Feb 08). Re: Multiprocessor Support.
(powered by Instant-Cquotes)
Cquote1.png OSG threading support is largely specific to offloading rendering-related computations (i.e. culling) to different threads, it will NOT directly help conventional FlightGear subsystems runing in the main loop, not without explicit coding - i.e. multi-threading or multi-processing and IPC.
— Hooray (Thu Mar 15). Re: [SUGGESTION] Multi-core FlightGear support.
(powered by Instant-Cquotes)
Cquote1.png OSG threading is neat and dandy, but obviously it is only directly useful for rendering related parallelization and related work. On the other hand, none of this comes for free. OSG's threading support really is impressive, but all those OSG threads must be kept busy. Properly. That's exactly the work that FlightGear is responsible for in its main loop.

OSG's multithreading support doesn't just come "automagically", just because FlightGear uses OSG. The multithreading support in OSG must be explicitly supported by following certain OSG coding patterns and coding protocols. Otherwise, you won't benefit at all.
Obviously, OSG really is extremely powerful and also pretty good at parallelizing things, but you cannot necessarily see that when running FlightGear, but there is other OSG-based software which is making really good use of this.

— Hooray (Thu Mar 15). Re: [SUGGESTION] Multi-core FlightGear support.
(powered by Instant-Cquotes)
Cquote1.png Even distribution across the cores doesn't in itself indicate that a process is using multiple threads. The operating system will switch tasks between cores for even temperature distribution, even with a single-threaded program.

The indication that a program is multi-threaded is when the overall usage of the program goes above the capacity of one core. For that to happen it must have different threads running on different cores at the same time.

— sanhozay (Sun Feb 08). Re: Multiprocessor Support.
(powered by Instant-Cquotes)
Cquote1.png In my preferences.xml I have:
<multithreading-mode> AutomaticSelection </multithreading-mode>

With OSG2 this worked and I could see fgfs using CPU cycles on both CPU cores. This did increase frame rates compared to single threading but only by perhaps 25% on average but it also seemed to improve frames rates even more under condidtions that would result in lower frames rates. With OSG3 this does not happen and it appears to only be single threaded.

— Hal V. Engel (2011-07-10). [Flightgear-devel] OSG3 frame rates and multithreading.
(powered by Instant-Cquotes)
Cquote1.png I [used to be] able to run FlightGear with osg multithreading mode set to AutomaticSelection on my presentation machine with five graphic cards and ten monitors attached and a dozen or so cameras configured. For some reason, that is no longer possible and I get a core dump sooner or later.
— Torsten Dreyer (2014-03-29). [Flightgear-devel] osg multithreading crashes.
(powered by Instant-Cquotes)
Cquote1.png Only of 1 out of 10 sessions crashed, here is the only dump I was able to produce.
— Torsten Dreyer (2014-03-31). Re: [Flightgear-devel] osg multithreading crashes.
(powered by Instant-Cquotes)
Cquote1.png When I run FlightGear with multiple screens and multiple cameras, the highes threading mode for OpenSceneGraph that works reliable is CullDrawThreadPerContext while the CullThreadPerCameraDrawThreadPerContext quickly leads to a crash.

You can set the osg threading model upon startup with --prop:/sim/rendering/multithreading-mode=CullDrawThreadPerContext If it still does not work, try DrawThreadPerContext or even SingleThreaded and see if this helps.

Cquote1.png My sense is that most of our crashes seem to come from newer code or threading issues.
Cquote1.png --prop:/sim/rendering/multithreading-mode=CullThreadPerCameraDrawThreadPerContext never worked for me with multiscreen/multicamera setups. It always crashed within a few seconds. It's a known issue, It should not bite you with a single camera, but I would not bet on it.
Cquote1.png if you use the default screen configuration there is just one window and one camera. In that case, CullThreadPerCamera results in one thread (just one camera) and you effectively run as CullDrawThreadPerContext. You can configure more than one camera on a single screen an in that case the above will bite
— Torsten Dreyer (Feb 21st, 2016). Re: [Flightgear-devel] 2016.2.0 long-term testing.
(powered by Instant-Cquotes)

There is a property supported named /sim/rendering/multithreading-mode this can be set either in the preferences.xml file located in the flightgear data folder (base package: $FG_ROOT) or by using the --prop:/sim/rendering/multithreading-mode=... parameter from the console (or fgrun) this affects directly the osgviewer threading mode, supported values are:

   * AutomaticSelection
   * CullDrawThreadPerContext
   * DrawThreadPerContext
   * CullThreadPerCameraDrawThreadPerContext

Further information on threading modes can be found here: and here:

To set this in a separate XML file, just include it from preferences.xml (toplevel PropertyList node):


 <?xml version="1.0"?>

This property must be set during initialization, modifying it at runtime has no effect.

Multithreading modes allocate two instances of OpenGL resources to speed up rendering . Default implicit buffer attachment policy adds depth buffer to FBOs if only color buffer was attached.

if you have a single graphics card, having a thread per camera (each one with a graphics context) doesn't necessarily improve the performance, what is more, it can degrade it. The reason is that each thread will be competing for the graphics card, which is an exclusive resource, and the driver is forced to perform many context switchs. If you are using multiple graphics contexts then by default the OSG/OpenGL will be creating OpenGL objects (like textures) on a per context basis. So one osg::Texture in the scene graph even if it's rendered on two contexts you'll have two separate TextureObjects/OpenGL texture objects.

Related content