Multicore and Version 10

Over the last two years, we've been working on the X-Plane rendering engine, setting up the code to take advantage of multiple cores when possible. Most of these changes are in X-Plane 9 already: multi-core creation of 3-d scenery, multi-core loading of scenery, multi-core loading of textures.

X-Plane 10 will leverage this work, pushing even more work to multiple cores. And yet, nine women cannot have a baby in one month. The ultimate limit on framerate will be based on the performance of one core pushing data to your graphics card.

So how many cores do you need, and is it better to have a few fast cores or more slow cores?

I can't give you a firm answer, because I don't know how important money is to you, I don't know which rendering settings you care most about, and X-Plane 10 isn't finalized. (And even if it was, we often improve performance in patches.) But I can suggest our attitude to how cores are used.

A Graphic Analogy

With graphics cards, the companies target different markets. The "enthusiast" market is the top end, where money is no object and maximum performance is the goal. Below that you have "performance" cards (a good value for the money but not as fast) and "mainstream" (which by video game standards means "slower than snot" - main stream users don't need fast 3-d graphics to check email).

When it comes to rendering features, we expect X-Plane to be efficient enough to meet the performance expectations of a given slice of the market. In other words, if you have bought a top-level graphics card, we need to be efficient enough to let you run at 8x FSAA on a huge screen with per pixel lighting - that's what is expected of the enthusiast crowd and that's what the cards are built for.

But if you have a mainstream card and get 5 fps with per pixel lighting, well, too bad. You've got a cheap, low powered card, you need to dial down the sim. Here our goal is only to give you a way to run X-Plane at all. (And frankly, if X-Plane could run at 60 fps on a mainstream card, it means the max rendering settings don't take advantage of top end hardware!)

Core Considerations

At this point we expect pretty much any modern computer to have at least two cores, and users with single core machines are going to have to make serious graphic quality sacrifices to run X-Plane. (This is already true for version 9.)

When it comes to version 10, I think we will categorize "a lot of cores" (e.g. 4, 6, or more) as enthusiast - some of the top level rendering options may not function well with less than four cores, but dual core machines should at least run decently with some rendering options enabled.

How far we go toward utilizing really high core count (Austin upgraded to the new Mac Pro and now has 8 hyper-threaded i7s) I don't yet know. My guess is that we will get at least some measurable benefit from up to 8 cores.

Trading off clock speed for core count is a difficult choice. Obviously if you had a choice of one core that was twice as fast as a 2-core CPU, you'd take the speed - you're getting the same total computing power but the clock speed can help frame-rate. But the trade-off is almost never formulated like this, and it's too soon to have hard data from the sim itself.

For what it's worth, the latest generation of CPUs is really fast, so it is unlikely that you'd upgrade to a new CPU and not get some serious benefit, whether it comes in cores or clock-speed. The users I have heard from with new iMacs seem quite happy with their machines.

An Older Build for Regression Testing

I'm never thrilled about posting bug-swatting info on this blog; the blog is (among other things) a temporal snapshot of what's going on in X-Plane, as well as an archive; it's my hope that we'll get this problem sorted out soon, at which point this blog post will do nothing but confuse. But I digress.

There have been a number of reports from users of the sim hanging on startup with this configuration:

• A 64-bit Windows (usually Vista or 7).
• A modern ATI card running Catalyst 10-6 or 10-7 drivers.
• X-Plane 9.62rc2.
• Usually a core i7 type system.

However, I haven't been able to reproduce this, and neither has ATI.

I don't know what the problem is, but a number of variables have changed in this equation that need to be isolated: new sim, new video drivers, newer operating systems.

So if you have this configuration and can't run the sim, despite removing all third party add-ons, please download this time demo. If you can run the 945 time demo but cannot run 962, please let me know by email, and we'll isolate a defect in the sim. I have heard from some users that they can run 940, but no confirmation that 945 runs.

64-Bit? It's On the Radar

I've been working on road processing today; one of the tricky problems with OSM data is that, because an OSM map is often a collection of vectors from separate authors, the results can be a huge number of very small segments, as nearby road features from different data sources cross each other. (Basically you get "thrash" between the two vectors from different sources and our tools solve this by adding a huge number of extra vertices.)

I am trying to run this data through an algorithm called Iterative Snap Rounding (ISR) to reduce this mess of vertices, and for the purpose of this blog article there's one thing you need to know about ISR: it is really, really slow. So for the next few minutes, I figured I'd start poking at some of the issues that came up at the X-Plane Congress in France this summer.

One question that came up was whether/when X-Plane will go 64 bit. Here's my current thinking:

We can't drop 32-bit X-Plane. Too many users have a 32 bit operating system, or a 32-bit CPU. One thing I have been resisting for X-Plane 10 is a ratcheting up of the system requirements to only top-end game machines. While 64 bit is becoming more prevalent and has the potential to be a big win for users who load the sim up with third party add-ons and have a high-end graphics card, plenty of people buy a computer first and then discover X-Plane. Those users will often have a system that is low end (by X-Plane standards).

If we start cranking the system requirements (you have to have 64-bit, you have to have a DX10 class graphics card, you have to have 2 GB of RAM) then more users who might discover X-Plane won't even be able to run the demo, and that will be bad for X-Plane's growth.

So the question is not "when will we switch from 32-to-64 bit" - it is "when will we support both 32 and 64 bit."

I think we will get there during the version 10 run, but I don't think it's that likely that we'll ship 64 bit right out of the box. 64 bit is more of a performance enhancement* than a new feature. The features we have strong motivation to get into 10.0 are:

• Anything that raises the system requirements, because we don't want to raise system requirements after we ship in a free update.
• Anything that enhances the authoring SDK, where it might be useful for authors to know that every version of X-Plane 10 has a feature.
• Of course, we want to ship any feature that looks really good and gets people excited.
• Foundation features that support other featuers have to go in first. So some enhancements that will ship in 10.0 are there because without them other tech couldn't be rolled out.

64 bit is important, but it is a feature that only helps some of the user base, and helps by making the sim more expandable; the sim is still usable without it. So we'll get there, but new features are a zero sum game so I think 64 bit is more likely to be a free patch than in-the-box.

