Experimental Multi-Threaded Viewer: Difference between revisions

From FlightGear wiki
Jump to navigation Jump to search
Line 18: Line 18:




== History ==
In the context of rendering simulator graphics, the most important thing is fluidity, and that is achieved with consistent frame rates and consistent update rates/amounts. This is something we learned after creating the original FlightGear architecture unfortunately. We thought if we just ran faster, then things would smooth out, and that's not entirely true. If we are running at 60hz and drop a single frame (momentarily down to 30hz) our eye's can pick that out. This is something that's fairly hard to achieve perfectly on a typical operating system like windows or linux. But the current flightgear timing architecture doesn't really help the situation, and the original scene graph library we used didn't offer any tools to manage this.
So by all means, architect a beautiful thread scheduling system that is robust to all the issues threads normally lead to, but keep precise time intervals in mind, or we will never climb out of the timing jitter hole we are currently in. (No worse than FSX probably, but we are no where close to the fluidity of sims like infinite flight and many other 3d games and simulators.) Don't fall into the trap of thinking we can climb out of the hole by just running faster, or boosting our average frame rates. That is only a partial solution.
The FlightGear property system is another beautifully designed piece of artwork. It is extremely powerful and useful for sharing 'state' between different program modules (even between nasal and C++). However, it is not thread safe, and it doesn't lend itself to being made thread safe. The property tree is such an integral part of the FlightGear design ... many of our past threading bugs and workarounds have come from ignoring that our property tree isn't thread safe, but pretending it is and trying to be mostly lucky most of the time. Some of our core developers have taken a really deep look at HLA/DIS as a way to rearchitect the flightgear core infrastructure in a way that is threadable and distributable.<ref>https://forum.flightgear.org/viewtopic.php?f=3&t=35936&p=349601&p349566</ref>
== Approach ==
== Approach ==
The current way Richard is multithreading the viewer is to split out the viewer->frame into the underlying calls:
The current way Richard is multithreading the viewer is to split out the viewer->frame into the underlying calls:

Revision as of 15:23, 1 August 2020

This article is a stub. You can help the wiki by expanding it.
Note  we should be looking to find a way to get more performance on the rendering side as that's what generally limits the frame rate - on Richard's system he did once manage to get a 90% GPU load and a 75% CPU load for FG by enabling 20 OSG Database threads but generally both the CPU (single core) and GPU are running at close to 90% on my system with OSM and high random vegetation.

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]


History

In the context of rendering simulator graphics, the most important thing is fluidity, and that is achieved with consistent frame rates and consistent update rates/amounts. This is something we learned after creating the original FlightGear architecture unfortunately. We thought if we just ran faster, then things would smooth out, and that's not entirely true. If we are running at 60hz and drop a single frame (momentarily down to 30hz) our eye's can pick that out. This is something that's fairly hard to achieve perfectly on a typical operating system like windows or linux. But the current flightgear timing architecture doesn't really help the situation, and the original scene graph library we used didn't offer any tools to manage this.

So by all means, architect a beautiful thread scheduling system that is robust to all the issues threads normally lead to, but keep precise time intervals in mind, or we will never climb out of the timing jitter hole we are currently in. (No worse than FSX probably, but we are no where close to the fluidity of sims like infinite flight and many other 3d games and simulators.) Don't fall into the trap of thinking we can climb out of the hole by just running faster, or boosting our average frame rates. That is only a partial solution.

The FlightGear property system is another beautifully designed piece of artwork. It is extremely powerful and useful for sharing 'state' between different program modules (even between nasal and C++). However, it is not thread safe, and it doesn't lend itself to being made thread safe. The property tree is such an integral part of the FlightGear design ... many of our past threading bugs and workarounds have come from ignoring that our property tree isn't thread safe, but pretending it is and trying to be mostly lucky most of the time. Some of our core developers have taken a really deep look at HLA/DIS as a way to rearchitect the flightgear core infrastructure in a way that is threadable and distributable.[4]

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

Summary

It is generally understood that the lack of LOD in the terrain mesh is contributing to overall system load - and good progress was made on fixing that with the nextgen scenery project but work on that is currently stalled.

What Richard thinks is the best long term solution is to split the rendering into a separate process and keep rest the same - as long as an aircraft model can consume no more than 6.2ms per frame (peaking at 8.3ms) we can have at 120hz simulation core that can then feed the rendering process possibly using CIGI[3]. Now it maybe that he's biased towards this approach because it's what the big sims have been doing since the advent of digital image generation.

The only way Richard can see of truly making use of lots of cores is Vulkan Scene Graph switching to Vulkan because OpenGL is essentially single threaded. Richard has been following the VSG (Vulkan SceneGraph) development lists and progress is being made and this is likely the long term direction that we will need to take; and it might be that this is the time to separate out the rendering.[5]

In the short to medium term we can only improve what we've got, firstly with Compositor, possibly with nextgen scenery but multithreading isn't going to play a major part unless we can separate out the rendering so we'll be using 2.5 cores.

References

References