Category: Hardware

Clouds, Screws, and Settings

I’m listening to Marco Arment and Dan Benjamin debate whether a user setting could have avoided the incident where a man’s iPhone rang during a concert.  I also just finished reading the Steve Jobs biography.  It got me thinking about the trade-offs between a closed non-configurable system and an open, configurable one.  This comes up in an X-plane context every time we poke at the cloud rendering settings and someone asks whether we can put in more settings for additional configuration.  What trade-off is right for X-Plane?

Chris suggested an analogy to me a few weeks ago that I think is pretty good: tuning the rendering engine in X-Plane should be like tuning the timing in your car.  It should be possible, if you are a serious expert and enthusiast, to change the tuning (and if doing so wrecks your engine, well, you were asking for it by opening up the engine), but it shouldn’t be easy.  Regular users of the car expect the manufacturer to have a lot more expertise, and to set the timing to an optimal setting up front.

I think the same thing goes for X-Plane.  I should use as much expertise as I have to maximize efficiency no matter what trade-off is being made; at no point should dialing in a setting result in stupid behavior inside the engine.  It’s up to me to know what can be inefficient and avoid that happening.

So: the rendering settings are going to remain as simple as possible, and any time we can make them more simple, less likely to be set up wrong, or any time we can realign them to be better aligned with user constructs (“more houses”) instead of internal constructs (“higher instancing density ratio!”) we’ll take that win.  It should not be the user’s job to tune the engine, and any time that is necessary, that’s a failure by me to pre-tune the sim, not a feature.

I don’t think we are even close to the kind of rendering settings that are really useful to non-expert users; one of the frustrations with performance tuning over the last few months has been the number of times a user has sent me rendering settings and it was clear that the settings were inefficient for the given hardware.

The answer is not to try to make every user into an expert in the OpenGL pipeline; the answer is to change the settings so that users don’t have to be experts.  This is not easy to do; the reason it’s not done yet is that we will have to create new code and do real hard work to make the interface simple.  One theme that both Steve Jobs and Jonathan Ive describe when discussing their design philosophy is that, to make something simple in its final product, you have to dig down and master the complexity that you want to get rid of.  To make the rendering settings simple but still powerful, we are going to have to solve these performance-efficiency-hardware problems ourselves and encapsulate that knowledge in code, and that’s not trivial.

Underneath the settings are a whole pile of art controls, and if you really want to, you’re more than welcome to enter any value you want in there.  If you discover that you’re better at tuning the engine than I am, I will be very happy to hear what you did!

This attitude is not as extreme as the “Steve Jobs” approach; Apple devices often use custom screws to ensure that normal people can’t open their devices even if they want to.  We are hiding implementation out of sight, but we are not locking that implementation at all.  The settings file is plain text, the art controls are viewable with a publicy available plugin (DataRef Editor).

X-Plane has always been a hackable sim, and one of the things I used to enjoy back in X-Plane 6 was just looking at all the stuff in the resources folder; the raw textures were pretty amazing to view in themselves.

My goal here is not to take that away; only to make hacking and opening up the sim something you can opt into if you are curious, instead of something mandatory to get good performance.

Posted in Development, Hardware by | 24 Comments

Mobile GPUs and Fill Rate

Fill rate: when we talk about fill rate, generally what we’re talking about is your GPU’s ability to fill in individual pixels to make the final image you see while flying.  (The actual components of GPU throughput get a lot more complex, but we’ll keep things simple for now.)  Two key things to note about fill rate:

  1. It only comes from your GPU – not your CPU.
  2. The bigger the size of X-Plane’s window (or the higher the full screen monitor res), the more of it you use.

Therefore I can offer this very simple test as to whether you are fill-rate limited:

If you are running in windowed mode and making the window smaller improves frame-rate, you are fill-rate limited.

(There is actually one important exception to the above test: if you are running out of VRAM, making the window smaller uses less VRAM for the main window + off-screen buffers, which can help fps.  So be sure to see whether cutting your texture res helps fps – if it does, you are out of VRAM.)

Fill rate gets used up by:

  • A larger rendering window.  This is the number one consumer of fill-rate.  Double the size of the window in each dimension, you use 4x the fill-rate.  That adds up quick!!
  • Clouds tend to be fill-rate intensive.
  • HDR mode is significantly more fill-rate intensive than non-HDR mode.
  • The 3-d cockpit is more fill-rate intensive than 2-d and external views, particularly with HDR enabled.
  • Shadows, to a limited extent.