(At this point I expect the various 64-bit OS users who have been asking for a 64-bit app for years to flame the heck out of me and point out that I am a cranky old bastard who doesn't realize that 64 bit is now everywhere and totally pervasive and that this is therefore the most important thing we could possibly do. Before you dig in, hang on one second, let me put on my asbestos flame-retardant jacket. Okay...fire away. :-)

Oops...ISR just finished...with a seg fault. Gotta go!

* As a performance enhancement, 64 bit is a weird one; because a 64-bit app uses more memory for pointer-based structures, the same data structures become larger, thrashing on-chip caches more. The real benefit to 64 bits is to allow X-Plane to use more than 3 GB of physical RAM.

DDS Has No Gamma (Which is Very Sad)

A few years ago I blogged about gamma correction for png files. Here's the very, very short version:

• PC and Mac monitors are calibrated differently. Dark tones on a PC appear darker than on a Mac. The curve of how colors are mapped to the monitor is the gamma correction curve, typically expressed as a number like 1.8 for Mac and 2.2 for PC. The higher the number, the more Gothic your dark tones.
• A png file can have a gamma value written into the file, which tells X-Plane (and anyone else) what kind of monitor the png was drawn on. This lets X-Plane brighten a png from a Mac when you are on a PC, and darken a png from a PC when you are on a Mac.
• If you leave off the gamma value on your png, we assume 1.8 (Mac) which can be bad if you're a PC author.

While this is confusing, it was an improvement over the BMP situation (where everything was set up for a Mac and PC users had to simply crank their monitor brightness).

In version 9 we added a gamma correction setting to X-Plane. The setting you enter in the rendering settings is how "dark" your monitor is (bigger number = darker). We then attempt to compensate by lightening the textures more; thus a bigger number results in a lighter looking X-Plane (because you told us your monitor was dark and we tried to "fix it").

There are two other developments since the original png situation which have unfortunately been a step backward in terms of X-Plane color correction.

DDS and Gamma

The handling of DDS and gamma is, to put it mildly, quite problematic. The problem is two-fold:

• DDS doesn't actually have gamma information, so we can't tag DDSes as having originated on Macs and PCs. So we assume a DDS is authored at a gamma of 1.8 (Mac). I think DDSTool correctly does a gamma correction when grinding files at other gammas.
  
• (If you are a real graphics programmer, please do not read this next sentence.) X-Plane attempts to adjust the color of the DDS in its compressed form. This is a big hack designed to keep framerate high, but it's really not a very good idea. The result can be color distortion when a DDS is viewed at 2.2 gamma.

So that's not good, but what happened next made things a lot worse.

Apple Goes Gothic

Apple adopted the sRGB color profile for OS X 10.6, which has a gamma curve of about 2.2. So now the situation with DDS is particularly ugly:

• All DDS are authored at a gamma of 1.8.
• All users are moving toward a display gamma of 2.2.
• X-Plane thus has to always color correct, but its color correction is low quality for performance reasons.

This is...very sad.

There are two things we can do about this:

• In the short term, we can provide post-decompression color correction. This will cost a (hopefully) small amount of framerate and improve color fidelity for users with 2.2 gamma. This is the kind of thing that any user with a modern card would want, but that we might make optional for users with very old hardware.
• In the long term, we can provide a gamma calibration in the text files that wrap DDS files so that authors can mark their DDS as already being 2.2. This will mean that for most users X-Plane won't have to do any color correction at all.

Where Has All My VRAM Gone?

In the past I have suggested that there is a limit to the value of additional VRAM when buying a graphics card. When I posted this, Nicholas from the org emailed me to point out that with third party add-ons VRAM was a lot more important.

At the time I wasn't really convinced, but I've finally come around; it takes a while for the trend to get back to me. (I just don't have time to look at everyone's add-ons the way I used to 4 or 5 years ago.) It seems clear that airplane authors (and to some extent scenery authors) are using VRAM pretty aggressively. If you want to use third party add-ons and you care about texture res and texture sharpness, spring for some VRAM. It doesn't cost as much as it used to, and authors are starting to use it.

What Lives in VRAM

Bear in mind that in any discussion of how your video card operates, anything I post is informed speculation. The driver provides an abstraction (OpenGL) of what the hardware does, and a lot of the bookkeeping isn't visible to X-Plane at all. So what I am describing is typical of past video drivers that we have had insight to in the past, but it's not universal, and it's not at all guaranteed. (X-plane can't demand any of this behavior of the video driver.)

In order of how "stuck" in VRAM things are we have:

• Video memory used for on-screen rendering. Depending on rendering settings you can lose anywhere from 12 to 24 MB of VRAM per million pixels on screen. So if you're running at 1920 x 1200, you might be using 50 MB of VRAM just for the screen. If you use FSAA, you're going to chew up VRAM even more aggressively. (Costs vary depending on the scheme; you might lose 4-16 MB x the FSAA level per million pixels on screen, depending on your GPU and driver.)
  
• Off-screen rendering for things like the water reflections, the panels, the cloud shadows, the airplane shadow, etc. These don't have to be in VRAM all of the time, but they have to be in VRAM almost all of the time. Because they are created by the GPU, the driver tries hard not to move these out of VRAM. You might lose 6 to 16 MB of VRAM for these, depending on the airplane you use and settings. (Given 4 1024x1024 panel regions, the panel will chew up 32 MB!)
• Textures end up in VRAM, but only when they are used. The key here is "working set". Only texures that are drawn need to be in VRAM, so over time stuff that isn't on screen will be removed from VRAM. This is why when you see "600 MB of texture memory" in the rendering settings, there is no need to panic. The working set is usually much smaller.
• OBJ geometry actually lives in VRAM too, sometimes. Again this is a working set issue; objects that aren't drawn don't get cached there.
• Textures from airplanes and scenery packages that are not loaded don't ever end up VRAM or even system memory; we only load what we need. Paged orthophotos have their resolution reduced while you fly, which makes their VRAM footprint quite small, even when drawn.

There are a few things authors and users are doing now that use up a lot of VRAM.

• Monitors have gotten bigger; the VRAM used for the screen itself can never be swapped out, so the advent of the 1920x1200 LCD has taken its toll.

• Since the panel texture is drawn off-screen, the panel texture is in an expensive category of VRAM use. Authors can limit the cost of this by using a single 1024x1024 panel region texture, if possible.

• There is a hidden cost here: we pack together instrument textures into "atlases" to help with performance. The problem is that we pack for fit. Some of your instruments may be hidden but loaded into VRAM anyway because they sit in the same atlas texture as other instruments that are drawn. Thus you may be paying for the VRAM used by your entire panel even if a lot of it is hidden.

• Because a lot of this VRAM is going to airplanes, reducing texture resolution doesn't have as much impact as it used to; X-Plane tries to keep the user's plane's resolution as high as possible since it is viewed up close. The panel cannot have its resolution reduced at all.

But It Works Sometimes

I think what drives users crazy about VRAM exhaustion is that X-Plane will sometimes run smoothly, and then fail later. And sometimes really strange things, like moving X-Plane to the background, then the foreground, or changing liveries or rendering settings in a trivial way, will change performance.

I have discussed this a bit in past posts. But the key here is "working set":

• In any one frame, we can access everything that is permanently in VRAM, plus as much data as we can put through the PCIe bus from the CPU to the GPU.
• We only need to access data in the working set (what is on screen).
• Some of VRAM is permanently used (e.g. memory for the screen itself).
• We lose PCIe bandwidth to both drawing from main memory (terrain is in your system memory and must go over the PCIe bus per frame) and from bandwidth spent juggling textures.

So the actual maximum throughput will have a lot to do with whether the video driver makes good decision about what lives in VRAM and what does not.

But how does the video card know what should be in VRAM? The answer is that it has to guess. It looks at frames going by and tries to use heuristics (that is computer-science geek speak for "carefully formulated wild guesses") to decide what goes in VRAM and what does not. When the heuristics happen to make good decision, your video card kicks ass. And when it does not, your framerate tanks.

The only way to guarantee good framerate is to use so little VRAM that everything that needs to be in VRAM can be in VRAM, without depending on the video driver to make lucky guesses with its juggling.

