Experimental Multi-Threaded Viewer: Difference between revisions
(+stub) |
No edit summary |
||
| Line 8: | Line 8: | ||
The net result in terms for performance is there is a frame rate increase, but only by a small amount - the time that the simulation takes. For the F-15 this is currently around 5ms. Simpler models will benefit less, so if a model takes <=1ms there will not be a benefit from this technique.<ref>https://forum.flightgear.org/viewtopic.php?f=37&t=35661&hilit=&start=15#p351374</ref> | The net result in terms for performance is there is a frame rate increase, but only by a small amount - the time that the simulation takes. For the F-15 this is currently around 5ms. Simpler models will benefit less, so if a model takes <=1ms there will not be a benefit from this technique.<ref>https://forum.flightgear.org/viewtopic.php?f=37&t=35661&hilit=&start=15#p351374</ref> | ||
There are really two things that are important, firstly (and most importantly to Richard) is to avoid frame pauses[1], secondly the overall frame rate. Recent changes to the model loader (DDS texture cache) have reduced frame pauses but there are still things to improve. These two things are also referred to a system load and latency - and are equally important. | |||
For research purposes Richard managed to get the rendering to run in a separate thread to the main simulation loop- and this gives a small increase in performance - effectively the bit at the end of the OSGStats histogram - on the F-15 this is around 5-7ms[2]. | |||
Richard spent a lot of time optimising the F-15 over the last few years in general and the last few months in particular - both the 3d and also the Nasal / Canvas to get to the 5-7ms figure and not all aircraft are this well optimised - but there's not a lot we can do about that in the core.<ref>https://forum.flightgear.org/viewtopic.php?f=3&t=35936&p=349636&hilit=#p349817</ref> | |||
== Approach == | == Approach == | ||
Revision as of 15:18, 1 August 2020
| This article is a stub. You can help the wiki by expanding it. |
Back in 2019, Richard reported that he has done quite a lot of research in this area and there is some extra performance to be had from using multiple cpu cores. For comparison, Richard is using the F-15 here because he knows that it is pretty well optimised for both Nasal and rendering performance; however it is still heavier than a lot of aircraft at an average of 3.7ms.
When Richard is using his experimental multi-threaded rendering, there is a small increase in performance which is almost equivalent to the 3.7ms of "the rest" - that usually works out to about an extra 10fps (on his system, with the F-15)[1]-
For a few years, Richard has been experimenting with having two threads, one for the rendering and another for the simulation. He's got something that is stable with the occasional glitch.
The net result in terms for performance is there is a frame rate increase, but only by a small amount - the time that the simulation takes. For the F-15 this is currently around 5ms. Simpler models will benefit less, so if a model takes <=1ms there will not be a benefit from this technique.[2]
There are really two things that are important, firstly (and most importantly to Richard) is to avoid frame pauses[1], secondly the overall frame rate. Recent changes to the model loader (DDS texture cache) have reduced frame pauses but there are still things to improve. These two things are also referred to a system load and latency - and are equally important.
For research purposes Richard managed to get the rendering to run in a separate thread to the main simulation loop- and this gives a small increase in performance - effectively the bit at the end of the OSGStats histogram - on the F-15 this is around 5-7ms[2].
Richard spent a lot of time optimising the F-15 over the last few years in general and the last few months in particular - both the 3d and also the Nasal / Canvas to get to the 5-7ms figure and not all aircraft are this well optimised - but there's not a lot we can do about that in the core.[3]
Approach
The current way Richard is multithreading the viewer is to split out the viewer->frame into the underlying calls:
- wait for the idleThread to finish.
- viewer->advance
- viewer->eventTraversal
- viewer->updateTraversal
- release the simulation thread (idleThread.release)
- viewer->renderingTraversals
This is experimental code to see if it is worth pursuing this route
To see exactly how much time is taken in the simulation firstly set /sim/rendering/sim-frame-count-reset to true (CTRL click in the property browser) and look at /sim/rendering/sim-host-avg-ms
References
| References |