On Tuesday 01 April 2008 13:10, Anders Gidenstam wrote:
> On Tue, 1 Apr 2008, LeeE wrote:
> > Hmm...  [looks at watch and wonders if it's time to post
> > another missive about the _need_ for a redesign of FG to run on
> > MPP systems as it gets ever clearer that significant increases
> > in computing power have more or less stalled in terms of height
> > (cpu speed) and in future, will come instead from width
> > (parallel processing) - FG's current design is effectively
> > obsolete]
> Yes, it might be time for that. However, the recent work on model
> loading is certainly a step in the right direction.
> One problem is to identify parts that we will gain anything from
> moving to a separate thread. I have seen the FDM suggested in the
> past, but even on my (ancient) system JSBSim corresponds to about
> 1-5% of the CPU usage (estimated by looking at the rate sim time
> progresses in the standalone version of JSBSim). Andy has told me
> YASim is more expensive (it does more at runtime) but it is
> probably at most 20-30% of the CPU usage (guesstimate :). So, the
> prospective gains there do not look that large.
> Doing some profiling might make the picture clearer.
> I think the main targets for parallelization are the rendering
> pipeline and various "add-on" systems, like the traffic manager.
> Personally, I'd like to have threads (possibly with very limited
> interaction abilities) available in Nasal for isolated and
> computation intensive tasks (e.g. fast forwarding my fire
> cellular automaton :).
> Just my 2 (euro) cents..
> Cheers,
> Anders

Without a fairly deep understanding of how the various subsystems 
within FG have been implemented and work it's difficult to make 
worthwhile suggestions, especially while the developers are still 
getting their heads around the intricacies of OSG...

...but fwiw:)

I think the single most important step would be to run the graphics 
subsystem in it's own process, splitting it from everything else.  
On multi-core systems this would mean that the graphics subsystem 
gets the resources freed by the 'everything else' and 
the 'everything else' gets the resources freed by the graphics 

This would be a relatively small gain for the graphics subsystem and 
a much bigger gain for everything else, where it's arguable that 
it's needed, but it would allow much higher and more consistent 
rates in the FDMs, autopilot controllers & filters and Nasal.

The thing is though, that the graphics subsystem needs a lot of data 
and it's questionable that it could be transferred quickly enough.  
Therefore it's likely that the scenery & model loaders would need 
to be included in the graphics subsystem so once it's told what 
data it needs it can fetch it itself.

With a core to itself, the 'everything else' part of FG would 
benefit less by further splitting but if it was well designed it 
should make plug-ins much easier to implement and maintain.

In the longer term, thought needs to be given to 'box-rendering' the 
graphics - splitting the scene into several regions and processing 
them in parallel - but this is much easier said than done, 
especially as rendering is h/w based.  Still, this is the sort of 
thing that newer versions of OGL/OSG will _have_ to address in the 
future, if they haven't already got some features in this area.


Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
Flightgear-devel mailing list

Reply via email to