Tuesday, October 21, 2008

Threaded FM - Probably Not

I always have to hesitate before posting a possible future direction to my blog - our future plans are a road map, a direction we intend to follow, but if circumstances change, our plans change. (This is one of the great powers of software: the ability to be flexible!) Unfortunately in the past, I've posted ideas, and then when we didn't productize them, gotten back "but you promised X" from users. So now I'm a little bit gun-shy.

But let's try the reverse: what about a feature that I am now pretty sure won't go into the sim?

We were looking at running the flight model on a separate core from the rendering engine.  The idea is that the less work must be done in series with that main rendering thread, the higher the total frame-rate.  But now it looks like it's not worth it.  Here's my logic:
  • The rendering engine now runs best on at least two cores, because all loading is done on a second core.  So unless you have a 4+ core machine, X-Plane is utilizing close to all of your hardware already.
  • The flight model isn't very expensive - and the faster the machine, the less percent of time the flight model takes (because it does not become more expensive with higher rendering settings).
  • Therefore I must conclude: threading the flight model would only help framerate on hardware that doesn't need the help - modern 4+ core machines.
So why not code it?  (Even if the improvement in framerate would be pretty low, it would be more than zero.)  Well, besides the opportunity cost of not coding something more useful, there's one thing that makes a threaded flight model very expensive: plugins.

Plugins can run during various parts of the rendering engine, and they can write data into the flight model.  I bounced a number of ways of coping with this off of Sandy, Andy, and others, and I don't see a good way to do it.  Basically every scheme includes some combination of a huge performance hit if a plugin writes data from render time, a lot of complexity, or both.

So the simplest thing to do is to not try to thread the FM against the rendering engine, and instead continue to use more cores to improve the rendering engine.

This doesn't apply to running more than one FM at the same time (e.g. AI planes and the main plane at the same time).  It's the question of the FM vs. the rendering engine that I think now is not worth the benefit.

1 comment:

Quino said...


I used to work as a 3D programmer several years ago with the OpenGL Performer library. When working with two processors, I used one for application computing and object culling, and the other one for the drawing process. The performance was quite good.

I think it's a good idea to split the FM process in another core, and use as many cores as you can.
You could end in a near future running a weather model in one of the cores of a 16 core machine, who knows!