On Mon, 24 Oct 2005 11:08:06 -0700, Andy wrote in message <[EMAIL PROTECTED]>:
> Curtis L. Olson wrote: > > I would like to make a case for non-threading from the standpoint of > > simplicity. We have had (and probably still have) some extremely > > subtle and extremely difficult to track bugs in our threaded tile > > loader. > > I don't disagree at all. Everything you say is true, and a reason to > avoid threading wherever possible. Naive thread architectures are > invariably a disaster. But unfortunately the hardware world conspires > against us -- SMP is rapidly becoming the rule rather than the > exception for high performance desktops. > > Note that there are a few spots where we could split out separate > threads in a relatively clean manner: > > + FDM: Put a lock around the input and output stages (or wrap them > into an object that can be placed in a synchronized queue) and let > the actual numerics work happen on a different CPU. The advantage > here is that you can crank up the simulation rate quite a bit on > SMP/multicore boxes, leading to (at least with YASim) more stable > ground handling. ..and clusters. ;o) > + Audio: drive the "OpenAL" thread with a simple command stream from > the main loop. One many systems, this will (might, if OpenAL > doesn't already do this) move the mixing off of the main CPU, which > is good. Even better, it will decouple the audio stream from the > main loop latency issues and make "skips" easier to handle. > > + Rendering: One idea here would be to "clone" a separate scene graph > (just the non-leaf animation nodes, really) and let one thread (the > renderer) draw it while another (the main loop) gets the next one > ready for rendering. When done, you do a synchronized "graph swap", > or even triple-buffer it for higher throughput at the expense of > latency. This would require significant surgery to the existing > model/animation code (and, to a lesser extent, the GUI and tile > code) to store the property values somewhere instead of reading them > at render-time. ..can we get both multi screen wrap around cockpit style immersion movie theaters and formation flight? > + Everything else: This thread would contain the existing main loop, > and its basic structure wouldn't change. > > Note that this design allows threads live by relatively simple rules. > The main loop doesn't change much except where direct calls are > replaced by commands to be queued. And the worker threads all work > only on their internal data; they don't need (and are forbidden) to > touch external state like the property tree. > > The first two could be done with fairly minimal code, actually. The > renderer changes would be more significant. -- ..med vennlig hilsen = with Kind Regards from Arnt... ;o) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. _______________________________________________ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
