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 subsystem. 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. LeeE ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
