by Hooray » Fri Dec 04, 2020 4:22 pm
Vulkan isn't going to be relevant for people on old hardware like this - and looking at the time frame of the OSG migration (which really never was completed over the course of the last 15 years), it's pretty safe to say that the stars would really need to align for vulkan to become relevant in the context of FlightGear, even just over the course of the next 3-5 years.
Even today, there remains a fair share of legacy FlightGear rendering code which isn't using any OSG coding patterns, modernizing that code (or absent that, phasing it out) is likely to have a larger impact for people with such "old" system rather than suggesting to "wait" for vulkan.
And even if FlightGear were to use pure OSG, the scene graph it builds is infamous for being fairly inefficient, it's long been pointed out by senior contributors like Mathias, Tim and Fred that FlightGear builds a rather heavy scene graph with tons of redundant nodes.
Addressing these issues is going to have a more noticeable impact on performance for people on legacy systems compared to adopting Vulkan - either way, for Vulkan to be adopted, the FlightGear code base would need to change, too - and in fact, James and others have been pointing out for years that the existing SGSubsystem structure isn't even widely used by legacy subsystems, i.e. pseudo subsystems - but for a vulkan based re-implementation, you would want to have a subsystem design where rendering and simulation are separated (think the whole headless idea).
Even today, FlightGear provides plenty of optimization potential depending on the use-case/target hardware - vulkan or a multi-threaded renderer are not exactly the lowest hanging fruit.