Experimental Multi-Threaded Viewer

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)-

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.

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