And this helps us understand why strange things like livery reloads and backgrounding the sim can affect framerate (for better or worse). These operations seriously reshuffle VRAM - either by deleting textures and loading new ones, or by forcing everything out of VRAM so the video driver must try to repack video RAM all over again.

Unfortunately as a user this means that there's not much you can do about this as a user. The main things would be: reduce screen size or FSAA or texture resolution, use fewer add-ons, or get more VRAM. Those peak bursts of framerate you see, they're not going to be sustainable .

Ray Tracing is the Technology of the Future...

...and it always will be!

Seriously, first, let's be clear: my opinions do not matter! X-Plane is a small program in a large market (game/graphics hardware) and as I've said before, flight simulators are not the early adopters of new tech. So (and this is a huge relief to me) I can do my job without correctly predicting the future of computer graphics.

Keep that in mind as I mouth off regarding ray tracing - I'm just some guy throwing tomatoes from the balcony. X-Plane doesn't have skin in the game, and if I prove to be totally wrong, we'll write a ray tracer when the tech scales to be flight simulator ready, and you can point to this post and have a good laugh.

With that in mind, I don't see ray tracing as being particularly interesting for games. I could make arguments that rasterization* is significantly more effecient, and will keep moving the bar each time ray tracing catches up. I could argue that "tricks" like environment mapping, shadow mapping, deferred rendering, and SSAO have continued to move effects into the rasterization space that we would have thought to be ray-tracing-only. (Heck, ray tracing doesn't even do ambient occlusion particularly well unless you are willing to burn truly insane amounts of computing power.) I could argue that there is a networking effect: GPU vendors make rasterization faster because games use it, and games use it because the GPU makers have made it fast. That's a hard cycle to break with a totally different technology.

I don't really have the stature in the world of computer graphics to say such things. Fortunately John Carmack does. Read what he has to say. I think he's spot on in pointing out that rasterization has fundamental efficiencies over ray tracing, and ray tracing doesn't offer enough real usefulness to overcome the efficiency gap and the established media pipe-line.

The interview is from 2008; a few months ago Intel announced that first-generation Larrabee hardware wouldn't be video cards at all. For all effective purposes from a game/flight simulator perspective, they basically never shipped. So as you read Carmack's contents re: Intel, you can have a good chuckle that Intels claims have proven hollow due to the lack of actual hardware to run on.

I will be happy to be proven wrong by ray tracing, or any other awesome new technology. But I am by disposition skeptical until I see it running "for real", e.g. in a real game that competes with modern games written via rasterization. Recoding old games or showing tech demos doesn't convince me, because you can recode an old game even if your throughput is 1/20th of rasterization, and you can hide a lot of sins in a tech demo.

Heck, while I'm putting my foot in my mouth, here's another one: unlimited detail. Any time someone announces the death of the triangle, I become skeptical. And their claim of processing "unlimited point cloud data in real time" strikes me as an over-simplification. Perhaps they can create a smooth level of detail experience with excellent paging characteristics (which is great!) but the detail isn't unlimited. The data is limited by your input data source, your production system, the limits of your hardware, etc. Those are the same limits that a mesh LOD system has now. In other words, what they are doing may be significantly more efficient, but they haven't made the impossible possible.

