On 3 Oct 2008, at 13:48, Matthew Tippett wrote:

> Speaking of which, another call out for multithreading...  The GPU
> isn't the limiting factor in our tests, the CPU is.  Even mid-low end
> systems have 2-4 cores these days, and with the multi-display demo we
> are continually capped by one CPU.

I have a long, long, long term plan to improve multi-threading  
support, by enforcing subsystems to *only* communicate via the  
property tree, which has light-weight locks thanks to some work by  
Mathias. With a dependency graph between subsystems (which I want to  
add for other reasons any way) it would then become possible to run  
any 'clean' subsystem on a pool of worker threads (maybe just one,  
maybe more).

I'm sure there's some other locking that would be required for global  
state (eg, the AIManger objects), and of course there's awkward cases  
that will never be clean (especially instruments that touch the scene  
graph) but it still seems a worthwhile goal. It'd be worth identifying  
which subsystems are the big time sinks (FDM? AItraffic?) to  
prioritise this.

Another thing that would work well is to proxy all nasal script  
invocations to a Nasal helper thread - again this assumes scripts  
basically interact with the sim via properties (which they already do)  
and that any system functions they call are thread safe - not very  
hard to do. As more and more functions get moved to nasal, this might  
become a very easy way to balance the CPU usage.


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