Since X-Plane 9 went final I’ve been going in about 5 different directions with the code, and as a result my posts have diverged pretty far from my charter within the company, namely scenery. Here’s some of what I’m looking at on the scenery front:
Texture Paging
Texture paging is a new feature where X-Plane can change the resolution of orthophotos while you fly. The big limitation of orthophoto-scenery right now is that X-Plane loads every orthophoto at the maximum user-defined resolution when the underlying DSF/ENV is loaded. This can cause X-Plane to run out of virtual address space and crash. With texture paging, only the nearby textures are loaded at high resolution.
Far away textures may be low res, but you’ll never notice because they are far away (and thus you’re seeing them over only a few pixels on screen anyway.
The cost of this technique is that textures are being loaded over and over and over. But this cost is made less painful by two features:
- DDS texture loads are very fast and cheap, especially at very low resolutions.*
- With the next major patch, texture loading will be entirely on a second core (if you have one) and can even span multiple cores.
This feature will require modification of scenery packs in that you’ll have to add some “paging” information to your .ter files; I will try to get a preliminary spec posted soon. Because you only have to modify text files, it should be possible to create “paging patches” to existing DSF orthophoto sceneries that are fairly small.
I do not know if paging will be available for .pol files. My guess is yes, but I reiterate that using .pol files for large areas of orthophotos is a bad idea! Make a new mesh!
Improved Multi-Core Performance
This is going to be an on-going process through the entire v9 run and beyond, but basically with every change to our rendering engine (and we make some serious modifications with almost every patch to keep it modern and competitive) we try to move toward using the new hardware (meaning machines with 2-4 cores) more efficiently. Some of this will be in 920, although my guess is we’ll need at least one more patch after 920 to really see the improvement.
Tools
It’s going to be a little bit before I can put more time into the various scenery tools. My top priority is to keep up with user feedback and work on MeshTool. Hopefully we’ll also declare WED final soon. But for now, since I am working on cockpit and airplane modeling features, my next set of work will probably be for the airplane authors.
Shaders
I do want to put additional shader work into v9. I realize I am at the edge of provoking a bunch of rants in the comments section, so let me save you some time:
“Hey Ben, stop working on eye candy and create some more tools. I don’t want a shader feature that makes my 1.2 ghz G4 with a GeForce 2 MX run any slower. You should finish the tools so they do exactly what I want!”
Okay, I admit, that was totally unfair…there is a lot of truth in the complaints about shaders vs. tools.
- I really do try to keep an eye on system requirements, particularly once we shipped. I’m going to try to prioritize shader features that improve existing rendering techniques, rather than introduce new rendering techniques, so we don’t seriously lower fps during the version run. But also bear in mind that shaders can be turned off, and there are users who have GeForce 9s and such.
- Tools are very important, hence the effort to get MeshTool out. But tools without engine work aren’t very useful either; most of the engine work we do is needed to keep performance up so that new scenery (made with those new tools) don’t bury the sim. For example, MeshTool without texture paging would be a dead-end…you could easily make a MeshTool scenery that you can’t fly.
So in planning what goes out when, I look for clumps of features and tools that can go together to make some sense: WED to use apt.dat 850, texture paging to go with MeshTool. It wouldn’t make sense to defer texture paging to make the next tool while MeshTool is waiting for engine enhancements.
* A DDS already has all of the smaller-version pre-compressed textures in the file. So loading a DDS at low res involves loading a small amount of data from disk to memory and sending it to the graphics card.
By comparison, a PNG file only contains the maximum size, so to load a PNG at low res, we load the largest size, shrink it on the fly, then apply DDS compression.
For those who posted comments, sorry it took so long to moderate them – for some reason my spam filter decided that notifications of comments are, well, spam, so I just found them now. I should have known people would have jumped into a Vista-bashing thread. 🙂
There is an X-Plane 9.02 beta 1 posted – like 901 we’ve been pretty quiet about this, but you can get it by enabling “get betas” and running the X-Plane updater. Please give it a try. Like 901 it is a small change for the purpose of localization, but it actually has an interesting feature pair:
- True-type fonts and
- Unicode-aware.
This is part of some rework we did to provide better language support. So…you should be able to run X-Plane no matter what weird characters* are in your folder names, name your airplanes funny things, and see diacritical marks. 902 uses a font that provides all of the Latin and Greek/Cyrillic code pages.
Also I have heard reports of improvements based on drivers:
- nVidia has 175.16 drivers out and they apparently address “stuttering” issues. The stuttering issue has been on my list to investigate because it happens under Windows but not Linux. If you have stuttering performance on high-end NV hardware, particularly with forests and Windows, please try 175.16 and let me know how it goes.
- ATI has released Catalyst 8-5. Catalyst 8-3 and 8-4 were causing “incomplete framebuffer” errors for some users, but I was unable to reproduce it (after spending a good day trying to jam Windows XP onto an iMac already crammed with Windows and Linux….yet another episode of a Tale of Three Operating Sytstems). Anyway, at least one user reported the issue as fixed in Cat 8-5, so if you are having problems, please try the new driver set.
As always, bugs in the X-Plane beta should go to our bug report form, on the X-Plane contacts page.
* You might accuse me of being American-centric in decrying diacritical and greek letters weird – but the truth is I am computer-centric…anything that is not in the original ASCII set is weird. 🙂
I’ll warn you in advance: this is going to start off topic and go way off topic. “Catching up” with the changes to Mac OS, Windows and Linux has me thinking about the nature of technology. I feel a little bit guilty about this post because it’s going to turn into a rant about Vista, and ranting about Vista is like shooting fish in a barrel. On the other hand, having used Vista, well, I have a lot of rant to give.
One of the most important things to understand about technology (and computers are no exception) is that changes in the scale of the technology change the very nature of the technology. That is, as you make computers faster and cheaper, at some point the sum of all of those small improvements changes the fundamental nature of the beast. We’ve seen this as the computer transformed from main frame to desktop (which is really just a change in cost and size), finding an entirely new audience, and now again as the computer changes from what we know of now as a computer to cell phones, MP3 players, and other small, mobile devices.
“Commodification” is what happens when, as things get better, cheaper, faster, etc., consumers stop caring about the marginal improvement. Back in the days of Windows 95 and 386’s, there were ways you could improve the operating system and hardware in substantial ways; a doubling in processor speed and a rewrite of the operating system got you protected memory, which meant less data loss.
A few years ago we reached the point where desktop hardware became commodified. For the average user, 1.8 vs 2.2 ghz makes no difference at all. It’s a question of how quickly your computer can wait for keystrokes and data from the internet. (Answer: even a lowly Celleron is light-years faster than the I/O devices it typically has to talk to. Even if you’re the last kid in your class at Harvard, you’re going to be bored discussing politics with a bunch of four-year-olds.) At that point things became very difficult for major vendors like IBM (sold out), HP and Compaq (merged), Gateway (bought out of it’s misery), etc. The price of a desktop plummeted from over $1000 to less than $400.
I believe we’ve reached the point where operating systems have become a commodity as well;
- Every major operating system has all of the features of a “real” operating system – that is, protected memory, virtual memory, plug & play driver support, etc.
- The performance for normal applications is just about the same; there are some specific variations that matter in the server market, but for all practical purposes the operating system is not in the way, and the machine is much faster than users need anyway.
- Every major operating system has a similarly designed GUI experience that, once you get used to the quirks of where the close box is, is just about the same, more or less. (Mac users – keep your pants on. 🙂
And this is why life is not so good for Microsoft. In a non-commodified market, you can charge a premium for incremental improvements over the competition. That’s a game Microsoft can play – they have a lot of capital to invest in changing their operating system, as long as they are rewarded with a lot of cash for doing it. (And normally they are – about six billion dollars for a major OS revision, I’m told.)
The problem is that operating systems are now a commodity. Simply put, users don’t need a new operating system. There are no big ticket features missing from OS X 10.4, Windows XP, or Linux 2.6. This makes Microsoft’s business model fundamentally vulnerable to Linux for the first time. If the name of the game is:
- Keep costs down, as low as possible.
- Incrementally improve quality very slowly without ever causing the pain of a major OS upgrade.
That’s a game Linux, with their army of distributed bug fixers and free source code, is going to win.
When I looked at Windows XP and Ubuntu 6.06 I was afraid that Linux wouldn’t make traction into the desktop market. I blamed the adoption of X11, the KDE/GNOME schism, and the Linux communities’ being made up of Shell nerds for the tolerable desktop experience.
But look where we are now: Vista is a vehicle for bloat. Combine “we make money by shipping major features” and “there are no more major features to ship” and you get Vista…an attempt to change a lot of things when you should have left things alone.*
By comparison, Ubuntu pretty much just works – you put the live CD on your machine, it asks you some questions and installs…it knows about more hardware, has less bugs, more drivers, and a better user experience. In a commodified operating-system space, the only thing to do is try to avoid a bad user experience – if you can’t offer a really juicy carrot to users, try to avoid hitting them with a stick.
And it is in this environment that the Mac is actually gaining market share. Apple’s business model has always been at odds with the industry. Complete vertical integration meant higher costs, lack of market share, and out-of-date technology – back when having more for less meant something, that was a real weakness, and explains why the Mac never dominated in market share.
But what a difference a decade makes! Hardware is now commodified (and Apple is integrated at the system-building level, leveraging cheap third party parts like they always should have). Operating systems are commodified. But on the one frontier left, quality of user experience, Apple’s vertical integration gives it an immense advantage.
The question is: why does an operating system “just work”?
- Vista: it doesn’t. There are too many systems and not enough testers and engineers trying to solve the problem.
- Linux: massive distributed engineering. For any given hardware system, eventually a Linux nerd will integrate it. Anyone can solve the problem of poor user experience.
- Apple: they have it easy. With only half a dozen machines in production (and maybe another two dozen legacy configurations to support) they have a much smaller configuration space to worry about than anyone else.
I don’t kow what Microsoft’s future is, but it can’t be very good. At some point they are going to have to transition from a “major revision for cash” to an “incremental tuning” approach to operating systems. As long as they have market share, they still get the “Windows tax” – that is, their OEM pricing from major vendors on every new computer that is built. It’s going to be harder and harder to convince the entire world to make a major jump (see how well XP to Vista went). In this situation, they’d be better off with a more solid operating system. It’s unfortunate that they’re going to have to try to sustain market share with Vista.
Their best-case scenario is that they eventually get Vista back to an XP-quality experience, in which case all they’ve done is spend a huge amount of R&D; money and pissed off a lot of customers to maintain the status quo.
* I have mixed opinions on Vista’s video-driver-model change. But that’s a different post.
Austin posted another State-of-the-Union yesterday, and he was good about only mentioning things that are fairly close to completion (e.g. the panel texture optimizations) as well as things that are general (e.g. threading optimizations). After a long beta, when 9.0 went final I sort of went crazy and started a whole series of new projects at the same time; here are some things that I have in progress:
- Major rewrites to the texture management code for both better orthophoto handling and better threaded performance.
- Moving the sim to unicode and true-type fonts, with a new system for translating the application’s strings. (I’ll post more on this soon – thanks to those who have already volunteered to work on translations!)
- Working on new shader technology to take better advantage of DirectX-10-class hardware.
- A big pile of airplane features to complement what was added to 9.0.
That’s a bit much for the next patch, so it’s likely that only some of these things will actually make it into the next patch, and I’m not sure what you’ll see. A lot of sim work goes in as a series of small independent pieces; only the last parts of a feature are user-visible.
For example, the first part of texture work was simply rearranging how the code was structured to make new things possible. Change to the user experience: none. The second part changed threaded handling of textures, which at least shows up as performance improvements. But both the stage for new features later.
So even if a lot of the above doesn’t make it into the next major patch, a lot of ground work is going in, setting us up for features later.
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.
