This post has been on my todo list for a while – long enough that X-Plane 11.40 came out before I had time to write up a post saying “X-Plane 11.40” is coming. But just to put 11.40 into context, here’s what our patch roadmap looks like for X-Plane 11 this year.
All Physics All the Time
X-Plane 11.40 is a physics release. Almost all of the changes in X-Plane 11.40 come from Austin’s work on the physics engine over the last six months. This is a new approach for us. In the past, when we’ve updated the physics or systems, it would be in a giant “omnibus” release, where everybody’s latest code went out at once (e.g. X-Plane 11.10).
The problem with the omnibus releases is that they would take forever to get debugged. With so many people changing so many things, we never knew what had gone wrong when a bug report came in. And with all of the code changed, we had to investigate every single bug report carefully (no matter how unlikely or vague the report) because anything could have been broken.
So far, at risk of jinxing the beta, it appears that the physics-only approach is working a lot better. It has been quicker to find bugs when they are reported, and the overall level of crazy is a lot lower than in past releases.
There aren’t many open bugs left in the 11.40 beta, but one particular bug has caused the beta count to run up: we were seeing crashes due to NaNs in the flight model.
NaN stands for Not A Number, and it’s what you get when you have divide-by-zeros run amok in the physics. To catch them, we’ve turned on a lot of auditing code and we’ve been collecting automatic crash reports. At risk of jinxing it, I think Austin has fixed one of the two root causes in beta 8. We are going to keep chasing them until the other one is fixed, then turn down the checks once we’re done. So we may make it to beta nine or ten and we may have another week with two betas; the high tempo is just to get more checks in fast.
There have been a number of questions in the comments on the state of the experimental flight model, so I want to clarify how it works and what is happening in 11.40.
Normally, new X-Plane features get beta tested during the beta of an X-Plane patch. This means we have somewhere between two and eight weeks to debug the feature and get it ready to ship. Once it ships, if we change the feature, we have to consider how this would affect authors using the feature and whether it would screw up their add-ons.
That’s not a lot of time to debug! In particular, it’s really not enough time for the flight model, where people need months just to develop the aircraft and measure the performance to get us feedback.
The experimental flight model is basically a giant year-long open beta of a future revision of the flight model that hasn’t shipped yet. By checking the “experimental FM” box, you’re getting to beta test the flight model of the future, now. By keeping the experimental flight model as an experiment for so long, this frees Austin up to simply fix bugs and improve it, as opposed to worrying how the X-Plane 11.40 experimental FM changes will affect X-Plane 11.30 users.
To be clear: there is no attempt at backward compatibility between the experimental flight model from one sim version to another! The goal is to have the experimental flight model not interfere with the “normal” flight model at all.
Physics changes in 11.40 fall into two broad categories:
Simulation changes that can change how an aircraft flies, improving the accuracy of X-Plane’s predictions about the airframe. An example of this is the delay in wash propagation from the prop to the tail of the aircraft. This makes the aircraft more stable, but may change how it flies; an author might have added artificial stability or reduced control surface efficacy to work around the lack of this feature in the past, and these work-arounds would be inappropriate with the new, more accurate physics.
Simulations that change how the aircraft flies in unusual circumstances that you can’t tune your aircraft to. Examples of this include stalls and wake turbulence. There isn’t going to be a book value for the effect, so all we can do is try to produce the most sane results given an aircraft that simulates properly in regular flight.
Features in the first category require the experimental flight model to be enabled, while the second category of features is always on.
At some point in the future, the experimental flight model will become the flight model for X-Plane, but we are not there yet, and we are not planning to do this as part of making X-Plane 11.40 final.
Third Party Aircraft
If you develop a third party aircraft, you need to test it now against both the experimental and non-experimental flight mode. If the non-experimental flight model doesn’t fly the same as 11.36, please file a bug, and please provide flight testing details. For the experimental flight model, you may see book numbers change a little bit; the real question is whether the overall physics response is better or worse.
Vulkan and Metal
X-Plane 11.50 will be the next major patch once X-Plane 11.40 is out of beta, and it will feature Vulkan and Metal support.
The marketing guys showed the Vulkan build of X-Plane live at Cosford last week; that build did not have any support for texture paging. Since then, Sidney has a basic texture paging implementation running, so hopefully we’re in good shape to get this into developer’s hands after 11.40.
Our expectation for add-on compatibility is:
Add-ons doing supported things, like 2-d panel drawing and UI should just work in Vulkan and Metal – we’ll take bug reports to fix compatibility issues.
Add-ons doing unsupported things won’t work in Vulkan and Metal at all. Your 3-d drawing callback won’t be called, or your attempt to grab internal GL resources will just fail (because none of our resources are GL).
X-Plane running under OpenGL should “just work” for pretty much every add-on, including ones doing sketchy things, and should be faster than 11.40 but not as fast as Vulkan or Metal.
I expect the Vulkan beta to be a relatively long one. We want it to start this year, but it probably won’t end this year, and my guess is that initially Vulkan will be fantastic for some users and will crash for others. During the beta we’ll gain useful information about how well Vulkan works “in the field” for different cards and drivers.
One reason I am looking forward to the Vulkan beta: we now have tremendous visibility into what the rendering engine and driver are doing. With OpenGL, the driver was often a black box. We still get reports of “the 3-d mouse in VR make my machine really slow” and frankly, we may never know why this happens to just some users and not others with the same hardware, drivers, and version of X-Plane.
With Vulkan and Metal it is going to be different. A lot more of the graphics work happens inside X-Plane, and the work that happens inside the driver is much more predictable, bounded, and can be viewed via modern profiling tools.
So while we will have a lot of debugging to do based on user feedback, it should be straightforward to get the information we need to really make the Vulkan renderer scream.
It’s a little too soon to discuss what comes after Vulkan, but I can say this: for almost two years now, Sidney and I have been rewriting the rendering engine with a rather strange goal: performance and predictability, but with the same visual output. So anything that looked ugly on the screen is supposed to keep looking ugly. Vulkan was a change of the how but not the what of our rendering engine.
Once Vulkan is out the door, that all changes. We have a number of fundamental changes we want to make to how we deal with light, with the atmosphere, with color, and with organizing our frame. Once we have Vulkan, we get to use it as our foundation for what comes next.
This summer when Marty asked if we could run the Vulkan version of X-Plane on our machines at the show I laughed a bit and then said “hell no” – at the time we were running scenery packs in the sim with default aircraft, but Vulkan was still a work in progress.
Vulkan is still a work in progress, but there has been a lot of progress, so when the marketing guys asked again I said “sure, yeah, what could go wrong” and Sidney cut them a build. We also told them not to throw out the shipping version, but if the app is well behaved people at the show may get to fly the Vulkan build for the first time.
Betas, Betas, Everywhere
At this point I’d judge us to be in the middle of the X-Plane 11.40 beta run. Beta 6 is reasonably stable and has fixed a bunch of problems that broke third party aircraft, and it’s now available to steam users. We’re still tracking down a bug where the physics code produces a NaN value. Since it just happens while flying and we haven’t gotten any useful reproduction steps, we’re pursing it by adding more checks and looking at automatic crash reports.
Please, always auto-report your crash. We don’t need you to fill out the description text field – just the auto-report and email is enough. We are looking for as many reports as possible, and we will probably stick with two betas a week until we chase this one down.
Third parties: if you haven’t yet, please test your add-on with the experimental flight model off against beta 6 – we don’t have any known bugs with the legacy flight model and third party aircraft at this point.
We are also killing off the last beta bugs in the new version of X-Plane mobile. There’s some really cool tech going into the lighting on mobile that I’ll write up soon in a blog post.
Observant Steam pilots flying VFR noticed that the Cessna 172’s windows were completely solid gray in 11.35 release candidate 1 – not a huge problem for IFR, but not great for site seeing.
This should now be fixed – if you let Steam update the app you’ll get the clear windows back.
This bug was totally bizarre and astonishing. The interior glass texture for the Cessna was missing from the installation, but not from the master files we build the sim from or from the Laminar version. As best as I can tell, Steam’s tool for building the sim just lost the file randomly. I rebuilt the Steam install this morning and the file came back.
Here’s a feature that went into X-Plane 11.35 that will be really exciting to a very small number of scenery authors: in X-Plane 11.35, line files (.lin) can have custom painted end-caps on each end, and the texture repeats can be aligned to a grid.
Scenery authors who have gotten deep into X-Plane’s scenery system will already know from that first paragraph why this is useful, but for normal people who have seen the sun in the last 30 days, .lin files are the art files that define the look of thin linear features. X-Plane uses them for the painted yellow and white lines in the airport environment, but a developer can use them for anything linear.
Line files repeat, tile, and can follow the ground in a bezier curved path, which makes them great for curved taxiway lines. Their achilles heal up to now has been that when the line ends, the line just … stops. This makes them inappropriate for really thick uses, where that hard “cut” at the end of the line would be really noticeable and ugly.
In X-Plane 11.35 you can provide a start and end cap for each line definition. Like the line itself, it can be mulit-layered if desired. So, for example, you could use it to make dirt paths between buildings in a rural airport – where the path ends you can have a “soft” ending to the path and not have to worry about tucking the line under another scenery element to hide the cut.
X-Plane 11.35 beta 4 is now live – run our updater and check “get betas”. Release notes here.
Steam users: we’ll release this tomorrow if there isn’t a sign of a huge fire overnight – it’s already uploaded to the servers.
Add-on Developers: if you haven’t run your add-on in 11.35, please put it through its paces now. Everything that might be risky or weird is already in and we’re just killing off bugs now. If your add-on has a compatibility problem, we need to know now if we’re going to fix the problem during beta. While we’ve tried to make everything “just work” with old add-ons, there’s always the chance that your add-on does something special we didn’t think of. Please test now!
Here’s our keynote talk from FlightSimExpo 2019 last week!
Evans video team really did a fantastic job with the feed this year – everything was live-streamed in great quality, and the talk has a direct feed to the slides and good quality audio. Totally what we were hoping for!
As you may have heard, we’ll be at FlightSimExpo 2019 in Orlando this weekend! If you are attending, please stop by our booth and drop in on our talk Saturday afternoon. We’ll be qualifying people for a VR landing contest too.
For developers: Austin, Philipp, Chris and I will all be there – find us to talk about developing add-ons for X-Plane!
Since my last Vulkan update, we now have the full sim running natively with Vulkan and Metal! There is still a pretty big list of random things turned off or bypassed to make this happen, but we can fly in the cockpit and use the sim.
Here’s some stuff that is now working:
Using regular and HDR rendering, and SSAO on metal.
Flying with Vulkan on AMD, NVidia, and Intel drivers.
Hardware stereo rendering on OS X – this never existed before Metal because the Mac GL drivers didn’t support it. Hardware stereo rendering is necessary for VR support.
MSAA on Metal – with the restructuring of our code, you’ll be able to change MSAA settings without restarting. I don’t know if this code works on Vulkan right now; it might.
Here’s some stuff that does not work yet:
Plugins are bypassed right now. We have not yet written the plugin-OpenGL-interop layer.
VR only works when using OpenGL as the driver; we need to write some new VR code to pass Metal and Vulkan frames directly to the OVR and Rift APIs.
Screenshots/Movie capture are a work in progress – that’s what I’ve been working on this week.
We still have a number of visual bugs, so screenshots are an important feature so we can run our automated test system. The test system takes hundreds of screenshots of the sim in many configurations and compares them to 11.30 to catch bugs introduced by the new Vulkan and Metal back-ends. Clearly I’ll have to fix my color problems first.
One fun aspect of this port: Metal and Vulkan copy Direct3D’s convention where the viewport Y axis points down and not up. This resulted in a whole series of weird “it’s upside-down again” bugs, most of which have been fixed.
(That airplane might look silly, but at least all of the image is consistently upside down. That’s because the only remaining upside down code is the movie/screenshot capture code itself.)
We should have some performance numbers to post next week; right now our primary focus is fixing bugs, particularly bugs that bring the whole machine down.
Here are a few more pics of things that have gone wrong during development.
Just a quick update on our progress with Vulkan and Metal. We last spoke about this on the live feed a few weeks ago, but we’re a little further along. Here’s the summary:
Plane-Maker and Airfoil Maker run in Vulkan and Metal.
X-Plane runs in Vulkan and Metal up to the main menu (e.g. the app starts) but can’t yet fly or show scenery.
The Vulkan and Metal code runs on Mac, Windows and Linux.
The Vulkan code runs on Nvidia, AMD and Intel drivers.
All shaders are ported.
All of the zoo animals (abstractions around part of the graphics engine) are now complete. We killed off the last 2 or 3 since the live feed.
For the last two weeks, Sidney and I have been working to port all rendering passes to the new code, so we don’t have to go through OpenGL to fly the aircraft. I lost a few days dealing with this:
That turned out to be a single if statement that got reversed deep in the mesh drawing code during one of the porting steps, resulting in some of the runway lights being replaced with random pieces of … heck, I never figured out what the wrong mesh was, just that it came from some other unrelated part of the sim and changed as the camera moved. To make matters worse, the error only appeared on the Mac, so we couldn’t use Windows OpenGL debugging tools to find the issue.
The silver lining is that once we are all Vulkan/Metal, we’ll have at least four separate debugging tools to go after bugs like this.
We don’t have measurements of performance yet; once we can sit in an aircraft in X-Plane running Metal or Vulkan, we can at least get some initial performance numbers.
We’ve posted X-Plane 11.32 release candidate two – it contains very few changes from release candidate one. If you think RC2 changed your framerate from RC1 (for better or worse), it is imaginary.
The big item for RC2 is that X-Plane now uses our own replicating METAR servers. NOAA weather was plagued by 404s when the server posted METARs didn’t meet the date/time scheme X-Plane expected. Our own server should serve the latest weather we have, whatever that is.
Over the last few weeks we have spent a tremendous amount of developer time investigating reports of instability, crashes and performance problems, and the results have been quite unsatisfying. We really haven’t found a series of smoking guns we could fix to improve stability. We have learned some things about X-Plane’s performance and stability though. The rest of this post gets into the weeds; if you tune out (and I won’t fault you if you do) the TL;DR is: please turn on our anonymous analytics, and click “send” if you get the crash report form. The more gathered data we get about crashes, the better shot we have at addressing the issues.
Crash Rates and Plugins
X-Plane’s overall crash rate (all causes is approximately 14% – which is to say, for all of our users using analytics, for every 100 times they launch X-Plane, the sim quits in a way we did not expect or want 14 times. This number has been remarkably stable – it’s not a ton different between 11.26, 11.30, 11.31 or the 11.32 beta.
The sim quitting on purpose because of bad content is not considered a crash. For example, if you load a DSF with a missing .ter file, the sim will refuse to proceed and quit. This failure mode is user hostile in that you can’t fly, but it’s not a crash – the refusal to load is the code working according to design. While I would like to make this code less hostile to users, it’s also worth noting that these cases are ones where the author of the scenery pack would have been able to fix this if they had loaded their own work even just once. That is, they are caused by an add-on that should not have shipped.
(There is an in-between area where an add-on is mis-installed because it has a library dependency that the user hasn’t met. This is a deployment problem that really needs to be solved, but it’s orthogonal to true app crashes.)
We categorize crashes into plugin and non-plugin crashes; starting with 11.32 we actually get a statistical picture of this. A crash is a plugin crash (and you see the “we crashed because of a plugin: XSquawkBox” or whatever) if the sim crashed while executing code on behalf of a plugin or inside the plugin on the main thread.
There are a bunch of cases where plugins do not get correctly tagged – in particular, we regularly see crashes on random worker threads spawned by plugins; since we don’t know whose thread it is, we can’t blame the plugin. For example, the FF A320 crashing inside CEF on a worker thread is registered as an X-Plane crash (and we see it in our auto-reporting view) but it’s not our code and there’s nothing we can do about it.
One thing I’d like to do in future patches is improve diagnostics. The rate of actual blamed plugin crashes appears so far to be quite low, and given that we do see uncaught plugin crashes in our data on a regular basis, I think this is a case where add-on authors can only fix what they can see. If we can attribute all plugin crashes to plugins, then the plugin authors can catch their own bugs. Better diagnostics also helps a user remove a troublesome add-on in the case where that would help.
We have a few cases where X-Plane hits an error condition and deals with it by crashing. This is pretty bad, drives up our crash rate, and is something we need to fix to be less user hostile. For example, if a PNG file is bad (either corrupt contents or the sector on disk that backs it has gone bad) then X-Plane’s response is usually to mysteriously crash. Besides being rude, the crash gives an end user no idea which file is bad, and thus no way to fix it. X-Plane ships with something like 9000+ PNG files and over 2500 DDS files, not counting add-ons, so if we don’t tell you which file is bad, you’re not going to find it by poking around.
FMOD sound bank incompatibilities is another example – if you have two aircraft sharing a byte-wise copy of the same FMOD data (e.g. command-D duplicate the C172) loaded at once – then our FMOD loading code fails and then registers as a crash. The code is working exactly as we designed it, but the design isn’t robust enough. As we’ve learned, in the real world users duplicate aircraft (and their FMOD packs) on disk all the time.
The crashes in this category are things where we’re being user-unfriendly and better code would make these problems go away or leave users with a way to actually fix them. But they’re not case of “weird stuff inside the sim blew up.”
Persistent Stability Problems
In the crash data we do also see a few persistent stability problems. There’s some kind of crash in the ATC system that we’ve seen for a very long time but we don’t know how to reproduce. It’s a case where if enough users do enough random stuff, we hit an edge case in the ATC system that isn’t handled correctly. The solution here is to embed more diagnostics at the crash site until we can understand it from the reports we get from users. Please hit “send” when you crash – don’t worry about filling in the fields – it’s the report itself that we need.
We also see a lot of crashes inside the OpenGL drivers, from all of NVidia, AMD and Intel. Because the IHVs don’t share symbols and source code with us, we really can’t tell what went wrong in these cases.
My hope is that with Vulkan we’ll have better options for in-driver crashes. With Vulkan, they redesigned the error checking model: error checking is a feature you enable (via a configuration option at app startup) that brings a layer of code in on top of the driver to check what the app is doing. With error checking off we get the fastest framerate, and with error checking on we get slow framerate (more error checking means more slow) but some really great diagnostics.
(To put this in perspective: when Sidney ran the Vulkan version of Airfoil-Maker on Linux with the wrong driver installed and no error checking, it rebooted his entire Window server! So no error checking really means: no error checking.)
Since error checking is optional and selectable when the app runs, we could put an option into X-Plane to run in “safe mode” – if a user is hitting persistent stability problems in the driver, that user could turn on validation and possibly capture an error in X-Plane itself that would otherwise just be “the driver crashed.”
Running Out of Memory
I’ve worked with a few users to try to track down the out of memory problems we’ve heard about, and there isn’t an obvious pattern here. Some users report running out of memory in 11.30, but when put back on 11.26, find that they still run out of memory. We get more out-of-GPU-memory complaints on 11.30, but that might be because a few cases in 11.26 that were crashes due to running out of memory now report the problem in an orderly way. In 11.26 they were just mysterious crashes with a “send” form.
In the cases we’ve seen, the user running out of memory was often…actually running out of memory – that is, the surprising thing is not the crash but that X-Plane ever worked at all on those settings. The fundamental problem we face is that we have no visibility into what the OpenGL driver is doing with GPU memory. The OpenGL tries to manage memory no matter how much we ask for, and if it fails, we don’t know what went wrong.
The good news is: we have much better options for Vulkan. With Vulkan, we manage memory, which means we know what’s going on, and we can take steps to avoid out of memory crashes. If we do run out of memory, it should be for much more obvious reasons. We’re still analyzing what we can do about memory with Metal, but the choices should still be better than OpenGL.
The only advice I can offer now if you are seeing persistent memory crashes is: turn your settings down or use less add-ons. If you push X-Plane to the limits of your hardware, it may work for a while and then fail.
Sidney has looked at a lot of performance data from users who reported low framerate, and in almost every case, the performance has been as-expected. The most common case we see is users with relatively low single-core CPU performance hitting low framerate at high rendering settings while their GPU is bored. To put some numbers on this, if your CPU’s single-core geekbench score is down around 2000, you are almost certainly CPU bound, way at the bottom of what’s okay for X-Plane, and a new GPU won’t help.
As of now, X-Plane cannot use large numbers of cores (e.g. a 32-core machine is useless) and gets only limited performance boosts for framerate with multiple cores under some circumstances. This is something we are working to change in the future, but it’s not going to change quickly. If you are looking to improve performance with hardware, single core speed is still the most important metric.*
In a few rare cases we saw performance that was disproportionately bad compared to what we’d expect from an old CPU. We’re trying to gather more data from these users but the case is rare enough that we haven’t gotten a useful report yet. If we find a smoking gun, we can act on it.
Like memory, Vulkan will help with diagnosing performance. With Vulkan, more of the code is written by us and the Vulkan code we run has very predictable timing. So when we get complaints about performance, we’ll be in a much better position to understand what is slow and why.
I’m actually not sure what the next patch will be, but we do have a bunch of bug fixes to 11.30 waiting to go out once we have stabilization under control. I also have a pile of bugs that I have not yet fixed that are high on my priority list where something in 11.26 stopped working in 11.30. So if you have filed a bug that’s not fixed, we have not forgotten about it – it’s either next to come out or possibly on the short list.
* Yes, we realize that this dependence on single core speed is bad. It’s just going to take time to move to Vulkan and then offload the single thread.