VulkanSceneGraph
|
|
| Multithreading |
|---|
Stuart did some prototyping work to federate FlightGear within HLA a number of years ago, using OpenRTI and SimKit. There should be some reference in the
mailing list archive if you care to look. It is certainly possible, and one use case was to decouple the IG (image generator) and enable work to start using VSG (vulcan scene graph) while continuing to support OSG.
FlightGear is used regularly as a decoupled Image Generator (IG) for both academic and industry projects, through the many flexible I/O options available. They just aren't publicised much.
[1]
|
[Mathias used] some abstraction classes to make such a transition smooth. The first thing will be to make fg independent of sg* vectors and matrices. Have a set of classes in my local tree which will be self consistent and will interface very well with sg* vectors. The same interfacing can be made for osg:: datatypes.
Using this we can [more easily] use the same scene graph independent code paths wih less 'type conversion by copy' operations. — Mathias Fröhlich (2006-01-14 10:56:31). [Flightgear-devel] Re: Graphics Engine.
(powered by Instant-Cquotes) |
|
|
|
I have thought often about a thin scenegraph abstraction layer for some structural nodes. That could help us much when we need/want to switch to an other scenegraph. At least for a transition time we could have a ssg and an osg version in parallel without disturbing people willing to have the settled down and feature complete ssg build.[...] I think of abstractions for Group/Transform nodes. Just to be able to plug together the scenegraph from flightgear's sources. Animations are scenegraph specific and shoudl be scenegraph specific.
Animations will just need a pointer to a property. The aprioriate scenegraph callback objects/code can be entirely scenegraph specific and does not need to be abstracted. That code is only installed in the model scenegraph as a postprocessing step to model loading. — Mathias Fröhlich (2006-07-29). [Flightgear-devel] HUD: raw gl-commands vs. plib/osg wrappers.
(powered by Instant-Cquotes) |
|
|
|
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) |
|
| This article is a stub. You can help the wiki by expanding it. |
VSG was discussed a few times on the weekly hangout last year - the consensus was that firstly VSG needs to become feature complete and stable and also that we need WS3.0 and to be building the scenery with VPB (because there is a roadmap for VPB on VSG).
So the main progress that can be made towards VSG is some of the work already in progress: removing the old OpenGL things and WS3.0/VPB and Compositor (Note: as of 07/2020, Jules is also prototyping CompositeViewer Support) .
There are also lessons to be learnt from the move to OSG that need to be applied to any plan to move to VSG (see especially Mathias' comments above about scene graph API encapsulation) and if anyone is serious about working on VSG then we should discuss that on the mailing list; it's likely that VSG is something that we do after the next next LTS release.[2]
Status
Last updated: 10/2022
There is some interest for adopting VSG, but no plan has been determined yet. It is anticipated VSG will get more discussion once a few key active initiatives come to fruition...
- Stabilization
- Compositor
- World Scenery 3.0 roadmap
- CompositeViewer Support
- Howto:New Canvas Execution Model
- Scenegraph optimizations
As of late 2020, VSG seems to be getting close to an initial release, but as of now it seems a bit risky to adopt at this early stage of its life.[3]
There has been some work on how we might move to VulkanSceneGraph, but there were some technical problems we couldn't overcome. [4]
Be aware that VulkanSceneGraph is expected to go to Release 1.0 any day now. I believe the main concern was around it not being feature complete, which it seems has now been accomplished.[5]
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.[6]
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.[7]
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.[8]
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.[9]
So to achieve the same as the new tech in the new Microsoft Flight Sim, the steps are:
- CPU multi-processing.
- Vulkan instead of OpenGL.
- Implement HDR and PBR.
- 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.[10]
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.[11]
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.[12]
Vulkan would be nice but OpenSceneGraph suits us fine right now. And changing that would really be an involved process.[13]
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.[14]
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.[15]
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.[16]
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.[17]
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.[18]