VulkanSceneGraph: Difference between revisions

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


== Motivation ==
== 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.<ref>https://forum.flightgear.org/viewtopic.php?f=37&t=35661&p=351392&hilit=vulkan#p351392</ref>
We shouldn't expect using HLA to improve performance.  The big "win"
We shouldn't expect using HLA to improve performance.  The big "win"
would be to decouple the simulation from the rendering.  That would
would be to decouple the simulation from the rendering.  That would

Revision as of 10:56, 28 June 2020

This article is a stub. You can help the wiki by expanding it.

Intro

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

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

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

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

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

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

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


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

References

References