EXPERIMENTAL USE ONLY!!! -- [What?] -- Login to add public annotations [How? >>YouTube].

X-Plane 11.40 is now final! You will be prompted to update to X-Plane 11.40 when you start X-Plane; Steam users will receive the update automatically via Steam. Here’s what’s next in the pipeline:

We are working on a bug-fix update (11.41) to catch one or two bugs that didn’t make the RC, as well as the inevitable bug that will be reported after go final. I expect to cut an 11.41 release candidate some time next week, and it should be a pretty quick release.

In the meantime, we are pushing hard to get Vulkan/Metal ready so that we can do an X-Plane 11.50 beta. We may start private testing of Vulkan and Metal before 11.41 is done, depending on what gets fixed first.

The limiting factor on getting to a public Vulkan/Metal beta will be bug fixing – it doesn’t make sense to go public beta with known bugs that will be reported over and over and make the beta unusable. There are also two remaining areas of development we need to close up:

Load Times

Vulkan and Metal fight stutters by pre-loading everything they need to render the frame – this means whatever we need to draw, it’s ready. But this also means X-Plane needs to prepare every shader it might need to render a given aircraft and scenery pack.

Because X-Plane’s shaders are so flexible, this can mean tens of thousands of shaders, and that hurts load time. We have new code that tries to analyze exactly what we’ll need for a given frame. For example, if an object comes from a DSF, we never need an “interior” shader for it because the scenery object can never be inside an aircraft. By carefully applying this kind of logic, we can cut down the number of preloaded shaders and speed up load times.

Sharing Memory

With Vulkan and Metal, X-Plane manages its own use of VRAM – this is a totally new capability that we have had to code from scratch for the Vulkan/Metal port. We watch our total memory usage and reduce texture resolution dynamically (hopefully on less important and less used textures) to stay within budget.

While this code is working, it hits a wrinkle on Windows:

  • Third party add-ons that chew up VRAM via their OpenGL VRAM usage can use up part of our budget. For example, if you change to an aircraft with a plugin that allocates its own textures to render to, we can’t use that VRAM anymore.
  • The Vulkan version of X-Plane allocates VRAM in big blocks for efficiency. If we reduce our texture res to make room for the plugin, we might end up with a bunch of big pre-allocated blocks (that are mostly unused) inside Vulkan – the memory still isn’t usable by the OpenGL plugin.

Sidney is working on compacting our textures so that some of the big blocks can be given back to OpenGL – yet more new memory management code for Vulkan.

There Be Dragons

Once we have the number of shaders cut down and memory compacting working, we’ll begin heavier testing of the Vulkan/Metal build – I can’t say how close to public beta we are because we haven’t gotten the initial wave of bugs from this testing.

About Ben Supnik

Ben is a software engineer who works on X-Plane; he spends most of his days drinking coffee and swearing at the computer -- sometimes at the same time.