X-Plane 10 contains a stat called “cpu load” in the framerate output data line; I will describe its full meaning and implication in another blog post, but generally low CPU load (e.g. < 0.7) means you are fill-rate limited.  If your CPU use for one core is 100% (this means 25% in the task manager for Windows users on a 4-core i5, but 100% in top for Mac/Linux users no matter what the number of cores) then you are almost certainly not fill-rate limited.

Optimizing Fill Rate

X-Plane 10.03r1 will post in a little bit – this is our first attempt to finalize X-Plane 10.03.  It is not the end of the bug fix and performance tuning work for X-Plane 10.  But if we can get a stable 10.03 we can use it as a baseline and limit betas to those who check the “get betas” check-box in the installer.

X-Plane 10.03r1 contains fill-rate optimizations for the 2-d and forward-no-HUD views; we’ll have to see how much they help people, but they should help you a bit if you are fill rate limited, flying a plane with a 2-d cockpit, and are seeing low fps with clouds and/or HDR.

Once 10.03 is final, we’ll start 10.04 and I will attempt to make a similar set of optimizations for the 3-d cockpit.  Note that the 2-d optimizations do not apply if you have a plane that uses the 3-d cockpit for the 2-d view.  (Since all of the new X-Plane 10 default planes do this, we’ll need the 3-d optimizations in 10.04 to see the performance benefit with the 747, Baron, and other new default planes.  The Cessna, Cirrus Jet, and Piaggio from X-Plane 9 should all benefit immediately.)

Your Mobile GPU Is Light But Not Fast

Here is a table I culled from Wikipedia: it is a table of GPU performance for the “top end” cards for ATI’s last 4 generations of hardware.

4870 Jun 08 12 30 115 1200
6970M Jan 11 21 32 115 1305
5870 Sep 09 27 68 153 2720
6970 Dec 10 28 84 176 2703
7970 Jan 12 29 118 264 3789

GP = gigapixels/second of fill, GT = gigatexels/second of texture, BW = GB/second of memory bus bandwidht, and GFLOPS = gigaflops/second of MADD.  At least I hope – see the original table.

Now I have inserted one mobile GPU (the 6970M) into this chart.  So the first thing you can see is: the 6970M provides in a laptop the power that was available in a desktop about two years earlier, more or less.  That’s a big step back in time.

The reason is simple: mobile GPUs are typically cut down in their core configuration – there’s no way you can run a 150W full power GPU with those 3 fans in a laptop.

If you have an iMac, you have a mobile GPU.  Even the older iMacs which didn’t have the “M” designation on their chip, those were mobile too.  In fact, you’ve got a mobile GPU on a huge screen.  (Super-size to the 27″ iMac to get the 4x fill rate boost and you pick up 1.7x the pixels; if you get the big iMac with the cheap GPU you have a mid-range mobile GPU on a 2560 x 1440 screen!)

Some Kind Of Summary

I’m not entirely sure what my main point here is…perhaps the executive summary is:

  • We (LR) are working to optimize fill rate in X-Plane 10.  Fill rate is not the only performance bottleneck we are working on, but it is a very important one.  Some of this is in X-Plane 10.03r1, some will come in later updates.
  • You can determine whether you are fill-rate limited by resizing your window.
  • If you have a mobile GPU in a laptop or iMac you may have less fill rate than you would expect.
Posted in Development, Hardware by | 53 Comments

Tips for better frame rates Pt #1

Austin, Ben and I are still working on cleaning out the remainder of Ultra-High priority bugs right now which essentially consist of crashes or other things that impact large groups of people. Only once these types of problems are taken care of will we be able to start looking into figuring out what can be optimized in the sim.

Many of you are getting really decent performance. Many of you are getting “ok” performance and others are getting really poor performance. This is not a surprise because there is a huge spectrum of hardware out there. Moving forward, we have some tools at our disposal that we can use to collect some data see what’s impacting performance the most. Then we can optimize it. Then we can see what the second biggest problem is, and then optimize that….and around and around we go.

