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. 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