That is my general complaint with most of the "anti-rasterization" claims - they assume that mesh/rasterization systems are coded by stupid people - and yet most of the interesting algorithms for rasterization, like shadow mapping and SSAO, are quite clever. Consider these images: saying that rasterization doesn't produce nice images while showing Half Life 2 (2004, for the X-Box 360) is like saying that cars are not fuel efficient because a 1963 Cadillac got 8 mpg. The infinite detail sample images show a lot of repeated geometry, something that renderers today already do very well, if that's what was desirable (which it isn't).

Finally, is in favor of sparse voxel octrees (SVOs). SVOs strike me as the most probable of the various non-mesh-rasterization ideas floating around, and an idea that might be useful for flight simulators in some cases. To me what makes SVOs practical (and in defense of the unlimited detail folks, their algorithm potentially does this too) is that it can be mix-and-matched with existing rasterization technology, so that you only pay for the new tech where it does you some good.

* Rasterization is the process of drawing on the screen by filling in the pixels covered by a triangle with some shading.

Ray Tracing: Shoot Before You Fly

I'll take a break from iPad drivel for a few posts; at least one or two of you don't already own one. (Seriously, it's simply easier to blog about X-Plane for iPad because it is already released; a lot of cool things for the desktop are still in develpment.)

In response to my comments on water reflections in X-Plane 950, some users brought up ray tracing.

My immediate thought is: I will start to think more seriously about ray tracing once it becomes the main technology behind first person shooters (FPS).

Improvements in rendering technology come to FPS before flight simulators (and this is true for the combat sims and MSFS series too, not just us). Global shadows, deferred rendering, screens-space ambient occlusion...the cool new tricks get tried out on FPS; by the time they make it into a flight simulator the technology has moved from "clever idea" to "standard issue."

Consider that X-Plane now finally has per-pixel lighting. Why didn't we have it when the FPS first did? Well, one reason is that the FPS were cheating. If you look at the papers suggesting how to program per-pixel lighting, at the time there were all sorts of clever techniques involving baking specular reflections into cube maps and other such work-arounds to improve performance. These were necessary because titles at the time were doing per-pixel lighting on hardware that could barely handle it. X-Plane's approach (as well as other modern games) is to simply program per pixel lighting and trust that your GeForce 8800 or Radeon 4870 has plenty of shader power.

I believe that the reason for the gap between FPS and flight simulators come from two sources:

1. Viewpoint. You can put the camera quite literally anywhere in a flight simulator, and thus the world needs to look good from virtually any position. By comparison, if your game involves a six foot player walking on the ground (and sometimes jumping 10 feet in the air) you know a lot about what the user will never see, and you can pull a lot of tricks to reduce the performance cost of your world based on this knowledge. (This kind of optimization applies to racing games too.

   To give one simple example of the kind of optimization a shooter can make that a flight simulator cannot, consider "portal culling". A portal-culled world is one where the visibility of distinct regions have been precomputed. A trivial example is a house. Each room is only visible through the doors of the other rooms.* Thus when you are walking through a room, virtually no other room is being drawn at all. The entire world is only 20 by 20 meters. Thus the developers know that they have the entire hardware "budget" of computing power to dedicate to that one room and can load it up with effects, even if they are still expensive.

   (A further advantage of portal culling is a balance of effects. Because rooms are not drawn together in arbitrary combinations, the developers may find ways to cheat on the lighting or shadowing effects, and they know nothing will "clutter" the world and ruin the cheats.)**

2. Often the FPS will have pre-built content, rather than user-configurable content. Schemes like portal culling (above) only work when you know everything about the world ahead of time and can calculate what is visible where. The same goes for many careful cheats on visual effects.

   But a flight simulator is more like a platform: users add content from lots of different sources, and the flight simulator rendering engine has to be able to render an effect correctly no matter what the input. This means the scope of cheating is a lot smaller.

   Consider for example water reflections. In a title with pre-made content, the artists can go into the world in advance and mark items as "reflects", "doesn't reflect", reducing the amount of drawing necessary for water reflections. The artist simply has to look around the world and say "ah - this mountain is no where near a lake - no one will notice it."

   X-Plane can't make this optimization. We have no idea where there will be water, or airports, or you might be flying, or where there might be another multiplayer plane. We know nothing. Everything is subject to change with custom scenery. So we can't cheat - we have to do a lot of work for reflections, some of which might be wasted. (But it would be too expensive in CPU power to figure out what is wasted while flying.)

Putting it all together, my commentary on ray-tracing is this: the FPS will be able to integrate small amounts of ray tracing first, because they will be in a position to deploy it tactically, using it only where it is really necessary, in hybrid ray-trace + rasterized engines. They'll be able to exclude big parts of the scene from the ray tracing pass, improving performance. They'll be able to "dumb down" the quality of the ray trace in ways that you can't see, again improving performance. The result of all of this will be some ray tracing in FPS when the hardware is just barely ready.

For a flight simulator, it will take longer, because we'll need hardware that can do a lot more ray tracing work. We won't know as much about our world, which comes from third party content, so we won't be able to eliminate visually unimportant ray traces. Like deferred rendering, shadow mapping, SSAO and a number of other effects, flight simulators will need more computing power to apply the effects to a world that can be modified by users.

(Is ray tracing even useful, compared to rasterization? I have no prediction. Personally I am not excited by it, but fortunately I don't have to make a good guess as to whether it is the future of flight simulation. The FPS will be able to, by effective cheating, apply ray tracing way before us, and give us a sneak peak into what might be possible.)

* There never are very many windows in those first person shooters, are there?
** To be clear: there is nothing negative about the term "cheat" in computer graphics. A way to cheat on the cost of an algorithm means the developers are very good at their jobs! "Cheating" on the cost of algorithm means more efficient rendering. If the term cheating seems negative, substitute "lossy optimization".

New Toys

This isn't supposed to be a coding blog, but users do ask about DirectX vs. OpenGL, or sometimes start fights in the forums about which is better (and yes, my dad can beat up your dad!). In past posts I have tried to explain the relationship between OpenGL and DirectX and the effect of OpenGL versions on X-Plane.

At the Game Developers Conference 2010 OpenGL 4.0 was announced, and it looks to me like the released the OpenGL 3.3 specs at almost exactly the same time. So...is there anything interesting here?

A Quick Response

In understanding OpenGL 4.0, let's keep in mind how OpenGL works: OpenGL gains new capabilities by extensions. This is like a new item appearing on a menu at your favorite restaurant. Today we have two new specials: pickles in cream sauce, and fried potatoes. Fortunately, you don't have to order everything on the menu.

So what is OpenGL 4.0? It's a collection of extensions: if an implementation has all of them it can call itself 4.0. An application might not care. If we only want 2 of the 4 extensions, we're just going to look for those 2 extensions, not sweat what "version number" we have.

Now go back to OpenGL 3.0, and DirectX 10. When DX10 and the GeForce 8800 came out, nVidia published a series of OpenGL extensions that allowed OpenGL applications to use "cool DirectX 10 tricks". The problem was: the extensions were all NVidia specific tricks. After a fairly long time, OpenGL's architectural review board (ARB) picked up the specs, and eventually most of them made it into OpenGL 3.0 and 3.1. The process was very slow and very drawn out, with some of these "cool DirectX 10 tricks" only making it into "official" OpenGL now.

If there were OpenGL extensions for DirectX 10, who cares that the ARB was so slow to adopt these standards proposed by NVidia? Well, I do. If NVidia proposes an extension and then ATI proposes a different extension and the ARB doesn't come up with a unified official extension, then application like X-Plane have to have different code for different video cards. Our work-load doubles, and we can only put in half as many new cool features. Applications like X-Plane depend on unity among the vendors, via the ARB making "official" extensions.

So the most interesting thing about OpenGL 4.0 is how quickly they* made official ARB extensions for OpenGL that match DirectX 11's capabilities. (NVidia hasn't even managed to ship a DirectX 11 card yet, ATI's HD5000 series has only been out for a few months, and OpenGL already has a spec.) OpenGL 4.0 exposes pretty much everything that is interesting in DirectX 11. By having official ARB extensions, developers like Laminar Research now know how we will take advantage of these new cards as we plan new features.

Things I Like

So are any of the new OpenGL 3.3 and 4.0 capabilities interesting? Well, there are three I like:

1. Dual-source blending. It is way beyond this blog to explain what this is or why anyone would care, and it won't show up as a new OBJ ATTRibute or anything. But this extension does make it possible to optimize some bottlenecks in the internal rendering engine.

2. Instancing. Instancing is the ability to draw a mesh more than one time (with slight variants in each copy) with only one instruction to the graphics card. Since many games (like X-Plane) are limited in their ability to use the CPU to talk to the graphics card (we are "CPU bound" when rendering) the ability to ask for more work with fewer requests is a huge win.

   There are a number of different ways to program "instancing" with OpenGL, but this particular extension is the one we prefer. It is not available on NVidia cards right now. So it's nice to see it make it into the core spec - this is a signal that this particular draw path is considered important and will get attention.

3. The biggest feature in OpenGL 4.0 (and DirectX 11) is tessellation. Tessellation is the ability for the graphics card to turn a crude mesh with a few triangles into a detailed mesh with lots of triangles. You can see ATI demoing this capability here.

There are a lot of other extensions that make up OpenGL 3.3 and 4.0 but those are the big three for us.

* who is "they " for OpenGL? Well, it's the architectural review board (ARB) and the Khronos group, but in practice these groups are made up of employees from NVidia, ATI, Apple, Intel, and other companies, so it's really a collective of people involved in OpenGL use. There's a lot of input from hardware vendors, but if you read the OpenGL extensions, you'll sometimes see game development studios get involved; Transgaming and Blizzard show up every now and then.

X-Plane Is An All You Can Eat Buffet

I have blogged in the past regarding the rendering settings in X-Plane, but this seems to come up periodically, so here we go again. Invariably someone asks the question: "what computer do I have to buy to run X-Plane with all of the sliders set to maximum?"

I now have an answer, in the form of a question: "How hungry do you have to be to clean your plate at an all-you-can-eat buffet?"

There is no amount of hungry that will ever be enough to eat all of the food at an all you can eat buffet - you can always ask for more. And when it comes to rendering settings and global scenery, X-Plane is (whenever possible) the same way. You can always set more traffic, more birds, more objects, more FSAA.

Now the all-you-can-eat buffet doesn't have infinite amounts of food in the building - just enough that they know that they won't run out. And X-Plane is the same way. There is a maximum if you set everything all the way up, but we try to make sure that no one is going to hit a point where they want more eye candy but they've maxed out the settings. Eat all you want, we've got more.

Why on earth would we set up X-Plane like this? The answer is choice.

If you go to an all you can eat buffet, you can fill up on nothing but potatos, or you can have five pieces of chicken. It's up to you. X-Plane is the same way - you decide if you want objects to be visible farther away or more densely. Would you rather have roads or trees? Birds or high frame-rate? You decide!

Not everyone's appetite is the same, and not everyone's taste is the same. This is very true when it comes to flight simulation. There are huge variations in hardware capability, target framerate (some users don't mind 20 fps, some demand 80 fps) and in what part of the visual experience people care about most (objects vs. FSAA vs. visibility distance, etc).

Given such a heterogeneous environment, the only way to meet the needs of a wide group of users is to present choice, and make sure that we have enough of everything.

So when you go to set the rendering settings, don't think that setting objects to anything less than maximum is like only eating half the steak you bought at a steak-house. Rather, the rendering settings are like picking which food from the buffet makes it to your plate. You choose how much you want based on what you can consume, and you pick and choose what is most desirable to you. And like an all you can eat buffet, don't eat too much - the results won't be pleasant!

To Tune Framerate, You Have To Hit Rock Bottom

I have blogged about this before, but I keep seeing this issue come up in the forums, so I want to go over it again. If you want to effectively tune X-Plane to trade off maximum visual quality with desired framerate, you must first reduce your rendering settings all the way to the bottom, then work your way up. Let me explain with an analogy.

I have fallen off my motorcycle and hit my head, skinned my knee, and broken my arm; the bone is sticking right out of my skin! Ouch! So I go to the hospital and the Doctor examines me. Here is how the conversation goes:

Dr: How does your arm feel?
Me: My arm hurts so much! OUCH!
Dr: And how does your leg feel?
Me: My arm is burning and stinging! Please make it stop!
Dr: Do you feel dizzy or light headed?
Me: Please fix my arm!!!!!!!!

Clearly with a bone sticking through my skin, there is no point in doing a physical examination. My arm hurts so much that I can't tell the Doctor whether I have any other aches or pain. I feel one thing: the arm.

What does this have to do with framerate? Well, framerate is just like pain. The low framerate you see is caused by only the one worst problem with your setup. If your graphics card is a little bit overloaded, you are a hair short on VRAM, and your CPU is absolutely being killed, then the low framerate you see is totally because of the CPU. The weakest link decides your framerate. And like the Doctor, if we go trying to deal with the VRAM problem, we will see no change because it's the CPU that hurts the most.

This is what I see over and over: a user is running X-Plane, his framerate is bad, and he has turned some but not all of the settings down. At this point the user is usually pretty grumpy - his visuals now look bad and his framerate is poor.

The problem is that the user hasn't turned down the setting that really matters. This is why the first thing you need to do in order to tune framerate is to turn everything down, so that you are running with framerate at least as high as what you want for your target value. Then you can turn settings up one at a time and watch which one lowers framerate.

(Don't worry, you're not going to stay at the lowest settings. The key is just to always be turning settings up, not down.)

Here are some of the settings I see that need to be turned down but often are not.

• Full screen anti-aliasing. (FSAA) Always turn FSAA down to none. FSAA will kill fps on any graphics card that is fill rate limited.
• Pixel shader effects - every one of these should be turned off to start. And when you do start them, try them one at a time and have the water reflections off - work your way up in small steps. The gap from shaders without volumetric fog, shadows, reflections and per pixel lighting to shaders with all of these effects is huge!
• Turn objects all the way down to default, or even off. If your CPU is the problem, objects could be a factor.
• Leave texture compression on in your "rock bottom" settings. Texture compression improves fps and lowers visual quality, so having the check box be on is the minimal setting.
• Don't run at a huge screen res or FOV. Run 1024x768 and 50 degrees FOV.

What happens if you turn everything down and you still see 19 fps? Now it's time to investigate your video drivers and control panel settings. If your setup is even remotely better than minimum hardware, it should scream when all of those settings are turned down. If you still see low fps, check drivers, check control panel settings. There are a lot of control panel settings, for example, that will completely kill framerate.

Developer Hardware

So...just how awesome is my main development machine? Not that awesome.

Periodically users ask me what my setup is. Usually the user wants to set up a really nice machine to run X-Plane at its best and figures "let's find out what the guys who write X-Plane have."

But ... my main development machine is definitely not selected to be the best possible X-Plane machine. I put together a system to:

• Debug X-Plane productively.
• Test all aspects of X-Plane.
• Create the global scenery as fast as possible.

In practice this means a Mac Pro with 8 cores, 12 GB of RAM, a lot of hard drive, and not particularly fast CPUs. It's a machine that can churn out 8 DSFs at once. There's no need for me to keep upgrading the CPU type itself - it's the 8 way parallelism that makes DSF creation fast. (To Apple's credit, the IO in the machine is fast enough to keep all 8 cores busy!)

Being an Intel Mac, the machine is triple-bootable into Vista (someone in the company has to have it) and Ubuntu Linux.

Right now I have a Radeon 4870 in the machine and an 8800 on my shelf. I do recommend the 4870 to Mac users - it's a very nice card. But for my purposes it has one annoying problem: it takes up the space for the second graphics card slot and both power connectors...I may go back to a lower powered card so I can have one NV and one ATI card in the machine at the same time - a great configuration for debugging. (I do not recommend that any user ever mix graphics card brands..."don't try this at home", etc.)

Maxing out X-Plane isn't on the priority list. In particular, past these goals, the faster the machine, the less likely I am to notice a problem.

An example: during 930 development, for some period of time, we had accidentally set the code to allocate an extra 1 GB of RAM at startup. Oops! The embarrassing part: neither Austin and I noticed for weeks. Both of our machines have plenty of RAM, and OS X has a decent VM system, so we just ran, using a lot of memory.

Then one day I try to start X-Plane on my laptop and the whole machine nearly catches on fire. Sure enough...an extra 1 GB of RAM is being grabbed.

The moral of the story: I'd rather not have a machine that hides things from me, if it doesn't affect productivity.

NVidia Isn't Making Faster Humans

It's been a tough year for X-Plane authors. Key framing, manipulators, global lighting, baked lighting control, generic instruments, normal maps...version 9 has extended the possibilities for airplanes in a huge way. This is great for X-Plane users, and great for any author who wants to push the envelope, but there is a flip side: the time investment to make a "cutting edge" X-Plane aircraft has gone way, way up.

Here's the problem: as hardware has been getting faster, the amount of data (in the form of detailed airplane models) needed to keep the hardware running at max has gone up. But the process of modeling an airplane hasn't gotten any more efficient; all of that 3-d detail simply needs to be drawn, UV mapped and textured. Simply put, NVidia and ATI are making faster GPUs but not faster humans.

That's why I was so excited about order independent transparency. This is a case where new graphics hardware and nicer looking hardware means less authoring work, not more. (The misery of trying to carefully manage ordered one sided geometry will simply be replaced by enabling the effect.)

My Daddy Can Beat Up Your Daddy

Cameron was on FSBreak last week last week discussing the new CRJ...the discussion touched on a question that gets kicked around the forums a lot these days: which allows authors to more realistically simulate a particular airplane...X-Plane 9 or FSX.

This debate is, to be blunt, completely moot. Both FS X and X-Plane contain powerful enough add-on systems that an author can do pretty much anything desired, including replacing the entire host simulation engine. At that point, the question is not "which can do more" because both can do more than any group of humans will ever produce. As Cameron observed, we've reached a point where the simulator doesn't hold the author back, at least when it comes to systems modeling.

(It might be reasonable to ask: which simulator makes it easier to simulate a given aircraft, but given the tendency to replace the simulator's built-in systems on both platforms, it appears the state of the art has gone significantly past built-in sim capabilities.)

Graphic Leverage

When it comes to systems modeling, the ability to put custom code into X-Plane or FS X allows authors to go significantly beyond the scope of the original sim. When it comes to graphics, however, authors on both platforms are constrained to what the sim's native rendering engine can actually draw.

So if there's a challenge to flight simulation next year, I think it is this: for next-generation flight simulators to act as amplifiers for the art content that humans build, rather than as engines that consume it as fuel. The simulator features that get our attention next year can't just be the ability for an author to create something very nice (we're already there), rather it needs to be the ability to make what authors make look even better.

(This doesn't mean that I think that the platforms for building third party "stuff" are complete. Rather, I think it means that we have to carefully consider the amount of input labor it takes to get an output effect.)

NVidia: 3 Ben: 0

This is getting embarrassing - I'm at risk of getting shut out. I was able to fix the "Null texture, how" error users were seeing on NVidia hardware.

It turns out it was an uninitialized variable in code that was never used until NV changed their drivers. As far as I can tell, NV dropped support for FSAA in 16-bit mode a few months ago, at least on some of their newer GPUs. (It is also possible that the incantation necessary to get FSAA has changed a lot and I simply don't know what it is.)

So the dialog between X-Plane and the video card ran something like the Monty Python cheese shop sketch:

X-Plane: So ... can you do full screen anti-aliasing?
GeForce 8: Oh yes, of course! (Please, I'm a GeForce 8 card.)
X-Plane: Splendid! So...how about 16x FSAA?
GeForce 8: Sorry, can't I can't do that.
X-Plane: Ah. How about 8x FSAA?
GeForce 8: Sorry, can't do that either.
X-Plane: I see. Well then, how about 4x FSAA?
GeForce 8: Nope.
X-Plane: 2x FSAA?
GeForce 8: No way.
X-Plane: Ah. I see.

At this point in the dialog X-Plane would promptly lose track of what it had been doing in the setup process, throw out its notes on the GPU setup, and then freakout a bit later when it realized its note taking left something to be desired.

This is the first case I've hit where a video card advertises FSAA and can't actually do it.

Anyway, if you have hit this bug:

1. Update to 941 final - it should fix it.

2. Stop trying to run with FSAA and 16-bit color. This is a somewhat crazy combination. FSAA attempts to clean up rendering artifacts at the cost of fill rate. 16-bit color creates artifacts to save fill rate. If your GPU needs 16-bit color to run at high framerate, it's time to turn FSAA off.

(I realize that 16-bit color and aliasing are different kinds of artifacts, and some users might prefer harsh color transitions to harsh polygon transitions. But I still say, go for 32-bit color, no FSAA. When the sim is running in 16-bit mode, a good chunk of the sim still runs in 32-bit mode because 16-bit RGB surfaces only have 1 bit of alpha.* So you're not quite getting universal savings but you get 16-bit output colors, so the results look universally bad.)

*This assumes 5551, or 565 pixels. There is a 4-bit alpha 16-bit color format, cleverly called 4444, but if you thought 16-bit looks bad...

Is Your Video Card "Two Steps Down"

Identifying an underpowered video card is difficult. Video cards have simple, non-confusing names like the CryoTek GeForce FX 9999 XYZ. What the heck does all that stuff mean?

(The lists below will contain a number of "specs". Do not panic! At the end I will show you where to look this stuff up on Wikipedia.)

A modern graphics card is basically a computer on a board, and such, it has the following components that you might care about for performance:

• VRAM. This is one of the simplest ones to understand. VRAM is the RAM on the graphics card itself. VRAM affects performance in a fairly binary way - either you have enough or your framerate goes way down. You can always get by with less by turning texture resolution down, but of course then X-Plane looks a lot worse.

  How much VRAM do you need? It depends on how many add-ons you use. I'd get at least 256 MB - VRAM has become fairly cheap. You might want a lot more if you use a lot of add-ons with detailed textures. But don't expect adding more VRAM to improve framerate - you're just avoiding a shortage-induced fog-fest here.

• Graphics Bus. The GPU is connected to your computer by the graphics bus, and if that connection isn't fast enough, it slows everything down. But this isn't really a huge factor in picking a GPU, because your graphics bus is part of your motherboard . You need to buy a GPU that matches your motherboard, and the GPU will slow down if it has to.

• Memory Bus. This is one that gets overlooked - a GPU is connected to its own internal memory (VRAM) by a memory bus, and that memory bus controls how fast the GPU can really go. If the GPU can't suck data from VRAM fast enough, you'll have a slow-down.

  Evaluating the quality of the internal memory bus of a graphics card is beyond what I can provide as "buying advice". Fortunately, the speed of the bus is usually paired with the speed of the GPU itself. That is, you don't usually need to worry that the GPU was really fast but its bus was too slow. So what we need to do is pick a GPU, and the bus that comes with it should be decent.

• Of course the GPU sits on the graphics card. The GPU is the "CPU" of the graphics card, and is a complex enough subject to start a new bullet list. (As if I wouldn't start a new bullet list just because I can.)

So to summarize, you want to look at how much VRAM your card has and make sure the bus interface matches your motherboard. What about the GPU? There are three things to pay attention to on a GPU:

• Generation. Each generation of GPUs is superior to the previous generation. Usually the GPUs can create new effects, and often they can create old effects more cheaply.

  The generation is usually specified in the leading number, E.g. a GeForce 7xxx is from the GeForce 7 series, and the GeForce 8xxx is from the GeForce 8 series. You almost never want to buy a last-generation GPU if you can get a current generation GPU for similar price.

• Clock Speed. A GPU has an internal clock, and faster is better. The benefit of clock speed is linear - that is, if you have the same GPU at 450 mhz and 600 mhz, the 600 mhz one will provide about 33% more throughput , usually.

  Most of the time, the clock speed differences are represented by that ridiculous alphabet soup of letters at the end of the card. So for example, the difference between A GeForce 7900 GT and a GeForce 7900 GTO is clock speed - the GT runs at 450 mhz and the GTO at 650 mhz.*

• Core Configuration. This is where things get tricky. For any given generation, the different card models will have some of their pixel shaders removed. This is called "core configuration". Basically GPUs are fast because they have more than one of all of the parts they need to draw (pixel shaders, etc.) and in computer graphics, many hands make light work. The core configuration is a measure of just how many hands your graphics card has.

  Core configuration usually varies with the model number, e.g. an 8800 has 96-128 shaders, whereas an 8600 has 32 shaders, and an 8500 has 16 shaders. In some cases the suffix matters too.

How would you ever know your core configuration, clock speed, etc.? Fortunately Wikipedia is the source of all knowledge. Here are the tables for NVidia and ATI.

Important: You cannot compare clock speed or core configuration between different generations of GPU or different vendors! A 16-shader 400 mhz GeForce 6 series is not the same as a 16-shader 400 mhz GeForce 7 series card. The GPU designers make serious changes to the card capabilities between generations, so the stats don't apply.

You can see this in the core configuration column - the number of different parts they measure changes! For example, starting with the GeForce 8, NVidia gave up on vertex shaders entirely and started building "unified shaders". Apples to oranges...

Don't Be Two Steps Down

This is my rule of thumb for buying a graphics card: don't be two steps down. Here's what I mean:

The most expensive, fanciest cards for a given generation will have the most shaders in their core config, and represent the fastest that generation of GPU will ever be. The lower models then have significantly less shaders.

Behind the scenes, what happens (more or less) is: NVidia and ATI test all of their chips. If all 128 shaders on a GeForce 8 GPU work, the GPU is labeled "GeForce 8800" and you pay top dollar. But what if there are defects and only some of the shaders work? No problem. NV disables the broken shaders - in fact, they disable so many shaders that you only have 32 and a "GeForce 8600" is born.

Believe me: this is a good thing. This is a huge improvement over the old days when low-end GPUs were totally separate designs and couldn't even run the same effects. (Anyone remember the GeForce 4 Ti and Mx?) Having "partial yield" on a chip set is a normal part of microchip design; being able to recycle partially effective chips means NV and ATI can sell more of the chips they create, and thus it brings the cost of goods down. We wouldn't be able to get a low end card so cheaply if they couldn't reuse the high-end parts.

But here's the rub: some of these low end cards are not meant for X-Plane users, and if you end up with one, your framerate will suffer. Many hands make light work when rendering a frame. I you have too few shaders, it's not enough hands, drawing takes forever, your framerate suffers.

For a long time the X-Plane community was insulated from this, because X-Plane didn't push a lot of work to the GPU. But this has changed over the version 9 run - some of those options, like reflective water, per-pixel lighting, etc. start to finally put some work on the GPU, hitting framerate. If you have a GeForce 8300 GS, you do not have a good graphics card. But you might not have realized it until you had the rendering options to really test it out.

So, "two steps down". My buying advice is: do not buy a card where the core configuration has been cut down more than once. In the GeForce 8 series, you'll see the 8800 with 96-128 shaders, then the first "cut" is the 8600 with 32 shaders, and then the 8500 brings us down to 16.

A GeForce 8800 was a good card. The 8600 was decent for the money. But the 8500 is simply underpowered.

When you look at prices, I think you'll find the cost savings to be "two steps down" is not a lot of money. But the performance hit can be quite significant. Remember, the lowest end cards are being targeted at users who will check their email, watch some web videos, and that's about it. The cards are powerful enough to run the operating sytem's window manager effects, but they're not meant to run a flight simulator with all of the options turned on.

If you do have a "two step" card, the following things can help reduce GPU load:

• Turn down or off full screen anti-aliasing.
• Turn off per pixel lighting, or even turn off shaders entirely.
• Reduce screen size.
  

* GT = Good Times, GTO = Good Times Overclocked? Only NVidia knows for sure...

Why Isn't SLI/CrossFire A No-Brainer?

To get this out: I have no idea if/whether/how much SLI or Crossfire improve or hinder X-Plane's framerate. None of my development systems have such hardware, and I spend no time either optimizing for SLI/CrossFire or testing. If you have done tests with SLI enabled and disabled, I would like to know the results!

I have read the white papers on how to optimize an application for SLI/CrossFire, and while X-Plane isn't quite a laundry of SLI/CrossFire sins, we're definitely an application that has the potential for optimization.

Now normally more hardware = faster framerate. In particular, the limiting factor of filling in a big display with high shader options and full screen anti-aliasing can be the time it takes to fill in pixels, and more shaders mean more pixels filled in at once.* Why doesn't having an entire second GPU to fill in pixels allow us to go twice as fast?

The answer is: coordination. Normally the process of drawing an X-Plane frame goes a little bit like this:

1. Draw a little bit more of the cloud shadows into the cloud shadow texture. (This is a gradual process.)
   
2. Draw the panel into the panel texture.
3. Draw the world (as seen from below the water) into the water reflection texture.
4. Draw the airplane shadow into the airplane shadow texture.
5. Draw the entire world using the above four textures.

Notice a trend? Those four textures are dynamic textures, meaning they are created by the viedo card drawing into its own texture, once per frame. Dynamic textures are generally a good thing, because they let us create texture content much more rapidly than we could with the CPU. (There is no way we could prepare the panel texture once per frame if we had to do it on the CPU.)

In fact, the total dynamic textures can be more so - if you use panel regions, there are 2 panel textures per region, and if you use volumetric fog, there are two more textures with interim renderings of the world, used to create fog effects.

Okay, so we have a lot of textures we drew. What does that have to do with multiple video cards?

Well, one reason why dynamic textures are normally fast is because, when a dynamic texture is finished, it lives exactly where we want it to live: on the video card!

But...what if there are two video cards? Uh oh. Now maybe one video card drew the water, and another drew the clouds. We have to copy those textures to every video card that will help draw the final frame.

There is a sequence to draw the right textures on the right card at the right time to make X-Plane run faster with two video cards...but the video drivers that manage SLI or CrossFire may have no way to know what that sequence is. The driver has to make some guesses, and if it puts the wrong textures in the wrong places, framerate may be slower, due to the overhead of shuffling textures around.

So SLI and CrossFire are not simple, no-brainer ways to get more framerate, the way having a faster GPU might be.

* If you have a huge number of objects, your framerate is suffering due to the CPU being overloaded, and this is all entirely moot!

Have You Hugged Your Driver Writer Lately?

In my contact with users, on X-Plane forums, in discussions of computer graphics, video drivers are an easy punching bad. When an app doesn't work, blame the video driver. The guys at NV and ATI don't have time to respond to every ridiculous allegation that is posted. Sometimes drivers are borked, but when it turns out to be X-Plane I try to set the record straight.

Driver writers have what might be the hardest combination of programming circumstances:

1. Their code cannot crash or barf. X-Plane crashes, you send me some hate email. Your video driver crashes, you can't see to send me that email.
2. The driver has to be fast . The whole point of buyng that new GeForce 600000 GTX TurboPower with HyperCache was faster framerates. If the driver isn't absolutely optimized for speed, that hardware can't do its thing.
3. The driver writers don't have a lot of time to be fast and correct - the GeForce 700000 GTX TurboPower II will HyperCache Pro will be out 18 months from now, and they'll have to start all over again.

That's not an easy set of goals to meet. Today's video cards are basically computers on a PCIe board, and they do amazing things, but they do it thanks to a fairly complex piece of software.

Applications writers like myself get to outsource the lower level aspects of our rendering engine to driver writers. When a driver doesn't work right, it's frustrating, but when a driver does work right, it's doing some amazing things.

A Rant On Control Panels

NVidia and ATI provide control panels for Windows and Linux. These control panels let users configure aspects of 3-d acceleration, often in ways that bypass an application's request. This post is a rant about such control panels, but in order to understand the rant, you must understand how X-Plane communicates with a video card.

Stranger In A Strange Land

X-Plane is an OpenGL application. OpenGL (the "open graphics language") is a "language" by which X-Plane can tell any OpenGL graphics card that it wants to draw some triangles.

Think of X-Plane as an American tourist in a far away land. X-Plane doesn't speak the native language of ATI-land or NVidia-Land. But if the hotel says "we speak OpenGL", then we can come visit and ask for a nice room and a good meal.

Of course, if you have ever been an American tourist (or live in a country that is sometimes infested with American tourists :-) you know that sometimes American tourists who speak only English do not get to see the very best a country has to offer. Without local knowledge, the tourist can only make generic requests and hope the results turn out okay.

An example of where this becomes a problem is full-screen anti-aliasing (FSAA). OpenGL allows an application to ask for anti-aliasing. The only parameter an OpenGL application can ask for is: how much? 2x, 4x, 8x, 16x. But as it turns out FSAA is a lot more complicated. Do we want super sampling or multisampling? Coversage Sample Anti-Aliasing? Do we want a 2-tap or 5-tap filter? Do we want temporal anti-aliasing?

As it turns out, NVidia-land is a very strange country, with many flavors of FSAA. Some are very fast and some are quite slow. And when X-Plane comes in and says "we would like 16x" FSAA, there is really no guarantee that we will get fast FSAA (for example, 16x CSAA) or something much slower (like 16x super-sampling). X-Plane is not native to NVidia-land and cannot ask the right questions.

Control Panels

So where do the control panels come in? Well, if X-Plane can only ask for "16x FSAA", how can NVidia give users control of the many options the card can do? The answer is: control panels. The NVidia control panel is made by NVidia - it is native to NVidia-land and knows all of the local tricks: this card has high-speed 5-tap filtering, this card does CSAA, etc.

At this point I will pass on a tip from an X-Plane user: you may be able to get significantly faster FSAA performance with an NVidia card on Windows by picking FSAA in the control panel rather than using X-Plane's settings. This is because (for some reason) X-Plane's generic OpenGL request is translated into about the slowest FSAA you can find. With the control panel you can pick something faster.

Bear in mind that only some users report this phenomenon. My NVidia card works fine even with X-Plane setting FSAA. So you may have to experiment a bit.

It Gets Weirder

When it comes to full-screen anti-aliasing, I can see why NVidia wants to expose all of their options, rather than have X-Plane simply pick one. Still, which do you think is best for X-Plane:

• Multisampling
• Supersampling
• Coverage Sample Anti-Aliasing
• Some Mix of the Above?

Antialiasing has become very complex, and some of these modes will absolutely wreck your framerates.

And FSAA is one of the better understood options. How about these:

• Adjust LOD Bias
• Anisotropic Filtering
• Anisotropic Filtering Optimization

(I know what these do, and you shouldn't be messing with them.)

How about these?

• CPU Multi Core Support
• Multi-Display/Mixed GPU Acceleration

I haven't found any description of what those do, but I have reports from users that setting them to the "wrong" value (whatever that is) absolutely destroys framerates.

Suffice it to say, as an applications developer, the situation is a support nightmare. Users can modify a series of settings at home that we cannot easily see, that are poorly documented, that cause performance to be very different from what we see in our labs, sometimes for the worse, sometimes for the better.

The Legacy of the R300

You know it as the Radeon 9700 (and its later cheaper 9600XT, as well as the X300, X500 and X600). The R300 was a definite victory for ATI - when it came out it was vastly superior to the NVidia GeForce FX series, and for a video card it held up pretty well.

From my perspective as an application's developer, however, the R300 has some fine print that makes it difficult to deal with:

• It features only 24-bit floating point precision (as opposed to 32-bit precision in all other shader-enabled hardware from ATI or NV). This is why the reflective water looks square and pixelated up close on these cards.
• It has a 96 instruction limit per shader (as opposed to the 1024 instruction or larger limit in all other shader-enabled hardware from ATI or NV.) X-Plane 9's current water shader is right on the bleeding edge of exceeding this limit. In fact, the water pattern is simplified for this set of GPUs to stay within the 96 instruction limit.
• Since the cards were really quite decent for their time, they are still in field and in use.

(This is a different problem from the Geforce FX/5 series...those GPUs were fully capable of running advanced shaders, they just couldn't do it quickly. In practice this is better for an application's developer, because users are more likely to replace a slow GeForce FX than a capable but internally limited 9700.)

This shows up in X-Plane as a pile of special cases...X-Plane 9 productizes 2.5 renderers:

• A no shader renderer for old GPUs and buggy drivers.
• A shader-based renderer for modern hardware.
• A special-case on the shader based GPU to meet the limits of the R300.

I'm not sure what we will do about this in the future. But as I go through the shader code, this special casing sticks out. We don't usually special case X-Plane for a particular set of hardware, but in the case of the R300, it was for a while so widespread that it made sense to special-case for its limitations.

DirectX, OpenGL and X-Plane

I commented about this once a long time ago, but with DirectX 11 cards coming to market, I think some clarification may be in order. What exactly is the relationship between DirectX, OpenGL, your graphics card, and X-Plane?

OpenGL and DirectX

OpenGL and DirectX (well, technically the Direct3D part of DirectX) are both:

• Specifications for how an application requests that graphics be drawn.
• Specification for what will be drawn by a library or video card when those requests are made.

(Okay that's a gross simplification, but it will work for now.)

But DirectX is also something else: it specifies what the hardware must do. That's different from OpenGL. You can have an OpenGL compliant renderer that uses the CPU for everything difficult. It will be slow, but correct.

Extensions and Versions

Both DirectX and OpenGL have version increases, and the new version increase specifies new functionality. But OpenGL also has extensions. While normally new features come in a new spec verison, OpenGL's extensions allow OpenGL implementations to pick up new functionality "a la carte". OpenGL implementers can pick and choose what they add.

When Features Show Up

The trend in game GPUs has been for new features to show up in the DirectX spec first, then become available in OpenGL via an extension, and then make it into a future core OpenGL version. For example, most DirectX 10 features were available once DX10 hardware was released, in the form of extensions.

Sometimes the features flow in the opposite direction. For example, ATI's tessellation technology may make it into the DirectX 11 spec, but is already available as an OpenGL extension.

How This Affects X-Plane

To be blunt, X-Plane is not an early adopter of GPU tech. We are a small company so we have to prioritize our feature work carefully, and there's strong motivation to prioritize a feature that helps all users over a feature that helps only users with certain hardware.

So by the time we code a hardware dependent feature, the feature is usually available in OpenGL...I can't think of any cases where not using DirectX has held us up.

For performance, DirectX vs. OpenGL doesn't really matter - both provide access to the "fast path" of the harware - this is the code path where the GPU runs its fastest. At that point, it's a question of hardware, not OpenGL vs. DirectX.

So X-Plane uses OpenGL, but both are fine for rendering engine development (unless you need to be cross-platform), and both provide reasonable access to video card features for X-Plane.

I'm Looking Through You

Order independent transparency (OIT): first, the shiny robot.

So first, what's so special about this? Well, if you've ever worked with a lot of translucency in X-Plane, you know that it doesn't work very well - you invariably get some surfaces that disappear at some camera angles.

The problem is that current GL rendering requires translucent surfaces to be drawn from farthest to nearest, and who is far and who is near changes as the camera changes. There are lots of tricks for trying to get the draw order mostly right, but in the end it's somewhere between a huge pain in the ass and impossible.

What's cool about the robot data is that the graphics card is drawing the transparency even if it is not drawn from back to front, which means the app can just shovel piles of translucent triangles into the card and let the hardware sort it out (literally).

X-Plane is currently riddled with transparency-order bugs, and the only thing we can do is burn a pile of CPU and add a ton of complexity to solve some of them partly. That proposition doesn't make me happy.

So I am keeping an eye on hardware-accelerated OIT - it's a case where a GPU feature would make it easier for modelers to create great looking content.