In my opinion, one major contributor to performance loss right now is having your settings wrong. X-Plane allows you to configure a LOT of settings to get optimal performance. We’ve given you more than enough rope to hang yourself with, and many of you are doing just that. X-Plane’s rendering engine is very flexible. It has to be because it has to run on a huge spectrum of hardware. Like any large system, it needs to be tuned properly for its intended use. Ben’s already told you that you need to hit rock bottom to tune X-Plane properly. What that means is that you need a baseline. Think of how you tune a guitar or any instrument for that matter. You need a reference pitch such as a tuning fork. You match one string up perfectly to that pitch and then you adjust ONE string at a time until it’s in tune with the previous string. Imagine trying to tune a guitar without a reference pitch. You would have no idea whether you were making progress or not!

The “tuning fork” of X-Plane is starting from zero. This is your reference. Turn off EVERYTHING. Turn of AI aircraft, set your clouds to clear, set your visibility to something reasonable like 20-30SM, turn off rain and storms. Go to your Rendering Options and set EVERYTHING as low as it will go. If you run X-Plane in fullscreen mode, turn down your resolution. If you run X-Plane as a window, reduce the size of the window. The item that says “Framerate-lock to monitor” should be set to “Do Not Lock” (more on this in a moment). Take a look at what kind of framerate you get in the sim. Don’t just sit on the runway, fly around, take note of the range that you see. Also, see what you’re system’s doing as well as you can. Take a note of CPU usage, Memory Usage (mainly how much is left to be used), and GPU usage if you have a fancy driver that lets you see this information. At this point, you should have a rough guess as to what your weakest link is. If your CPU is almost maxed out right now, it’s going to be your limiting piece of hardware. If your almost out of memory, that will be your limit etc.

(A quick detour on CPU cores…more is better-ish…to a point. 9 women can get together and do 9 different tasks in 1/9th of the amount of time it would take 1 woman, but 9 women cannot have a baby in 1 month! The point is, if X-Plane has multiple tasks going on (like AI traffic, scenery pre-loading etc), then multiple cores helps get the tasks done quicker. But if there’s only one task going on (like rendering), your other cores will NOT help you do it any faster.)

Back to tuning…Start with Rendering Options. Now start turning things up ONE setting at a time. Start with things that are most important to you. Each time you change something, go back to the sim and see how it impacted you. Take note of your hardware utilization again. Has CPU changed much? Has memory changed much? Don’t be fooled by large jumps in FPS. Remember, going from 100fps to 90fps is a difference of 10fps (“wow” you’re thinking)…but that’s only 10%! That same 10% reduction at 20fps would bring you down to 18fps. You should care about the PERCENTAGE change, not the FPS change. If you notice that one setting in particular causes your framerate to lose a huge percentage, then you’ve probably figured out what the weakest part of your particular hardware is. This is the setting that you’ll either have to live without or the one you’ll have to be VERY careful about touching. If this setting is important to you, perhaps there is something else that you can sacrifice to get some performance back for this setting. Or if you’re able to upgrade your hardware, that’s the thing that you should invest in.

At some point, hopefully you’ve found yourself with a configuration that you like. Again, note your average FPS in various situations. NOW you can go back and set the weather how you like it. Turn the clouds up, turn the visibility up if you want but be careful. Visibility can be a huge factor in performance. The farther you can see, the more things the system has to draw. I would not recommend going over 50SM unless you find yourself with a ton of performance left over. Now you can turn on the number of AI planes that you like flying around with. You may have to go back and retune some things to get the system balanced with the new weather and AI. Make SMALL incremental changes. You don’t want to de-tune it severely. When everything’s balanced, now go back into Rendering Options and note at the very bottom, it will tell you how much VRAM is being used. Turn the Texture Resolution up until the VRAM usage gets near the amount of VRAM you have on your GPU. Then fly around and test it. You should NOT notice any difference in performance. If you do, go back and turn your Texture resolution down a notch and try again. Your goal is to get your texture resolution as high as you can without impacting performance or going over your VRAM limit.

