Howto:Using additional OSG Pager Threads: Difference between revisions

From FlightGear wiki
Jump to navigation Jump to search
m (https://forum.flightgear.org/viewtopic.php?f=24&t=37767&p=371779&hilit=pager+threads#p371779)
m (https://sourceforge.net/p/flightgear/mailman/message/37754850/)
 
(11 intermediate revisions by 3 users not shown)
Line 1: Line 1:
{{Multithreading Navbar}}
{{Main article|Multi-Threading in FlightGear}}
{{Stub}}
{{Stub}}


you can configure OSG to use additional pager threads, which basically means the terrain cache gets additional CPUs it can use.
You can speed up scenery loading times by configuring OSG to use additional pager threads, which basically means the terrain cache gets additional CPU cores it can use.
 
See the OSG docs. To use additional threads just configure the following [[Environment variables|environment variable]] setting: <code>OSG_NUM_DATABASE_THREADS</code>. For a 4 core system try setting this to 2 or 3 or higher. For a 6-8 core CPU try increasing further to use extra cores. Try reloading scenery via the debug menu to see benefits - look at the CPU utilisation.
 
Stuart spent a bit of time digging into the OSG DatabasePager as part of the WS3.0 work. It's all a bit complicated, and our  behaviour has changed
since 2020.3:
 
The OSG_NUM_DATABASE_THREADS and OSG_NUM_HTTP_DATABASE_THREADS
environmental can be used to set the number of threads used to load
objects, scenery etc.  The first is the total number of threads, and the
latter is the subset of those threads that are used for HTTP.  (I agree
that's not at all obvious - see OSG osgDB/DatabasePager.cxx line 1209).That said, neither of the variables are relevant on next because FG
explicitly sets the number of threads in fg_init (I haven't checked
2020.3). I recently added code to next to support using
/sim/rendering/database-pager/threads to set the number of threads.  Note
that this is again the total threads, and one of those will we still set up
a single HTTP thread.  I suspect we should simply set the number of HTTP
threads to 0, as we don't use them.<ref>https://sourceforge.net/p/flightgear/mailman/message/37754850/</ref>
 
{{Main article|CompositeViewer_support#DatabasePager}}
 
This has the potential to speed up loading of scenery like [[OSM2City]]. People on the forum have reported instability. This will ''not increase FPS'', merely improve loading times - which will only be visible in areas with a lot of scenery objects.
 
Note that according to findings shared by Richard, when testing the database pager extensively (running with 20 DB pager threads), the main problem is the way that random objects (buildings, vegetation) are inserted into the scene graph doesn't seem to be compatible with lots of pager threads<ref>https://forum.flightgear.org/viewtopic.php?f=17&t=38094&hilit=pager+threads&start=15#p374620</ref>
== References ==
{{Appendix}}
 
[[Category:Multicore]]
[[Category:Environment variables]]

Latest revision as of 18:14, 30 December 2022

1rightarrow.png See Multi-Threading in FlightGear for the main article about this subject.

This article is a stub. You can help the wiki by expanding it.

You can speed up scenery loading times by configuring OSG to use additional pager threads, which basically means the terrain cache gets additional CPU cores it can use.

See the OSG docs. To use additional threads just configure the following environment variable setting: OSG_NUM_DATABASE_THREADS. For a 4 core system try setting this to 2 or 3 or higher. For a 6-8 core CPU try increasing further to use extra cores. Try reloading scenery via the debug menu to see benefits - look at the CPU utilisation.

Stuart spent a bit of time digging into the OSG DatabasePager as part of the WS3.0 work. It's all a bit complicated, and our behaviour has changed since 2020.3:

The OSG_NUM_DATABASE_THREADS and OSG_NUM_HTTP_DATABASE_THREADS environmental can be used to set the number of threads used to load objects, scenery etc. The first is the total number of threads, and the latter is the subset of those threads that are used for HTTP. (I agree that's not at all obvious - see OSG osgDB/DatabasePager.cxx line 1209).That said, neither of the variables are relevant on next because FG explicitly sets the number of threads in fg_init (I haven't checked 2020.3). I recently added code to next to support using /sim/rendering/database-pager/threads to set the number of threads. Note that this is again the total threads, and one of those will we still set up a single HTTP thread. I suspect we should simply set the number of HTTP threads to 0, as we don't use them.[1]

1rightarrow.png See CompositeViewer_support#DatabasePager for the main article about this subject.

This has the potential to speed up loading of scenery like OSM2City. People on the forum have reported instability. This will not increase FPS, merely improve loading times - which will only be visible in areas with a lot of scenery objects.

Note that according to findings shared by Richard, when testing the database pager extensively (running with 20 DB pager threads), the main problem is the way that random objects (buildings, vegetation) are inserted into the scene graph doesn't seem to be compatible with lots of pager threads[2]

References

References