37 comments on “X-Plane 11.40 is Final”

  1. Very informative post and exciting times.
    I hope any dragons are easily slain and the Vulkan release goes smoother than in the many fevered dreams you have likely had while coding it.
    Many thanks.

  2. Its always fascinating reading this blog as it reveals the inner working of XPlane, even if I don’t understand it all. Thanks 🙂

  5. Is VRAM allocation a balance act in Linux too? Can’t say I would be surprised given that system RAM allocation behaviors seem to be quite different between win10 and linux. In my case, the latter seems to be the hungry hippo (causing system freezes even) but I have yet to figure out which kernel is eating all the marbles (Linus or Austin/Ben).

      1. Any word on how the “private” test will be distributed? same as with the early private beta for 11.40 or something else.

        Happy to crash it for you on linux as much as you need. Dont use any opengl plugins tho.

    2. In Linux there exists a “pmap” utility that can display all the memory areas a process uses. For example I see that …/voices/default pilot/default_pilot.zip is loaded with roughly 115MB. And I see many small rendering objects (/dev/dri/renderD128).

  6. Happy birthday X-Plane 11.40! Great update and news!

    Would like to take part in the private testing of Vulkan and Metal, if possible! (Linux and Windows).

    Many thanks!

  9. Ben,

    Thank you all for your hard work. I really want to learn to fly and my wife really doesn’t want me to die in a general aviation crash so x-plane is the compromise.

    I am very interested in all the detail about Vulkan/metal and future directions you want to take the rendering engine that you are willing to share. I understand blog time takes away from home/hobby/family time, so I won’t complain if you can’t blog about it. Should you be able to though I wanted to convey thanks and appreciation.

    1. Use X-Plane as a learning tool to supplement your lessons so you have less chance to die in a real aircraft. Either way, if you really want to fly, go do it. Otherwise you’ll regret it on your deathbed. A bit morbid, so to put it another way: “Better to live a single day as a tiger than an entire lifetime as a worm.” (Cat from Red Dwarf).

  11. Two little issues still existing:
    1. Sometimes cars and trucks are not moving in Replay Mode.
    2. Aircrafts can’t be seen through windows when you are within a tower.

    1. Yes – these have always been true – they are _design limitations_, not bugs, e.g. the systems were never designed to do these things. I do agree that both would be good and both are on our roadmap.

    2. While we’re on it: AI vehicles drive through airport fences and through each other (seen at KBFI). And even small planes are served by big food trucks 😉

  12. Great Job everyone, so, if you want a Guinea Pig for the Vulkan Version, cont me in. I have a RTX 2080 TI (11Gb of VRAM) and 64Gb of RAM… so a lot of memory to be eaten….. just let me know how can I help…

  13. Hi Ben,

    Thanks for the insight into 11.50, its very insightful (cough…)

    Based on the comment you made “While this code is working, it hits a wrinkle on Windows:”, does mean Metal manages VRAM differently to Windows?

    1. Slightly, yes. Vulkan allocates VRAM via the Vulkan Memory Allocator open source library (which is just awesome, so mad props to Adam and AMD) for most of our allocations – VMA divides up large driver-provided blocks to get the smaller blocks we need. With Metal, the driver provides smaller memory blocks directly for everything we need and probably contains its own sub-pool allocator.

      The key difference here is that when we free memory in Metal, the memory is visible to the driver immediately and hopefully can go to plugins/GL. When we free memory on Vulkan, if the allocation is part of a big block and the block isn’t completely free, the big block remains with X-Plane. So we have to move our allocations around to try to consolidate.

  14. Thank you Ben , the X plane simmers appreciate a lot involves us in the evolution of X Plane, if i well understood, you must launch X plane 11.5X stable with Vulcan/Metal & Open GL, so the next step in 2020 will be an X plane XX Only with Vulcan/Metal and no openGL ? again thanks for all the Dev’s team !

  15. Hi, please, fix the global or ,,ambient” sink rate, when thermals are enabled. Like it was stated before the sink rate between thermals should be zero globally (with some exceptions)

  16. So, if I understand this correctly, any 3rd party add on will need to convert to Vulcan to take full advantage of Xplane 11.50

    1. No, this is not correct at all. There is no conversion to Vulkan for third parties. It will either work or it will not. If it does not, you can use it with the OpenGL back-end.

  17. Looking forward to Metal! I’m running older hardware, my processor is only an i7-3770. It does ok (my graphics card is the bigger bottleneck right now, but that should change soon), and I can get over 20fps (usually) at lower settings unless there’s weather. I’m really looking forward to a performance boost as I currently only run ~25% total CPU utilization. If you want some performance checks on processors that old, please contact me! I’d be happy to help.

  18. Great News! So the Mac version will use Metal, natively or will it implement MoltenVK to wrap and execute the Vulcan code on the Mac?

  19. Hi Ben,
    Maybe I’m wrong but has the obj8 compilation code changed in X Plane ? I ask because I’ve observed that some custom models had an issue where a switch got “stuck”. It moved once but it couldn’t be moved back. In those cases the cockpit.obj had “min” and “max” values inverted. That is the case of some manipulators like but not only ATTR_manip_axis_switch_up_down where for instance “min” is set to “1”‘ and “max” to 0. In versions lower than 11.40 this would be discarded but since about rc1 this seems to mess up the manipulator. Correcting the value in the cockpit.obj cleared the error. Of course being more strict in implementation and sticking to the syntax is what is expected. But I just wanted to put this out for 1) knowing if it is on purpose 2) letting devs know so they can easily correct their models should users complain about stuck switches since 11.40 rc1 if my observation is correct.

    1. Sigh…This is a known bug that will be fixed in 11.41…XPD-10382. This is why we can’t have nice things. I changed a low level routine to have slightly faster code generation as part of some work I was doing…the result is that our clamping math routine produces different results when the inputs are illegal.

      As it turns out, swapped manip extrema (which is illegal in the OBJ spec) hits this case and causes “working” stuff to “break”.

      I’m putting the math back the way it was and drowning my sorrows for 11.41…if we can make the obj parser more robust we may be able to get this back. The perf improvement was really tiny – it was part of an audit of all of the low level math funcs that were in a particular hot loop.

  21. Heads up: I just filed a bug report on mic permissions. I thought the issue first appeared in 11.3, but I may have been incorrect: it may be new to 11.4. Sorry for the confusion

Comments are closed.