Lastly, a note on VSync. I told you earlier that the “Framerate-Lock to Monitor” setting should ALWAYS be on “Do Not Lock”. This is a tiny white lie. If you’re an advanced user, if you know what VSync is, if you know how it works and if you have enough performance to spare and you want to stop scene tearing, go ahead and turn it on. Even then, don’t turn it on until you are done tuning framerate, because VSync will obscure changes in fps, making it impossible to tell what effect a rendering setting has on your hardware. If you don’t know what it is or what problem it’s meant to solve…please leave it off and forget it exists. It will NOT improve your performance. If you’re like me and just want to learn about it anyway, read this but leave the setting off anyway.

Feature Affected Subsystem
AI Aircraft CPU/VRAM/Bus Bandwidth
Cars CPU
Clouds GPU
Objects Bus Bandwidth (CPU on old cards)
Roads Bus Bandwidth
Forests Bus Bandwidth
Screen Resolution / Window Size GPU (usage proportional to resolution)
Shadows Bus Bandwidth (this amplifies all other bus bandwidth use a lot!)
Table 1. Feature vs. Affected Subsystem

***EDIT*** I didn’t want to have to do this but I’m going to be more heavy handed with the comment moderation because inevitably, the comments end up getting WAY off topic.  Feel free to ask questions or post comments directly related to the topic but this is not the forum for other discussions. I am also not going to be providing one-on-one tuning at this time so please do not post your specs unless asked. We have not begun diving into performance issues yet. The purpose of this post is to educate you on how to setup your own system in the most optimal way possible right now. Thank you for your understanding!

Posted in Hardware by | 37 Comments

We Have Our First Patch

Austin just posted an announcement.  The short version: we have the first patch to X-Plane 10.  You can read more about how to get the patch here.  A few key points:

  • You don’t have to re-download the whole sim!  You can simply run an update, which will get only the changed files.  Less than 150 MB, I think.
  • If you can’t run X-Plane 10 because the app isn’t getting along with your graphics card, you can still update – just run the updater directly.
  • We have posted a new torrent – zipped, so it should be smaller, have correct permissions, and not drive µTorrent nutty with too many files.

Compatibility With Graphic Cards

I’ll try to post on-going status updates with regards to graphics card support; I’ve posted a chart on the wiki.  If you have gotten one of the cards for which the status is “unknown” to work, please post a comment.

The two cases that I believe we have fixed for the 10.02 patch are Intel HD integrated graphics and Radeon X1000 series GPUs – both were not functioning due to bugs in X-Plane (which were revealed by the particular capabilities of these cards).

I was surprised by how many reports of Intel HD graphics crashes we got but in hind sight it makes sense: everyone with a Core i3/i5/i7 chip has one of these GPUs, since it is built into the chip.  In some cases, users were running on the Intel GPU despite also having a real GPU, so even with the crash fix, those users will need to figure out how to change their default GPU.  (For a desktop this is usual a BIOS operation – for a laptop it’s usually black magic.)

I still have at least six different GPU crash cases that I am investigating, so there’s a lot of compatibility work to do.

The other major compatibility problem I am hearing about is just a slew of reports of weird stuff with NVidia GeForce cards.  Graphic artifacts, hangs, screen corruption, two copies of the app – you name it.  It’s going to take a while to figure out what’s going on.

Framerate and Performance

We put out X-Plane 10.02 to fix a few crash problems and cases of graphic corruption; there are only a few performance tweaks along for the ride.  The majority of performance work is still to come.  You may get a few fps back with AI planes, or if you have a Mac NVidia GPU.

Posted in Development, Hardware, News by | 42 Comments

A Few Settings Tricks to Try

For those who cannot wait to try to get X-Plane 10 to run fast, a few tips on how to ‘break down’ where a bottleneck might be:

  • Run with clouds vs. clear skies.  The clouds chew fill rate.  Are clouds the issue?
  • Turn down visibility – X-Plane 10 will run at 100 nm but some machines will die with this.  Does a low visibility help?
  • Turn off the AI planes.  Any better?  They take draw time when on screen and cores.
  • Turn down texture res if you haven’t already.  (Well, most people try that by default.)  Start with low settings and work your way up.
  • Try areas away from KSEA.  Compare down-town to rural, and different airports.
  • If you have an nvidia card before the 400 series, try running with –no_instancing from the command-line.  This can particularly help Mac users.

In most cases there is only one setting killing your framerate – find it, fix it, and things get a lot better…fix it and you’ll find those other settings you turned down can go up at least a bit.

