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.


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
Flightgear-devel mailing list

Reply via email to