FSX:More on SLI and Multi-core

Compatible versus Capable


I keep hearing "FSX isn’t SLI or Dual core compatible/capable"; although strictly we should be speaking of multi-core.


This statement is not really accurate. Let’s look at the definition of compatible and capable first.


Compatible most often means "peacefully co-exists but doesn’t use". FSX can run on SLI or multi-core systems. So by definition FSX is compatible.


Capable most often means "uses". FSX can use SLI and Dual core today, just not as well as we and the community would like. 


What do I mean by this? Let’s talk in terms of SLI first and then multi-core.




SLI and Crossfire happen in the driver. The app stays out of the way and, as long as the app doesn’t do any of the 2 or so "bad things" that could break SLI it just works, see Note 1.


The main issue is FSX is CPU bound so the extra GPU doesn’t provide any benefit until fill rate, as determined by resolution and AA settings, drive past the CPU-boundness.


So SLI doesn’t benefit FSX much except at extreme resolutions with high AA. This is borne out by the review “Real-World Gaming CPU Comparison with 8800 GTX SLI”.  This article proves at 19x12 or 25x16 with 16xAA on the Intel CPU, the fill rate requirement is high enough to counterbalance the CPU-boundness and show some benefit for FSX. And these conclusions are borne out by the community, see Note 2.


On AMD, the CPU is enough slower enough that even with those fill-rate settings the CPU side of the performance cost equation still dominates.


As another note, ExtremeTech here indicates other games have varying success with SLI.  This shows FSX wasn’t showing a negative impact like some titles.


True we could be better, but it is worthwhile for the community to realize that these issues are not occurring in FSX in isolation.


If we get decent impact from SP1 on the CPU side, then SLI scenarios should get that much better.




As my blog post here stated, we do use multi-core today. We use it primarily during loading when our thread and fiber system used to schedule the various parts of the simulation are not so highly coupled. And various people have measured this.


What we don’t do today is make extensive use of threads across cores during rendering. The threads we do have are scheduled by the OS across cores, but we don’t do that ourselves.


So again it is incorrect to state FSX doesn’t use multi-core. It is just a question of how much.


And there are several instances of top game developers discussing how hard multithreaded programming is, here by John Carmack and here by Gabe Newell. As Aces is doing, Valve relooked at this and here is Gabe’s most recent discussion.


Future Goals


One goal of SP1 is to reduce the CPU-bound nature of FSX which should help SLI by reducing the point at which benefit is shown, eg at a lower resolution.


Another goal of SP1 is to increase the multi-core nature of FSX and get benefit during rendering. How much of that we get in SP1 is still to be determined.


But let’s be clear about what is and is not true today; in the interest of facts and rational discussion. It’s only then that our roadmap makes sense.


Note 1:









pg 59 "When the two graphics boards are then linked via an external SLI bridge connector, the driver recognizes the configuration and allows you to enter SLI Multi-GPU mode. In SLI Multi-GPU mode the driver configures both boards as a single device: the two GPUs look like a single logical device to all graphics applications."


so SLI is all the driver.




pg 61 "Application developers can force AFR and SFR modes by creating an application-specific profile in the driver, i.e., in the display driver control panel, click on the GeForce tab, select “Performance & Quality Settings,” click on “Add Profile,” and enter the name of your application’s executable. Then enable “Show advanced settings” and choose “AFR” or “SFR”."


so using the control panel you can enable SLI on FSX.


However, given FSX is CPU bound this only has an effect at high resolutions with max AA. Another thing to remember is to be sure and disable VSYNC and make sure your frame rate target is bumped up otherwise FSX itself is throttling you.


Note 2:


Parts of the SLI discussion come from this thread on fs2004.com


Comments (4)

  1. jonpatch says:

    Brave man, Phil, jumping into these stormy waters!  I know many people, including myself, were disappointed at the minmal multi-core usage of FSX.  I understand the reasons and constraints, and am confident the team did their best.  And I think MS would have benefited from being up-front about the fact that usage of the non-primary CPU in FSX is minimal, so multi-core users will see only a small increase in performance.  Many users feel misled, and I can understand that.

    Technical explanations aside (and appreciated), all folks want to know is that whether the program will run faster, and how much faster.

  2. Phil Taylor says:

    I agree we could have front-end loaded the discussion more, but we are here now and are being pretty frank about the state of FSX and our plans.

  3. Only yesterday Argisht "SwitchFX" left a comment on this thread looking for clarification on what Flight

  4. mpan3 says:

    is it really that hard to fish some jobs out of the main thread and throw it at the second core?  maybe move the entire AI traffic over?  or the rendering thread?  I really wouldn’t call FSX (without any patches) multi-core aware when the second core sits at less than 5% all the time loading scenery (which is an IO intensive job to begin with)

Skip to main content