The gotchas in v10 are definitely different from v9.  Shadows can kill your fps in a huge way – I’ll be spending a bunch of time tuning them to look better and kill fps less.  Turn water reflections down if you don’t need them – the “advanced” setting is frankly a bit pointless.  Turn off full screen anti-aliasing if you are going to run in HDR mode, then restart the sim.

Posted in Hardware by | 56 Comments

Rendering Settings and FPS: Don’t Panic

I am still trying to dig out my in-box this morning, but Chris tells me that there is a lot of concern over X-Plane 10’s framerate.  For now I can only offer one bit of advice:

Don’t panic.

I have no doubt that many users are seeing terrible fps with version 10.  But I think that we’re going to get this sorted out over the next few weeks and the end result will be really good.

How can I think that when so many users are seeing poor performance?  Here’s why…

  • With X-Plane 9, four years after its debut, you still can’t run X-Plane 9 at extreme objects on a modern computer.
  • With X-Plane 10, all of 1 day old, with very little performance ,i can run at extreme objects on my core i5 and get > 20 fps in the demo area.

In other words, the hardware usage of v9 was never properly “fit” to the capabilities of a modern desktop.  By comparison, version 10 is at least on the right curve, and we know how to tune for performance.

Please bear with me for a few days: the current state of chaos in our server download farm is a high priority right now, as are a few serious bugs.  So if you send me a list of your hardware specs, settings, and some numbers, I cannot help you.

When I do have time to look at performance (hopefully real soon) here’s how we will do it:

  • I will post some standard fps-test command lines that you and other users can try.
  • You can send me back the log.

One I have that data, controlled for all rendering settings, across a variety of hardware, then we’ll be able to understand performance and fix engine bugs and provide work-arounds.

X-Plane 10 is only fast if it hits the fast path through the driver every time it needs to; there are all sorts of little things that can go wrong that can kill fps that are not an indication that long-term the sim will suck.  We have worked through nasty performance issues before and we will again!  It took two months to kill off the very last driver problem in X-Plane 9.0 – I certainly hope it won’t take that long to get the vast majority of users running well in version 10.  But I do believe that fps problems we see now may be as much a case of driver vs. engine quirks than a fundamental performance gap.

Posted in Hardware by | 34 Comments

We Spent That Efficiency (And Other Caveats)

I’ve seen a lot of fretting in blog comments and forums to the tune of “I’m afraid my computer won’t be able to handle X-Plane 10.”  And sometimes the response is “it will be more efficient than version 9.”  I want to take a second to address both points.

First: don’t panic.  Wait for version 10 to come out, then try it.  You might be pleasantly surprised.  If your computer is an absolute basket case on version 9 (or your graphics card is dropping below our minimum hardware requirements*) then version 10 won’t work for you, but if you can run 9, you may be able to run 10 acceptably.  It’ll be a question of whether you’re happy with the graphics quality or you want more.

Second: yes, X-Plane 10 is more efficient at a number of very specific rendering tasks.  (For example, we have a number of much faster OBJ paths, and improved memory use for draped meshes and forests.) But there are a few reasons why you might not see the win:

  1. In some cases, the efficiency only helps certain parts of the system.  If we make forests use less memory, and you turn forests off, you get no memory savings compared to version 9.  The performance work is specific to subsystems, not across-the-board.
  2. In some cases, we made the system more efficient and then promptly “spent” that efficiency by drawing more stuff.  For example, we can draw a lot more cloud vertices per frame, but the new weather system makes more cloud puffs.  So the system is more efficient but you need that efficiency to handle the more complex effects.
  3. A few of the new effects are always on. If something is expensive, I’ve tried to leave it out of the lowest settings, but there are some effects that don’t have an off switch.  For example, X-Plane 10 always runs with a linear lighting model – and at the lowest setting this still costs a few percent of your GPU.
  4. The rendering settings don’t match up between version 9 and 10.  “Tons” of objects doesn’t mean the same thing in versions 9 and 10.  The art assets aren’t even remotely comparable.  So if you send me a screenshot of your rendering settings in version 9 and 10 and ask why your framerate is different, I am going to politely direct you to what you actually see on the screen, which will be quite different.

This is all pretty normal for a major version.  I try not to raise the cost of minimum rendering during a version run so that everyone can update without buying new hardware.  So when a major version and hardware spec reset comes along, we have to normalize our configuration a bit.

