In a previous post I discussed the basic ideas behind using multiple threads in an application to get better performance out of a multi-core machine.
Now before I begin, I need to disclaim some things, because I get very nervous posting anything involving hardware. This blog is me running my mouth, not buying advice; if you are the kind of person who would be grumpy if you bought a $3000 PC and found that it wouldn’t let you do X with X-Plane (where X includes run at a certain rendering setting, framerate, or make your laundry) my advice is very simple: don’t spend $3000. So…
- I do not advocate buying the biggest fastest system you can get; you pay a huge premium to be at the top of the hardware curve, particular for game-oriented technologies like fast-clock CPUs and high-end GPUs.
- I do not advocate buying the Mac Pro with your own money; it’s too expensive. I have one because my work pays for it.
- 8 cores are not necessary to enjoy X-Plane. See above about paying a lot of money for that last bit of performance.
Okay…now that I have enough crud posted to be able to say “I told you so”…
My goal in reworking the threading system inside X-Plane for 920 (or whatever the next major patch is called) is, among other things, to get X-Plane’s work to span across as many cores as you have, rather than across as many tasks are going on. (See my previous post for more on this.)
Today I got just one bit of the code doing this: the texture loader. The texture loader’ job is to load textures from the hard drive to the video card (using the CPU, via main memory) while you fly. In X-Plane 901 it will use up to one core to do this, that core also being shared with building forests and airports.
With the new code, it will load as many textures at a time as it can, using as many cores as you have. I tested this on RealScenery’s Seatle-Tacoma custom scenery package – the package is an ENV with about 1.5 GB of custom PNGs, covering about half of the ENV tile with non-repeating orthophotos.
On my Mac Pro, 901 will switch to KSEA from LOWI in about one minute – the vast majority of the time is spent loading about 500 PNG files. The CPU monitor shows one core maxed out. With the new code, the load takes fourteen seconds, with all eight cores maxed out.
(This also means that the time from when the scenery shifts to when the new scenery has its textures loaded would be about fourteen seconds, rather than a minute, which means very fast flight is unlikely to get to the new area before the textures are loaded and see a big sea of gray.)
Things to note:
- Even if we don’t expect everyone to have eight cores, knowing that the code can run on a lot of cores proves the design – the more the code can “spread out” over a lot of cores, the more likely the sim will use all hardware available.
- Even if you only have two or four cores, there’s a win here.
- Texture load time is only a factor for certain types of scenery; we’ll need to keep doing this type of work in a number of cases.
This change is the first case where X-Plane will actually spread out to eight cores for a noticeable performance gain. Of course the long-term trend will be more efficient use of multi-core hardware in more cases.
The global scenery comes in two packages in version 9: -global terrain- and -global overlays-. The global terrain package contains the base meshes (with beaches); the global overlays contain roads, forests and objects.
Why is this scenery split in half? The answer is unfortunately not “so you can replace the base mesh but keep the overlay 3-d stuff.” That would have been clever, but I must admit I didn’t think of it at the time; MeshTool didn’t exist and people just weren’t making base meshes.
My actual goal was to make it cheaper to replace a significant number of overlays. I don’t know if we’ll ever do this, but one of the obstacles to patching global scenery is the file size; we can only hope to replace a fraction of the files during a version run before the web update size gets too large. But most of that size is in the base mesh. With the base mesh and overlay split, we could potentially replace more overlays.
(Note: we did not actually issue any DSF replacements during the v8 run, and I don’t know if we will or will not during the v9 run. The only thing I am sure of is that if we provide replacement v9 DSF tiles, they’ll be a free download, like all v9 patches…if you buy v9, you get everything.)
The fundamental problem with replacing the base mesh but not the overlays is that the scenery system provides no good way to do this. The Global Scenery folder is always scanned after the Custom Scenery folder* so you’d have to install custom scenery into the global scenery folder with the right file name to get access to the overlay content.
I’m not sure what to do about this yet; the trend in scenery development is for authors to want more control to replace individual parts of the system; the overlay system provided part of that.
* Users with v9 beta DVDs will have the two global scenery folders in the Custom Scenery folder. But — the sim detects this and simply treats them as if they were in the Global Scenery folder, ignoring alphabetic ordering.
901 is out now…basically it’s just 900 + French and German localizations. Also a few minor tweaks:
- We added a few datarefs and commands by request – check DataRefs.txt.
- The plugin font size is back to 6 pixels, like v8. It looks a bit ugly now, but we’ll put a new font in place soon. The important thing is: 6-pixel fonts for v8 and v9, so one plugin can operate everywhere.
- A few plugin bug fixes – see the SDK known bugs page.
- Linux won’t complain if your disk is mounted as iso9660. Since the v9 final disks are all mastered as ISOs and not UDF, asking you to mount them as UDF is asking the impossible.
- If you have a demo install, it will add the word “Demo” to its name in the startup screen. This is to help users with more than one install identify which one they are running.
If this all seems minor and tweaky, well, it is. The main point of 901 was to get the localizations in. In the future we’ll have a feature patch that brings new airplane features in and other cool stuff.
901 is freely available using the X-Plane web updater…the download size is only about 14 MB.
Finally, I’ve posted all new DVD installer/updater/web demo installer apps – version 2.04 localizes to French and German too.
A while ago I put three operating systems on my laptop. With the Mac Pro I’ve done the same thing – it’s a huge win to be able to cover such a wide swath of OS/GPU/CPU combinations with fewer machines. Last time it was OS X 10.4, Windows XP SP2, and Ubuntu 6.06. This time I repeated the process with OS X 10.5.2, Windows Vista RTM, and Ubuntu 8.04. Random observations:
- Linux really just keeps getting stronger. I’ve always been a bit skeptical about Linux as a desktop environment, particularly as a Windows/Mac developer (that is to say, I’m spoiled by free high quality IDEs ad debuggers that require no setup to use the platform SDK, comprehensive platform documentation in one location, etc.). But Linux installation is becoming more plug & play and trouble-free each time I make myself a live CD.
- Windows Vista is a train wreck. I feel a little bit lame blogging this, as taking pot-shots at Vista is sort of like shooting fish in a barrel. But the contrast between Ubuntu, which has become easier to use over a year and a half, and Windows, which has not, is stark.
- There are some positive things to say about Vista. The partition-aware installer is a real convenience for multi-booters. And once you figure out where everything has been moved to and go back to “classic” views, the OS is tolerable. But you’ll still find plenty of things that will make you want to tear your hair out. My recommendation: stick with XP. (Duh.)
Now on to the performance numbers. These numbers are the Xp900 time demo fps tests 1, 2 and 3. Each set of 3 numbers is from the three phases.
1 2 3
MAC 49/ 60/ 62 38/ 43/ 44 21/ 20/ 21
WIN 121/128/133 114/115/119 77/ 75/ 82
LIN 143/144/157 130/123/132 92/104/113
That’s not a typo. Linux is beating out Vista, but both are absolutely killing OS X. What’s going on here? I don’t know. But there appears to be something that isn’t well optimized in the GeForce 8 drivers on OS X.
I suspect Apple will close this gap eventually; don’t bother asking me for status information on this because if they ever tell me what’s going on, I’ll be bound by NDA not to tell you.
For now my recommendation is: consider dual-booting into Linux – it’s pretty easy to install Ubuntu and you’ll get great X-Plane performance. With good drivers, the Mac Pro and 8800 are just monstrous.
The New Mac Pro came today. I’m very excited about this computer because it may be the first computer that can render an entire set of global scenery on its own in under three days. We’ve always had to apply multiple computers to the problem, sometimes in different cities, and synchronize the data. Being able to do the render on one box is a nice simplification.
A few immediate observations:
- Man is it expensive. If you aren’t Warren Buffet and your work isn’t buying it, think long and hard about why you need it. The iMac is a more reasonable X-Plane computer. (And from what I understand, both Radeon HDs and GeForce 8’s have driver problems on OS X; until Apple fixes this, consider BootCamp. With the new iMacs you can pick which next-gen card with “work-in-progress” drivers you want.)
- Buy third party parts…not only will you save money, but you’ll get the joy of installing them. Since the “blue and white G3” Apple’s cases have been on par with well-designed PC cases for accessibility. The Mac Pro is nicer though – hard drives and memory are all installed on rail-guided slide-in parts; two hard drives and two DIMMs took about 5 minutes and a single screw-driver.
My office is going to explode. Here’s a rough list of all of the Macs we have in the house now:
- Mac Pro (the new scenery rendering machine, also graphics with 8800, will be triple-boot).
- Aluminum iMac (mostly for testing graphics code on Radeon HD, but it’s now the DVD burning station, runs Ubuntu 7.10).
- Mac Book Pro (old X1600-based, portable dev machine, triple boot but LILO is dead).
- G5 (the old rendering machine, kept around to regress bugs on PPC, R300 chipset, OS X 10.3, etc.).
- Dell P-IV 2.6 ghz – mostly used to record music, but it does have a GeForce 6 in it, and it’s a good low-end test system. (A 2.6 ghz P-IV doesn’t get you real far, the FSB is slow, and it’s only got 4x AGP.)
- G4 laptop (800 mhz) – case is falling apart, but if I ever needed to try to run on a really low-end system. Actually at this point the laptop is so far below min specs that it probably isn’t worth it.
- Mac Book – got this for my wife, but if I begged she’d let me regress Intel X3100 bugs on it.
So there are two points to note here, and neither of them are “Ben has a lot of computers” and “Ben’s office is a mess.”
- X-Plane 9’s use of graphics hardware has caught up enough with the bleeding edge that I now basically have to have “one of everything” to really debug the sim. We’ll have some major updates to shaders in future patches, so having accumulated all of this hardware in-house (a lot in the last few months) will help me debug these things faster. A lot of these setups are due to “X doesn’t work” bug reports specific to certain hardware/OS combinations.
- It’s really handy that Macs now have x86 chips because it cuts down the number of boxes. The new Mac Pro will give me an nVidia DX10-type platform not only for OS X but also for Vista (first Vista machine in the house, not because I want Vista, but because someone in the company should have at least one copy) and Linux too, if I can make it work.*
So the next time we release a beta and it immediately crashes your computer, please bear with us. It really did work bug free on some computers we own…we’re getting closer to a complete matrix to catch more of these incompatibilities early on. But even with that huge mess of hardware we’re still missing a lot of combinations.
* Triple-booting Mac/Win/Linux is a much bigger PITA than double boot. The problem is that the old MBR-type setups only give you four partitions, of which one gets eaten for the firmware. That leaves you three partitions and three operating systems, but by default Linux wants a second one for swap (a good idea). So you need to either stick a fifth partition
on and fix the MBR by hand or reconfigure Linux to use on-main-volume swap-space. In summary, with only two operating systems, eitiher Windows or Linux “just installs”, but to put three on one drive, you get into customization.
Now that multi-core machines are mainstream, you’ll hear a lot of talk about “threads”. What is a thread, and how does it relate to using more cores?
Definitions
A “core” is an execution unit in a CPU capable of doing one thing. So an 8-core machine might have two CPUs, each with four cores, and it can do eight tasks at once.
A “thread” is a single stream of work inside an application – every application has at least one thread. Basically a two-threaded application can do two things at once (think of driving and talking on your cellular phone at the same time).
Now here’s the key: only one core can run a thread at one time. In other words, if you have an eight core machine and a one-thread application, only one core can run that application, and the other seven cores have to find something else to do (like run other applications, or do nothing).
Two more notes: a thread can be “blocked” – this means it’s waiting for something to happen. Blocked threads don’t use a core and don’t do anything. For example, if a thread asks for a file from disk, it will “block” until the disk drive comes up with the data. (By CPU standards, disk drives are slower than snails, so the CPU takes a nap while it waits.)
So if you want to use eight cores, it’s not enough to have eight threads – you have to have eight unblocked threads!
If there are more unblocked threads than cores, the operating system makes them take turns, and the effect is for each of them to run slower. So if we have an application with eight unblocked threads and one core, it will still run, but at one eighth the speed of an eight core machine.
It’s not quite that simple, there are overheads that come into play. But for practical purposes we can say:
- If you have more unblocked threads than cores, the execution speed of those threads slows down.
- If you have more cores than unblocked threads, some of those cores are doing nothing.
Trivial Threads
When a thread is blocked, it does not use any cores. So while X-Plane has a lot of threads, most of them are blocked either most or all of the time. For all practical purposes we don’t need to count them when asking “how many cores do we use”. For example, G1000 support is done on a thread so that we keep talking to the G1000 even if the sim is loading scenery. But the G1000 thread spends about 99.9% of its time blocked (waiting for the next time it needs to talk) and only 0.1% actually communicating.
What Threads Are Floating Around
So with those definitions, what threads are floating around X-Plane? Here’s a short list from throwing the debugger on X-Plane 9.0. (Some threads may be missing because they are created as needed.
- X-Plane’s “main” thread which does the flight model, drawing, and user interface processing.
- A thread that can be used to debug OpenGL (made by the video driver, it blocks all the time).
- Two “worker” threads that can do any task that X-Plane wants to “farm out” to other cores. (Remember, if we want to use more cores, we need to use more threads.)
- The DSF tile loader (blocks most of the time, loads DSF tiles while you fly).
- At least 3 threads made by the audio driver (they all block most of the time).
- At least four threads made by the user operating system’s user interface dode (they block most of the time).
- The G1000 worker thread (blocks most of the time, or all the time if you don’t have the G1000 support option).
- The QuickTime thread (only exists when QuickTime recording is going on).
So if there’s anything to take away from this it is: X-Plane has a lot of threads, but most of them block most of the time.
Core Use Now
So how many cores can we use at once? We only need to look at threads that aren’t blocked to add it up. In the worst flying case I can think of:
- The main thread is rendering while
- The DSF tile loader is loading a just-loaded tile while
- One of the pool threads is building forests while
- You are recording a QuickTime movie (so the QT thread is compressing data).
Yep. If you really, really put your mind to it, you can use four cores at once. 🙂 Of course, two cores is a lot more common (DSF tile loading or forests, but not both at once, and no QuickTime.
Core Use In the Future
Right now some of X-Plane’s threads are “task” oriented (e.g. this thread only loads DSF tiles), while others can do any work that comes up (the “pool threads”, it’s like having a pool car at the company, anyone can take one as needed). The problem with this scheme is that sometimes there will be too many threads and sometimes too few.
- If you have a dual-core machine, having forests building and DSF loading at the same time is bad – with the main thread that’s three threads, two cores; each one runs at two-thirds speed. But you don’t want the main thread to slow down by 66%, that’s a fps hit.
- If you have a four-core machine, then when the DSF tile is not loading, you have cores being wasted.
Our future design will allow any task to be performed on a “pool thread”. The advantage of this is that we’ll execute as many tasks as we have cores. So if you have a dual-core machine, when a DSF tile load task comes along while there is forests being done, the one pool thread will alternate tasks, leaving one core to do nothing but render (at max fps). If you have a four-core machine, the DSF load and forests can run at the same time (on two pool threads) and you’ll have faster load times.*
* Who cares about load time if you’re flying? Well, if you crank up the settings a lot and fly really fast, the loader can get behind, and you’ll see trees missing. X-Plane is always building trees in front of you as you fly and deleting the ones behind you. So using more cores to build the forests faster means you’re less likely to fly right out of the forest zone at high settings.
Well, the paint is barely dry and we already have an X-Plane 9.01 RC1. Here’s what’s going on and how you can try it.
9.01 is the first of what may be a few small internationalization and localization patches. 9.01 adds German localization and updates the French strings. 9.01 also has a handful of very minor bugs; Austin will probably post the bug list shortly. 9.01 is already RC because the code changes are really minor.
After 9.01 we’ll do another localization patch (probably in the next month) that will include unicode and true-type font support. That build (902? 905? Who can guess what number Austin will pick!) will probably have a formally named beta because the unicode changes are extensive.
900r3 is still the latest final build and it’s what you get if you update your copy or run the web demo installer.
To get 901r1, go to the updater options and check “get betas”; update your sim and 901r1 will be downloaded. Please try it!
I just added this article on version numbers and betas to the X-Plane Wiki. A few notes:
- You can select to update to new betas using a check-box in the X-Plane Web Updater. Previously there was a special updater for betas – now it is a preference, to cut down on the number of applications we have floating around.
- Release candidates do not get re-released or renamed when they go final! A release candidate means “we think this is totally done and can be released”. It is declared “final” when, after letting people use it for a while, we decide that there probably aren’t any bugs left that we will fix in this release. So 900r3 is the final version of X-Plane 900.
It took us three tries (900r1, 900r2, 900r3) to get the final version of 900 right. So we will not rebuild the sim just to remove “r3” from the app version…900r3 is the latest – if you have it, there is nothing to update.
And of course, my usual rant about betas: betas aren’t free candy, they’re an attempt to work the bugs out of buggy software! If your goal is to enjoy your X-Plane experience, the safest bet is almost always to not download the beta. (An exception would be if there is a work-around for a driver bug that affects your hardware, available in a new beta.)
If you are a third party developer/author, please do download the betas, early and often! It is much easier for us to fix bugs early in beta.
We have an X-Plane support Wiki: //wiki.x-plane.com/.
I’m not sure what will end up there eventually, but it will include some airplane development info, a lot of trouble shooting tips, and general instructions.
It will not contain scenery or plugin development info, as they have their own full websites.
I encourage you to edit the wiki and help organize – I am putting information up there as I think of it, but I need help editing it for organization.
Posted in News
by
Ben Supnik |
I made the mistake of nuking this poor user’s comment and I can’t figure out how to get it back; it’s a question that I think a number of people might have, so:
Ben, I am thinking of buying the dvds. I have heard the new (final)
version fills the whole dvd (6gb) whereas the beta took about 1,5 gb.
What is the difference? If I buy the final version, will I get better
geographic detail (more vectorpoints) or what is the real reason?
First, you will not get more scenery detail (geographic, vector points, or otherwise) in the final than beta. The scenery is the same in beta and final.
Generally speaking, every difference between beta and final is available via web download. In fact, the final DVDs are made by:
- Installing beta 1.
- Running the updater to get the final version.
- Cutting a new DVD off that finished result.
So I am quite sure that the final disks are the same as a beta DVD plus update.
Now the question is then, why did we do eight DVDs before and six now? The answer is two-part:
- Walmart.
- Best Buy.
The retailers prefer a six-DVD pack that is commonly used for software; our distributor therefore wanted us to cut from eight to six DVDs. We did this both by using a more powerful compression algorithm on the DSF (7-zip instead of regular zip for DSFs) and by packing the DVDs much tighter. The old DVDs are one continent-per-DVD, plus the sim; the new set is simply a ton of files packed onto 6 DVDs until they’re almost full. Since the new installer lets you pick areas to install, the fact that the files are packed is not a huge problem.
So why did Austin have a sim DVD with only 1.5 GB of stuff? Convenience during beta. Austin updated the beta DVDs at beta 11; by having the sim by itself he could make a new sim DVD and not recut all of the scenery DVDs. (Cutting DVDs takes forever; an hour to burn each one, a lot of testing, a few copies, start all over if you find a problem. It can take me a whole long day and into the night to create a master.)
As a final note, there is a difference between the early US retail six-DVD set and the Laminar one; the installers are different. But they are both six DVD packed sets with scenery on the sim disk (disk one). The retail disks had to be finished first; the new installer was not ready. We will be using the new installer from now on.
The operative point here is: it really doesn’t matter what you buy; everything we’ve released can be web-updated to the current version!
