VulkanSceneGraph

From FlightGear wiki
Revision as of 14:19, 3 July 2020 by Hooray (talk | contribs)
Jump to navigation Jump to search
Cquote1.png from my past experience switching to an other scene graph [OSG], I would prefer to see no osg::.. references at all in flightgear - except some few viewer related stuff. But the simulation part of FlightGear should not need to know that the viewer runs on osg/OpenGL.
— Mathias Fröhlich  (Tue, 23 Jun 2009).  [Flightgear-devel] property system extensions redux.
(powered by Instant-Cquotes)
Cquote2.png
This article is a stub. You can help the wiki by expanding it.

Intro

Back in 2016, test at Phoronix that for Vulkan the difference is much smaller between NVidia and ADM/Ati so there's hope for the future. But how soon this future will come for FligthGear is still unsure, since there has been some tinkering with Vulkan for Open Scene Graph but nothing serious yet.[1]

VulkanSceneGraph was just announced. Something to watch as it develops. Potentially a disruptor down the road, and perhaps a good design option to consider as it matures.[2]

https://github.com/openscenegraph/VulkanSceneGraph


As other posters have mentioned, there are a variety of specific requirements for a flight simulator that aren't fulfilled in a more typical game engine. So it is exceedingly unlike we'd move to Godot or any other game engine, as there would be an innate tension between our requirements and that of a game.

Much more likely is a migration to Vulkan Scene Graph, which is a project being run by the same team that wrote OSG. That will have similar characteristics as OSG, operate at a similar integration level and we can hope for some commonality to make migration easier.

I say "migration" intentionally. Moving to a new graphics engine is not just going to be a case of a drop-in replacement for OSG at a core code level. It's highly likely that there will be implications on a whole range of areas - scenery, trees, clouds, buildings, Effects, Canvas, animations, aircraft.

The two main drivers of the migration from plib to OSG (Tim and Matthias) are no longer active as FG developers, but I was moderately involved (along with Erik and James IIRC). It's a huge amount of work, and requires some fairly deep knowledge of how graphics pipelines and scenegraphs work to design something that scales to our needs.[3]


The only way I can see of truly making use of lots of cores is switching to Vulkan because OpenGL is essentially single threaded. I've 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.

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.[4]

So to achieve the same as the new tech in the new Microsoft Flight Sim, the steps are:

  1. CPU multi-processing.
  2. Vulkan instead of OpenGL.
  3. Implement HDR and PBR.
  4. Better artwork.

there is VulkanSceneGraph. This evolution of OSG will still need some more time to bake. Would switching from OSG to VSG really be something that cannot be achieved in FG? Obviously, if we stick with OSG, this will eventually happen.[5]

Background

GPU doesn't do anything on its own, it's fed all the time by the CPU. Having the CPU and GPU work 100% all the time is very, very hard. I'd say it's not even possible to get more than 50/60% on legacy APIs like the one we are using. If we introduce async compute with modern APIs like Vulkan and GL > 4.0, we could probably get to 80/90%. A lot of effort is put into real times apps so they can get all the juice they can from the system hardware.[6]

Unfortunately, OSG is still largely dependent on the old openGL fix-function pipeline. Some folks have been working toward a working OSG build without it, but you need to deal with several non-functional features (e.g. osgText).

I doubt the situation improves until VSG becomes a viable option.[7]

Vulkan would be nice but OpenSceneGraph suits us fine right now. And changing that would really be an involved process.[8]


Largely it's not something that we can fix in FG because it's not FG that can't take advantage of multicore it's OpenSceneGraph that can only make limited use of multiple cores because underlying OpenSceneGraph is OpenGL and it is will understood that OpenGL is effectively almost single threaded. So the only way to make the rendering make more use of multicore is to replace all of the rendering with something that uses Vulkan.

The folks over at X-Plane have been working on their Vulkan rendering since 2018; and they're predicting it will be 2020 before they're finished.[9]

The problem is that OpenGL is fundamentally single threaded, although OpenGL does support multi threading it doesn't really gain much because of the driver architecture; and because of this there isn't much that can be gained from OSG from running in multiple threads. This is the problem that Vulkan was designed to fix and until FG supports Vulkan (which is years of work) there is no benefit to be had from multiple CPU's.[10]

Motivation

X-Plane are seeing around 10-15% improvement using Vulkan over OpenGL (NVidia driver), 20-30% with AMD. These early results may be misleading and there could be more to com. Also Robert has seen a bigger proportionate improvement with VulkanSceneGraph.[11]

We shouldn't expect using HLA to improve performance. The big "win" would be to decouple the simulation from the rendering. That would mean that graphical frame-rates would be more consistent, even if the simulation underneath wasn't. It would also allow different renderers to be used - e.g. you could plug in a a completely separate renderer based on VulkanSceneGraph as opposed to OpenSceneGraph.

To be honest, many of these advantages are not going to make a huge difference for home-simulator enthusiasts with a single PC and display. But for larger more complex applications in, say, industry where having a guaranteed 30fps is critical, there are benefits.[12]


VulkanSceneGraph requires C++17. If we adopt VSG, and I believe we should, that will impose a second disruption further down the road. Better to adopt C++17 now to avoid a double hop.[13]

References

References