Finally, I’ve said this before but: I am not going to answer any questions about “will my machine run well with X-Plane 10.”  X-Plane 10 isn’t done, I don’t have your machine, and what defines good performance has everything to do with what rendering settings you select.

(See also the thread on the org where a user put in a big GPU upgrade and felt like he got nothing because he couldn’t increase object count.  He could get better FSAA settings, but unlike some users, he just didn’t care.  Many other users won’t run with anything lesst han 4x.  The sim has too many options and user preferences are too varied to define “good”.)

* X-Plane 10 will require a graphics card that has programmable pixel shaders – if you are still nursing a fixed-function graphics card, you won’t be able to run version 10.

Posted in Hardware by | 52 Comments

What’s This Whole PCIe Thing About, Anyway?

I’ll try to summarize some of our hardware findings for X-Plane 10 over the next few posts.  But in my previous post I mentioned that the new MacBook Pros have only an 8x PCIe connection to the discrete GPU (that is, the nice GPU that isn’t built in to the CPU, the one you want to fly X-Plane with) and this got a bit of attention.

So it begs the question: what is this PCIe bus and why do we need to  care all of a sudden?

The PCIe bus is the connection between the CPU/main memory and your graphics card (with its memory and GPU).  It is the bottleneck through which all communications must flow – sometimes every frame, sometimes every now and then.

PCIe slots are named by the number of lanes (e.g. 16x means 16 lanes) – each lane has fixed capacity (which is doubled in PCIe 2.0).  So a graphics card in a 16x slot drink data from your computer at double the rate of one in an 8x slot – it’s an extra wide straw.

(Nerds: I realize this is about the worst description of the PCIe bus you will ever find.  Go read Wikipedia!)

What Do We Use the PCIe Bus For?

X-Plane needs the PCIe bus to:

  • Send the instructions to draw each frame to the GPU.
  • Transfer any textures, new OBJ meshes, and other data that will be held in VRAM.  The data is born on the CPU, goes over the PCIe bus once, and then lives in VRAM.
  • Send to the GPU anything that changes every frame to the GPU.  For example, smoke puffs and car headlights have to go over the PCIe bus every frame because they are constantly changing.
  • Send to the GPU mountains, forests and other non-repeating geometry.  This data gets sent every frame.

If the sum of all of the stuff on that list gets too big, your framerate drops as the CPU and GPU both wait data to make it over the bus.  In other words, the bus can at times be the bottleneck in terms of framerate.

If you set your rendering settings near the maximum that your computer can handle and get the occaisional stutter, that may be X-Plane running out of PCIe bus bandwidth.  As you fly to a region with new textures that haven’t been used before, the OpenGL driver will transfer our textures over the PCIe bus from system RAM to VRAM.  If the PCIe bus is already nearly maxed out, the extra traffic of those textures is going to temporarily hurt framerate – sometimes in the form of a stutter or pause.

Are You Sure You Know What You’re Doing?

At this point those of you who know some things about 3-d graphics are shouting at your monitors: why are you guys transferring the mountains and forests over the PCIe bus every frame?  Why not just put them in VRAM, since they don’t change?

That’s a good question and if you have a better solution than the one we use, I’d love to hear it.

The problem is this: OpenGL doesn’t give us a good way to prioritize which meshes (VBOs) stay in VRAM and which ones are purged out when we run out of VRAM.  If we put every mesh in the sim into VRAM, framerate gets better (because we aren’t using the PCIe bus) right up until we run out of VRAM.  At that point the OpenGL driver freaks out and starts throwing out textures to make room for meshes, and then the textures have to be sent back over the PCIe bus, and we end up in a world of hurt.  We end up in a state of texture thrash as we have too much “stuff” for VRAM and framerate falls off of a cliff.

The real problem is this: X-Plane has no idea how much VRAM is available for its own use.  Sure the card might have 256 MB, but how much is being used by the OS window manager for those translucent window effects, or by other applications?  We can’t even add up how much VRAM we use with ultimate precision because we don’t know the granularity of allocation on the video card (there’s real overhead for VBOs being rounded up to the VM page size, for example) or whether side buffers like a hierarchial Z buffer have been allocated.

