So first, if I promised you scenery tools about now (MeshTool, AC3D, or any of the other things I’ve been asked for), please wait two weeks and ask again. I thought Austin would be cutting master DVDs while I would have time for tools, but instead I will cut the DVDs, so tools will have to wait until the masters are done.
To calm any fear: if you have X-Plane 9 DVDs, you will not need to buy new ones. We will be periodically updating our master DVDs (just like we always have), but we’ve taken a number of steps to ensure that everything new since the original “Beta 1” DVDs will be deliverable by reasonably small incremental web updates.
If you are reading this blog, you’re probably an advanced X-Plane user, possibly one who makes airplanes or scenery or even plugins, and you’re probably comfortable with computers and know a lot about the sim. Please bear in mind as I describe some of the changes we’re making in the installer that we have users who have never used a computer before, and purchased their first computer to run X-Plane.
Simply put, the primary goal of the installer is to allow the non-experts to use X-Plane too.
Anyway, with this post I’d like to call attention to a feature that I believe very few people know about (because it was broken for a long time and yet we didn’t get many reports).
You can update X-Plane 8 or 9 from the About Box – when you pick “About X-Plane” the sim will check our update servers for new versions, and if one is found, it will give you an update button. This update button will then download the very latest installer and launch it, setting it to update the copy of X-Plane you were running.
X-Plane 9 beta 25 will be out soon; when it comes out, please try updating by using the About Box in beta 24. Let me know if the process works correctly.
(What’s so great about updating from the about box? Well, one of the biggest tech support calls we get is users who do not successfully patch their existing copy of x-plane, but use the web updater to fetch a whole new X-Plane, which of course has no scenery. When you get the installer from the about box, you always get the latest correct installer, and the sim tells the installer which copy to live. In the future we’ll be removing the “destination” button when you run this way, so it’s as simple as “go”.)
X-Plane 9 currently recognizes (roughly) three categories of graphics hardware:
- Non-Pixel-Shader hardware (GeForce 2,3,4, Radeon 7000-9200)
- First-Generation Shader Hardware (GeForce FX 5nnnn, Radeon 9500-9800, X300-X600)
- Later-Generation Shader Hardware (GeForce 6, 7, 8, Radeon X200, Radeon X700+)
That first bucket is pretty simple: those cards don’t support programmable pixel shaders (as we know them today) and can’t run any shader effects. The “use pixel shaders” check box doesn’t appear in the rendering settings.
The distinction between the later two is a little bit more subtle. Basically the first generation of pixel shader cards (the 9700 and friends) support only 96 instructions for each pixel shader; this puts us right on the edge of sometimes not being able to draw all of our effects; we have to simplify the water slightly to make it work. The next generation of chips (X850 and friends) doesn’t have this limitation.
By comparison, while NVidia cards have been able to handle long shaders from day one, the GeForce 5’s shader performance is really poor.
So we bucket all of these chips as “first-gen”. When we detect this we:
- Simplify shaders slightly (gets us out of trouble with the 9700).
- Don’t default to shaders being on when the sim is first booted (because the framerate will probably be unusably slow).
Even though the 9700 provided very usable shader performance in its day, by the standards of modern GPUs, this older chip isn’t that fast, so it’s probably for the best that we not enable reflective water by default on machines with these cards.
By comparison, X-Plane deals with almost all other capabilities on an a-la-carte basis; particualr features are enabled if the right menu of hardware features is available. We do this to try to deal more flexibly with the wide variety of cards that are out there. Some examples:
- You’ll get hardware accelerated runway lights if your card supports pixel shaders and sprites (virtually all shader-enabled cards have sprites).
- You’ll get sun-glare effects if your card supports pixel counting (virtually all modern cards can do this).
- The non-pixel-shader rendering code will show more detail if your card supports more texture units (this is only an issue with very old hardware).
I’ve been looking over hardware profiles a lot lately, and I suspect that the next big “jump” in hardware will be the DX10-compliant cards (GeForce 8, Radeon HD). There’s a lot of fine print in what the various cards can do between all of the pre-DX10 cards; at some point when we decide what menu of features we’ll require for rendering, we need to simplify.
My guess is that when we start to have “really advanced” pixel shaders that require hardware more sophisticated than what we need now, we’ll simply require a DX10 card. Otherwise we’ll have to sort through 8 different profiles of fine print, only to attempt to partially support cards that probably won’t be fast enough anyway.
(That is to say, a feature is only useful for us if it can run reasonably quickly. It doesn’t make sense for us to try to make a special “simplified” version of a rendering feature for, say, the X850 if every X850 is going to turn it off every time for framerate reasons.)
If any of this turns into hardware buying advice, I suppose it would be this:
- If you are deciding between a DX10 and DX9 card (e.g. between the HD2400 and X1900, or GeForce 8600 vs 7900) go for the newer generation DX10 ards (HD or GeForce 8); if the card has decent performance you’ll also be setting yourself up for future features.
- As always, pay attention to the fine print of the model numbers, particularly the configuration. Lower model number cards basically have fewer parallel components than higher number ones and that leads directly to lower framerate.
I see an add online for the GeForce 8500 for $70 and 8600 for $90. But if you look at the links below, you’ll see that the 8500 has only half the shaders of the 8600 – that’s going to be a huge performance difference for $20.
(So the moral of this story is: try to get an HD or GeForce 8 card, but don’t dip into the really low end cards because they’re stripped down too far for X-Plane use.)
These pages (NV, ATI) on Wikipedia list specs for a whole pile of cards and can be useful to decode the fine print.
I’m going to be more or less out of the office next week – the Amichai Margolis band is playing a series of shows in Florida. I’m going to have to take the laptop – we’re too close to going final to miss a week of bug reports, but hopefully the next beta will stick for a while. (Initial reports indicate that the video driver initialization changes we made are fixing crashes and not causing new ones.) There will be a beta 23 shortly to address other bugs.
I wanted to take a moment to thank all of the users who have helped me debug video card compatibility problems remotely. I now have seven installed operating system configurations in my office, and it isn’t nearly enough to see all of the problems we hit in field. Looking back at my in-box this week is a reminder of how patient you all have been in trying test builds, sending log after log, helping get to the bottom of some very tricky issues.
Things are going to be a bit busy for the next few weeks – once I get back we’ll be finishing up the last few bugs, so it will take a little while to get back to questions about scenery, plugins, etc.
One of the reasons why the X-Plane 9 betas have had so many more crash bugs than version 8 is that we introduced loading DSFs on a second core. This feature makes scenery loads much slower and (by using the second core) impacts fps less while they happen.
The problem is that I’m still fumbling with code that will allow this in all cases. (That would be three operating systems, two hardware vendors, and a myriad of drivers, some new, some quite prehistoric.)
Beta 22 will be out soon, and will contain the fourth major rewrite of the OpenGL setup code for X-Plane 9. So far the initial tests look good, but we never know until we let a lot of users try the code and find the new edge cases.
It’s relatively easy to tell if your instability is related to the use of OpenGL with threads: simply run the sim with the –no_threaded_ogl option. If things become a lot more stable, it’s a threaded GL problem. Mind you –no_threaded_ogl is more of a diagnostic than a workaround; without threaded OpenGL, the sim will pause when loading scenery.
(Also, to clarify, you’ll find talk on discussion groups and game forums about “threaded drivers”. Threads are a programming abstraction that can utilize multiple cores. What I am talking about is X-Plane using multiple threads to load scenery – in our case this requires interfacing with OpenGL. But a threaded driver is different – it’s just a graphics driver that’s been optimized for multcore machines. These two concepts are totally different; you don’t need a threaded driver to use X-Plane 9, and a threaded driver won’t make X-Plane 8 load without pauses.)
A number of Windows and Linux GeForce 7 users have discovered that the command-line option –no_fbos improves their pixel-shader framerate a lot. Windows and Linux Radeon HD users have also discovred that –no_fbos cleans up artifacts in the water. Here’s what’s going on, at least as far as I can tell. (Drivers are black boxes to us app developers, so all we can do is theorize based on available data and often be proved wrong.)
Warning: this is going to get a bit technical.
FBO stands for framebuffer object, and simply put, it’s an OpenGL extension that lets X-Plane build dynamic textures (textures that change per frame) by drawing directly into the texture using the GPU. Without FBOs we have to draw to the main screen and copy the results into the dynamic texture. (You don’t see the drawing because we never tell the card “show the user”.)
We like FBOs for a few reasons:
- Most importantly, FBOs allow us to draw big images in one pass even if the screen is small. For example, if we have a 1024×1024 dynamic texture but the screen is 1024×768, then withou FBOs we have to draw the image in two parts and stitch it together. That sucks. With FBOs we can just draw straight to the texture and not worry about our “workspace” being smaller than our texture. This is going to become a lot more important for future rendering features where we need really-frickin’ big textures.
- It’s faster to draw to the texture than to copy to it.
- If you’re running the sim with FSAA, then we end up using FSAA to prepare all of those dynamic textures. In virtually all cases, we don’t need the quality improvements of FSAA, so there’s no point in taking the performance penalty. When we render right into the texture, FSAA is bypassed and we prep our dynamic textures a lot faster.
Since copying to a texture from the screen predates these new-fangled FBOs by several years, most drivers can copy from the screen to the texture very quickly; however we have hit at least one case where FBOs are much faster than copy-from-screen. That’s really a rare bug, and as you’ll see below, we see more weird behavior with FBOs.
When do we use FBOs vs. copying? Well, it’s pretty random:
- Pixel shader reflective water and fog use FBOs.
- Cloud shadows and the sun reflection when pixel shaders are off do not use FBOs.
- The airplane panel uses FBOs if the panel is 1024×1024 or smaller; if the panel is larger than 1024×1024 we draw from the screen and patch things together. So the P180 and the C172 are using different driver techniques!!
When you run X-Plane with –no_fbos, you instruct X-Plane to ignore the FBO capability of the driver, and we use copy-from-screen everywhere.
Mipmapping
There is one more element: mipmapping. A mip map is a series of smaller versions of a texture. Mipmapping allows the video card to rapidly find a texture that is about the size it needs. Here’s an example: imagine you have a building with a 128×128 texture. If you park your plane by the building, the building might take up about 100×100 pixels on the screen; your 128×128 texture is a good fit.
Now taxi away from the building and watch it get smaller out your rear window. After a while the building is only taking up 8×8 pixels. What good is that 128×128 texture? Its’ much too big for the job. With mipmapping, the card has a bunch of reduced-size versions of your texture laying around…64×64, 32×32,16×16, 8×8, 4×4, 2×2, 1×1. The video card realizes the building is tiny and grabs the 8×8 version.
Why not just use the 128×128 texture? Well, we’d only have two options with this texture:
- Examine all 16384 pixels of the texture to compute the 64 pixels on screen. That sucks…we’re accessing VRAM sixty four times for each pixel. Accessing VRAM is slow, so this would kill performance.
- Simply pick 64 pixels out of the 16384 based on whatever is nearby. This is what the card will do if mipmapping is not used (because option 1 is too slow) and it looks bad. Thsoe 64 pixels may not be a good representation of the 16384 that make up your building side.
So mipmapping lets the video card grab a small number of pixels that still capture everything we need to know about the building at low res.
We don’t mipmap our dynamic textures very often; the only ones that we do mipmap are the non-pixel-shader sun reflections and the pixel-shader sun reflections.
ATI
As far as we can tell, the current ATI Catalyst 8.1 drivers do not generate mipmaps correctly for an FBO-rendered texture. This is why without –no_fbos ATI users on Windows or Linux see very strange water artifacts. –no_fbos switches to the copy path, which works correctly.
At risk of further killing my track record of driver bugs in v9, we do think this is a bug. We have good contact with the ATI Linux driver guys so I have hopes of getting this fixed.
nVidia
It appears that the process of creating mipmaps for FBO textures is not accelerated by the hardware on the GeForce 7 GPU series. This is why GeForce 7 users are seeing such poor pixel shader performance, while GeForce 8 users aren’t having problems.
Now poor performance is not a bug; there’s nothing in the OpenGL spec that says “your graphics card has to do this function wickedly fast”. Nonetheless, what we’re seeing now is unusably slow. So more investigation is needed — given that the no-FBO case runs so quickly, I suspect the hardware itself can do what we want and it’s just a question of the driver enabling the functionality. But I don’t know for sure.
I may be fighting a pointless and unwinnable linguistic battle, but I have to try. People very often refer to the default city buildings in X-Plane as “auto-gen” but by any reasonable definition of “auto-gen” they are not really auto-gen at all.
Now these are all made up computer terms, so we can’t really check the dictionary. But “autogen” scenery (short for automatically generated) usually refers to scenery that is created by a flight simulator itself, usually while you fly, and usually by placing 3-d detail in places that match the base terrain. This exists in FSX, and existed in X-Plane up to version 7.63.
X-Plane 8 doesn’t have autogen!!!!!!! X-Plane 8 has scenery that is generated by computer programs, but X-Plane is not the computer program that is doing it. When you see a ton of buildings piled up in New York City, that is not becaues X-Plane looked at the New York city base terrain and said “hrm – some buildings would be nice.”
What actually happens is we analyze New York City when we create the global scenery (before we ever burn the DVD masters) and the DSF generator places all of those buildings in New York City. X-Plane simply gets a huge list of buildings from the DSF and draws them.
I am going to try to coin the term “algogen” (algorithmically generated) to describe these buildings that (like autogen) come from a computer generating semi-random buildings from input data, but unlike autogen, algogen is a process that runs once before the scenery is made.
So how is algogen and autogen different?
- You can’t change the pattern of algogen building placement by editing files in the sim. The algorithm has already been run! You can replace the buildings using an overlay (that excludes the base) or by using a library of models to substitute models.
- We are trading data size for computation. The DSF is bigger because it lists the location of every building in New York, even if they were just algogen buildings, but the job of placing those buildings is less difficult because X-Plane does not have to check each building against each road. That has been done in advance.
- Changing the scenery via an overlay doesn’t change the algogen! Add an airport via an add-on and you have to exclude the buildings. (But if you send that airport to Robin, the next global render will include it and the algogen will skip the airport automatically.)
Note one of the interesting results of algo-gen: X-Plane can’t tell the difference between an alg-gen building and a hand-placed one! They’re all just objects in a DSF. The fact that algo-gen buildings disappear with lower settings is because the sim/require_object property in the DSF header tells the sim which objects are important, and our generator always signals the buildings based on obstacle data as important. But algogen as a process is not visible to X-Plane!
And that’s why I’m spending so many words on trying to distinguish between “algogen” and “autogen” – because the processes are fundamentally different, they’re very different for scenery authors to work with. As a result, authors coming from X-Plane 7 or FSX will be very surprised if they try to understand X-Plane in terms of autogen….they won’t be able to find the autogen config files, and the autogen buildings won’t react to other scenery changes, because they’re not actually autogen at all!
Algogen is a classic pattern of “precompute” vs. “compute-while-fly”. Generally precomputing gives authors more flexibility (in our case, we have an obj engine that can handle a lot of objects, so authors can make their own objects of the same density as algo-gen with the objects placed anywhere) at the expense of making it more complex to edit the existing scenery (edit the mesh and the algogen doesn’t change).
When we started the v8 scenery, two things pushed me toward precomputation:
- In the past, changes in X-Plane’s rendering engine had broken third party add-ons. So a precomputation strategy (by getting the scenery code out of the sim) means that the sim is doing less “interpretation” and thus the interpretation of scenery is less likely to change.
- We wanted to focus on performance, which means getting computation out of the sim whenever we could.
Now that last point isn’t quite as important as it used to be…when we were doing the design (during mid X-Plane 7), dual core for everyone wasn’t on the radar, so the penalty for complex computation while flying is lower (and thus we have more expensive in-flight computation, like forests and completely draped bezier curve-based polygonal pavement).
But I think precomputation is still useful. Even with dual core, the algorithm that places X-Plane’s algo-gen bulidings can take one to two minutes for a 1×1 DSF tile on a very fast computer. That’s still a load time that’s out of the question for us; even on the second core, the DSF wouldn’t be “ready” in time for you to fly it. So one use of precomputation is to run algorithms that are more expensive than you can have in real-time. (That algorithm to pack objects inside an irregularly shaped polygon made by roads and land features is not fast.)
More importantly, precomputing does give us a nice advantage in the use of storage data. We ship about 50-60 GB of final scenery, but the source data is well over 100 GB. When we run the algogen algorithm, we have access to the full set of source data: coastlines, elevation, and land use before any simplification is done and any data is thrown out. So we have the potential not only to do a more complex analysis, but to do the analysis on a larger data set.
The down-side of precomputing is that if integration of all data is saved until sim time, there is the potential for third parties to contribute separate data to the sim via add-ons and still have the integration of those data sets work well. This doesn’t always work out – see complaints in online magazine reviews about combining orthophotos and new road grids in FS2K4…they don’t integrate because neither of those types of resources can be integrated to match the other in real time. But autogen still does a much better job than algogen at this; algogen basically has to be recut when other data changes. (And that is our intention – if you change the road grid, exclude and replace the objects too!)
The story on X-Plane performance is never over, but the chapter that is 9.00 pretty much is. I think we’ll be RC in the next build (if all goes well). Certainly a lot of the things that are still performance “problems” will require changes larger than we can do in a late beta.
I say problems in quotes because a lot of what’s been reported lately is in the form of: a huge screen res + a lot of shaders + a lot of FSAA = slow fps. That’s not really a bug, that’s an engine limitation. Now I want to make the engine as fast as possible, and a lot of this pixel shader stuff is new to 9.0, so if our track record for tuning stays the way it was for v8, we’ll probably get some efficiency improvements later.
But unfortunately there’s an underlying limitation: the new water and fog both cause the rendering engine to consume significantly more hardware resources than it would otherwise. Turn them on and you get prettier pictures at a price.
Just to post a a few general things I’ve found:
- X-Plane 9 will tell you where your GPU really stands. GPUs that were very adequate for X-Plane 8 (like the GeForce 6600 GT) will turn out to have nothing left in reserve for v9, while GPUs that were bored in v8 (the GeForce 8800 GTX for example) will show what it really has.
- Generally the cost of going from no shaders to shaders with water reflections of “none” and no volumetric fog should be very low if your screen res and FSAA don’t add up to something crazy (like 16x FSAA at 2048×2048).
- If you do have serious performance hits, try –no_fbos in the command-line; some drivers seem to have trouble with them.
- The P180’s virtual cockpit is a lot more expensive than the other ones, because it has a huge panel that is used in 3-d. We’ll hopefully rebuild the cockpit at some point.
- Turning water reflections to “complete” is very expensive. Watch the water and use the lowest setting that looks good. You don’t need complete reflections if there are a lot of waves!
- Shaders, FSAA, and screen size are all pulling from the same set of resources – be careful about cranking up all three.
- Check your v-sync – a lot of users whose vsync clamped them at 60 fps in v8 will be clamped at 20 in v9.
- Do your testing with texture res set low, then crank texture res later; pixel shaders also require the allocation of VRAM that can’t be purged (for things like reflection images) so running out of VRAM can show up in some weird ways performance-wise.
- The new Intel iMacs have serious performance problems with shaders on. This is due to driver limitations; given the much better performance under BootCamp, I expect the Mac performance to get better when the drivers are updated. For now I’d keep shaders off.
For now, please hold off on sending me performance reports. I just don’t have time to address them. In the future I will try to solicit very specific performance data points that we need to check. Perhaps in the future we can also set up a database of fps-test results to have a more comprehensive idea of how the hardware does its job.
I expect future features to appear in v9 that further eat hardware; those features will have an off switch. You may have to pick and choose what graphics you enable; there is no free lunch here. I also expect new graphics cards to emerge that make the GeForce 8800 GTX seem quaint!
What a difference new drivers make. ATI’s latest OpenGL drivers (Catalyst 8.1) seem to work quite well with X-Plane. On two fronts:
- Linux. Turns out all you need to do to make X-Plane happy on Linux with ATI hardware is update the drivers. I’m running with the Cat 8.1 drivers on my MacBook Pro and things look good. Use Catalyst 7.11 drivers or newer! No more MALLOC_CHECK_=1 or –no_threaded_ogl. With the next beta, you won’t have to use –force_run anymre.
- Windows. We were getting reports of corrupt screens on startup, and with the Catalyst 8.1 drivers these reports became very frequent. Turns out our threaded OpenGL code was doing something naughty*. Beta 19 fixes this.
The only known issue I can think of is: if you see corrupt water reflections, run with –no_fbos.
* Well, the way you set up threaded OpenGL on Windows and Linux is not very well documented, so I say naughty in that we made the drivers unhappy. I have yet to find a document that states clearly whether what we were doing is correct or not. We had to guess.
I try not to divert this blog from X-Plane related stuff, but I just can’t resist. Go to the itunes music store and search for:
amichai margolis
Ami has been a friend of mine for years; Orah V’Simchah is the first CD he’s recorded of his own music (I played bass on it). A few time a year he pulls a band together and we play a few gigs. Anyway, enjoy the tracks!
I get a lot of requests for settings…the email is typically something like:
- Some feature in X-Plane is defaulted to X.
- I like it better when it’s like Y.
- Can I have a setting to change the feature between X and Y.
Raymond Chen has a great posting that I think is very topical: “In order to demonstrate our superior intellect, we will now ask you a question you cannot answer.“
This brings up one of the main reasons why we shy away from more settings: the more complex we make X-Plane’s configuration, the less likely it is that the average user will be able to set the sim up correctly. Settings requests usually come from our most advanced users, but we also have users who have never used a computer before. Really! I’ve been on the tech support calls – they are very nice, but way overextended on the computer side of things. Should we allow them to pick whether scenery geometry is store in AGP memory vs. VRAM?
From our perspective, having a setting that a user doesn’t understand is worse than neutral, it’s actually harmful. Every one of those settings is something that can go wrong with the sim. I removed the ability to set the level of detail bias to positive (in other words, extend the visibility distance of scenery beyond its original design) after about 500 complaints of “low framerate” from users who had maxed this setting out (causing a 4x increase in 3-d processing load) without knowing (1) what the setting was, (2) what it was good for or (3) what the down-side was.
Could we present all the info to make intelligent decisions on the rendering pages? Honestly, probably not beyond a certain point…we would devolve our sim into a lecture on working sets, bottlenecks, and the OpenGL pipeline long before the user got flying. (Wait, that’s my blog! Doh!!!) At some point the sim just has to do its best to do the right thing, or something similar to it. Just as Raymond points out that the default answer to any dialog box is “cancel”, the default answer to any rendering setting is “all the way up.”
When I tell a user who wants a setting that he or she can’t have a setting because some other user will abuse it, the answer is almost always: well why don’t you have two settings screens, a simple and advanced mode?
Besides the irony (of trying to solve the problem of too many settings with another settings), Raymond also points out that no location to hide an advanced setting is ever quite good enough. This is something we have struggled with, choosing command-line options more for to pragmatic reasons than because it’s a great solution.
This doesn’t mean you can’t ask for command-line options…I am just trying to point out some of the thinking on the other side of the coin.
