On 3 Oct 2008, at 15:14, Matthew Tippett wrote: > Are there any short term targets that will show benefit?
That's a question best answered by profiling and measurement, since people are notoriously bad at guessing such things. The 'Nasal on a helper thread' thing may be possible in the short term, if someone wanted to look at it, but whether or not Nasal is using a noticeable amount of CPU is highly debatable, and depends a lot on the particular aircraft / models you test with, I expect. Again, profiling and concrete numbers are needed before doing potentially intrusive changes for performance's sake. In general, FG has quite a few data dependencies internally which make multi-threading challenging right now - there's groundwork to make the data-dependencies more explicit (i.e, via the property tree) that has to happen before pieces can easily move to other threads. Ensuring that as much rendering work happens on other threads (OSG can be very aggressive about this) is a likely area of investigation, but one I'll leave to Tim. In theory OSG can be doing DB paging, model and texture loading, updates and culls on worker threads, and the actual drawing on another. I have no notion how much of that is happening with the current code. My guess would be that pieces ported from PLIB/ SSG may not be playing 'nice' with the aggressive OSG pipe-lining, but equally, updating those pieces of code to be more OSG friendly isn't a quick hack either. James ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