X-Plane works around this with a simple rule: all OBJs go to VRAM, because their geometry is likely to be repeated, and non-repeating geometry, like forests and mountains, stay in system RAM and go over the bus.

This heuristic actually works pretty well in X-Plane 9 – we have enough bandwidth to transfer all of that “stuff” once per frame, and we tend not to run out of VRAM and thrash.

Why Does X-Plane 10 Want more PCIe Bus Bandwidth?

X-Plane 10 is hungrier for bus bandwidth for three reasons:

  1. The OBJ engine’s performance has been improved a lot.  In the past, we’d run out of CPU capacity (to draw OBJs) long before we ran out of bus bandwidth.  This isn’t always the case with X-Plane 10.  The graphics are always held back by their weakest link.  If you have a strong GPU (and low effects settings) and the OBJ engine is efficent, the PCIe bus is the weakest link.
  2. The art assets are more detailed and thus contain more vertices.
  3. Shadows.

When shadowing is on we have to draw the entire world multiple times, once to build shadow maps and once to draw the real world.  So shadowing can double (or even triple or worse) our bus bandwidth usage.  We didn’t have that kind of free capacity on the bus in the first place.

We’re still working on the engine, art assets, and performance, so my hope is that we’ll find ways to cut down bus use (especially with shadows).  And there has to be one slowest part of the system – as of this writing, the PCIe bus is often it.

Posted in Development, Hardware by | 25 Comments

X-Plane, SLI and CrossFire

In my previous post I described some of our findings for X-Plane 10 with respect to GPUs.  This begs the question we get asked all the time: what about SLI/Crossfire?

For those of you not familiar with SLI and CrossFire, they are technologies (from NVidia and AMD respectively) that use two graphics cards to share the load of drawing a 3-d scene.  The idea is to double the shading power of your graphics system by having each card render every alternate frame.*  You can get SLI/CrossFire with two GPUs and an appropriate motherboard, or by buying one of the monstrous “x2” GPUs.

Now to try to answer some often-asked questions:

Can X-Plane take advantage of Crossfire/SLI?

No.  Neither X-Plane 9, nor 10.0, will be capable of running with Crossfire or SLI.  From what I can tell, there are a few sites in the code that need to be reworked a bit to be ready for these technologies.  If you have an SLI/Crossfire setup, I would expect you to get the same framerate with only one of the GPUs.

Will X-Plane 10 ever take advantage of Crossfire/SLI?

Maybe someday.  If we can get our code clean enough to work with these technologies, I will post an update on this blog.  But I can’t promise anything – for all I know we may someday hit some horrible show-stopping problem.

Would SLI/Crossfire be useful for X-Plane?

Not for X-plane 9.  X-Plane 9 can’t even max out a single GPU from the previous generation’s top end cards, so there’s really no need for two of them.

For now there are resolutions where two GPUs would be necessary to get better frame-rate.  If we can run 2560 x 1440 at 20-30 fps on one card, it would in theory be nice to run at 40-60 fps on two.

But the next generation of GPUs is on the way, so it may be that the next generation of cards will be fast enough on their own.

Should I Buy an SLI/Crossfire setup?

Not for X-Plane – we can’t take advantage of it right now.

Here’s another way to look at it.

  • If you wanted 2400 GFLOPs on your GPU in August of 2008, you could buy the Radeon HD 4870 x2, which is basically two 4870s jammed together on a single card via Crossfire.  This would set you back $549.
  • 13 months later, in September of 2009, AMD released the 5870, which could put out 2720 GFLOPs as a single GPU for $400.

The performance curve for GPU power is really quite steep, and a dual-GPU system typically costs at least twice as much as two of the single-GPU form.  That’s a lot of money to pay for fill rate that will be available in about 18 months in single-card form.

So the short version is: we don’t support SLI/Crossfire yet.  Someday we may work with these technologies, but even if/when we do, they’ll only make sense if you really like high resolutions and framerates and money isn’t an object.

* SLI can operate in “split-frame” mode where each video card takes half of a frame, but this is not so good because a full frame of geometry must be sent to each card for each frame, effectively doubling PCIe bus use.  In alternate-frame mode, each card only sees every other frame, and thus only needs half the bandwidth – both cards together use the same bandwidth as one card would have.

Posted in Development, Hardware by | 13 Comments