I’ve posted a number of times on the transition to 64-bit, we have release notes and a FAQ, as well as a number of tech notes for plugin developers, but in this post I want to cover how I see the community moving over to 64-bit.

64-bit is a fundamentally confusing issue – it’s one of those things that should be totally transparent to computer users, but due to the nature of code and plugins, 64-bit is not transparent.  So more explanation will hopefully at least not confuse the issue even more.  Maybe.

Is a Transition to 64-bit Even Necessary?  Does it Have to be Now?

The short answer is yes.  32-bit applications simply cannot take advantage of more than 4 GB of physical memory (among other limitations).  Every year CPUs get faster, people get more cores, GPUs get faster, GPUs ship with more VRAM, and every now and then we even get a faster PCIe bus.  During this time hard drive, SSD and RAM prices continue to fall.  You can bring your computer up to 8 GB of memory (Crucial memory – good stuff!) for $34.  But what’s the point if the app you are feeding is 32-bit?

In other words, the march of hardware is unrelenting, and if we want X-Plane to be able to use the full power of our computers, we have to go to 64-bit.

How soon do we need to go to 64-bit?  Mac users who like add-ons have been crammed up against that 32-bit ceiling for a while now, while Win 7/64 users mostly still have some headroom.  But the real question is: could we finish out a major version run in 32-bit?  Could we wait years to go 64-bit?  I think the answer is no.  Even if we didn’t care about the RAM limit on Mac and Linux* 64-bit will become a Windows issue too; it’s only a matter of time, and I suspect not that much time.

The Phases of Adoption

This is how I see the migration from 32-bits to a 32/64-bit world going:

  1. Beta.  That’s where we are now.  In this phase, 64-bit technology is unproven even in the sim itself.  Plugin developers are hopefully trying the 64-bit betas and looking for major critical bugs, but 64-bit isn’t useful for actually flying. (Well, the sim is beta, and I never recommend flying on the beta.)  I don’t expect anyone to ship a 64-bit add-on during this phase.
  2. Crossover.  Once X-Plane 10.20 goes final and we have a stable 64-bit build that third party developers can actually test against, we’ll have a phase where some add-ons come out in 32/64-bit formats and others are not yet ported.  The length of this phase will be the difference between the fast and slow add-on developers; different plugins will take different time to port, have different levels of complexity, etc.  During this phase, users will have to pick 32-bit for compatibility or 64-bit for memory use.
  3. Acceptance. Eventually we’ll arrive at a point where so many add-ons have been made 64-bit compatible that the norm and expectation is that all add-ons are 64-bit, and the community will mostly have to abandon add-ons that are not migrated forward.

Note that “acceptance” is not only after 10.20 goes final but there is an entire phase between 10.20 going final and being able to “just run all add-ons in 64 bit”.  This is because it is going to take time for people to move their plugins forward.

32-bit Still Works!

I cannot emphasize this enough: there is a 32-bit build of X-Plane in the 10.20 betas, and it should just work!  The switch from 32 to 64 bits is not a binary transition where we pull the rug out from under everyone in one swoosh and everyone scrambles.  It is the beginning of a migration that can happen over time, while 32 and 64-bit apps areboth available to everyone.

* I have heard people tell us that we don’t care about the Mac just when it is surging, that we should drop everything but Windows, and that Linux is, in fact, the wave of the future. We’re going to hedge our bets and keep supporting all three.  Having done the work to be cross-platform it doesn’t make sense to drop multi-OS support.

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.

28 comments on “Phases of 64-bit Adoption”

  1. ten point zero alpha one should have been 64-bit already, because X-Plane 9 already showed the issues with memory – at least for Mac users. But well, we’re there, finally.

    “64-bit isn’t useful for actually flying”

    Some people don’t have a choice and I’m happy that I can fly again after a year full of head scratching about when X-Plane will tansition to 64-bit. So thank you and: I use it. Therefore it i useful 😉

    1. (Wham. Bam. Pow.)

      “Wiiiiiiiiiilllllbur!!! Noooooooo!”

      (Wham. Bash. Bang.)

      Okay Markus, I think you’ve beaten the “Laminar should have moved to 64-bits a lot earlier than it did” horse enough on this blog. 🙂

      If the 64-bit beta is useful to you, that’s great! But you know that I have to tell people _not_ to use it for flying…a user who really understands what a beta is can take a calculated risk of using beta software (and have only himself to blame if it crashes, but then hey, keep two copies); but users who do not understand this risk may just go “oh, latest, shiny” and then be in for a rude surprise.

      1. I know ;). But I had a reason. You will realize that when you realize that the “Acceptance”-Phase is already going strongly.

  2. Ben, Obviously this is going to take some time/ and plugins are affected, But I am still confused at how drawn out this is to get this done, I would like to understand how plugins are related.

    1) do you see many months needing to occur before we reach past acceptance/ have many payware planes?

    2) more importantly, 64bits main thing was to eliminate memory crashes; but even under 64bit i still get crashes. Also, if 64bit only adds memory use for the time, then why/ how does that impact plugins. Other words, why doesn’t the code to fix the memory only impact that area and not hinder others while in process?

    Thanks, just wanted to understand

    1. Hi Chris,

      1. I have no idea, but months, not weeks. Movement to 64 bits will be gradual. We’ll have to wait and see – a lot will depend on the demands of the community.

      2. If you still get a crash in the 64-bit build, use the auto-crash-reporter to file it and we will investigate. The only 64-bit build is a beta, so it’s clearly _not_ bug free. 64-bit does not fix all crashes. But it does fix out of memory crashes, which were the overwhelming majority of reported crashes on Macs.

      Plugins have to be changed because 64-bit is an ABI change – it changes the fundamental way that all _code_ running in x-plane uses memory. Only by changing how the code is written (the ABI) do we get access to the memory. Since plugins run inside X-PLane, their code ABI must match the host (X-plane) code ABI.

      The OSes we support (Mac, Windows, Linux) do not let us mix & match a 64-bit sim with a 32-bit plugin.

      In other words, if we could fix the memory issues by just writing new code, there’d be no plugin change. But we changed the ABI of the code – the very nature of the code itself. It’s a little bit like changing a book from English to Chinese – the ENTIRE book has to be in the same language.

      1. Ahh interesting, I figured if you guys would have simply changed the memory issue and left plugins alone if possible, obviously not the case. Thanks for the explanation, trying to understand x-plane dev from your side also more so. As far as crashes, I am submitting them, I would look at them myself but there is no document app to open it, unlike a log txt where I might be able to see an issue. so i have no idea if its memory or not. I have noticed more crashing at 16GB ram vs 32GB. Hopefully developers are testing and working on their planes so the wait time is not extended more months longer past 10.20 final. I think we all see this time buffer from 64bit beta until add ons are adapted , autogen set and x-plane 64bit stable as the calm before the storm with more companies and developers making things for x-plane and more happy fans. Would be cool to see spring time 2013 onward be the stepping stone. I have the 10.11 installed and 64bit, hard to go back and forth picking and choosing; till that day comes, following progress is interesting.

        – chris

        1. You don’t seem to “get” it, Chris.

          This is not just a Laminar or X-Plane issue. This is an every program issue. If any game or any program for that matter go 64-bit, then everything about it must be 64-bit. Even operating systems will operate in this manner. 32 != 64! There’s no way to just “leave plugins alone.”

          1. Well, it is a “most” program issue — most 64-bit OSes offer mixed operation _between_ separate programs…but yeah, the Kernel of the OS is always in just one mode and the stuff running in the kernel’s all going to be in one ABI. Similarly, any other in-process-plugin system has the same “all the same ABI” issue. But programs that use IPC for plugins can run in mixed mode if the IPC protocol is tame.

            See also here:

            //www.neowin.net/news/firefox-for-64-bit-windows-os-canceled

            Even though Firefox runs plugins out-of-process they _still_ couldn’t get everyone over to 64 bits…or at least, they thought they couldn’t.

            In the case of X-Plane:
            – In-process plugins make certain things, like custom OpenGL accelerated drawing onto the panel, possible at high performance.
            – 64-bit is enough of a carrot to bring everyone over in time, I think.

  3. Ben, I guess you forgot to mention point 4. Aftermath. 😉
    I’m sure there’ll be pretty huge “movement” after 64-bit version is getting rock-solid and there will appear plugins that will use just 64-bit (just because it will be not possible to have them on 32b)
    Then 32-bit-users will start cry they are not supported properly 🙂

    1. Yes – some plugins may end up 64-bit only..particularly new ones where the author does not want to compile more times. I am hoping that plugin developers will keep 32-bit builds in for the rest of the v10 run – there are still plenty of x-plane users not running 64-bit OSes.

  4. I’m sorry but I think xplane is incomplete, since first release we’ve been all this time in a BETA stage, including the final versions. I understand that you work hard to improve it, and understand that it takes time, however I think there are critical areas that are not being taken into account. I currently play in 32bit, When pluggins aircraft works, then there are errors, but these are forgiven only with the idea of ​​having a simulation experience, but it is quite frustrating trying to make a flight in conditions, so you take 45 minutes flying and ATC gives orders to a death in the mountains … turn off the simulator, then turn on your simulator again and you keep trying, but you realize that is not yet finished.

    I think “eye candy” are fine, also improve technical capabilities, but the functionality should be above

  5. by the way, I want to clarify that I am a fina consumer, I am not a developer ore some like that, the only reason to buy a flight simulator is to enjoy it, which so far has not been entirely satisfactory,

  6. Hi Ben,

    There’s a feature I would like to request. It’s not really about plugins, but has to do with the transition to 64-bit.

    I am developer of FaceTrackNoIR, which is a free alternative for TrackIR. To relay headpose-data to X-plane, I intend to use a virtual joystick. Why? Because it’s totally transparent and can be used by anyone who wants alternative head-tracking.

    In the X-plane GUI, it is possible to assign joystick-axis to view left/right and view up/down, so that works fine. To support 6DOF, could the developers please add assignments for view roll left/right, move left/right, move up/down and move forward/backward?

    Thanks in advance.

    1. Hi,

      I think you should really integrate FTNIR with X-Plane using a plugin, not a synthetic joystick; the plugin system has all of the right hooks to support camera movement info (and coordinate the ownership of the camera, change of views, etc.). The joystick system really isn’t meant for this.

  7. Seems that I am the only one not frustrated by X-Plane’s development. Since 64-bit has to come, I think guys at Laminar choose the right path to go. There were 3 options for them:

    a. Postpone the X-Plane 10 release until is 64-bit 100% ready. But that may mean another 1-2 years delay to the release.

    b. Let XP10 at 32-bit and go 64-bit for XP11. That seems even worse cause XP10 will never take advantage of the new technologies (software/hardware) and XP11 will probably come after many years.

    c. Do what they did. Start the development during XP10 run. That way we have both stable 32-bit, and in a few months 64-bit too. Of course that requires a bit of patient to the point that all things we come together.

    Who haven’t bought FSX when Microsoft release it and after a few days went back to FS2004? FSX took more than to years to established as a solid alternative to FS2004, and even today I’m seeing many post how to make it run well.

    1. This is a pretty good analysis of the alternatives. Every project management decision is a trade-off, and when to go 64-bit is one of them.

      I must point out one other aspect of this: memory exhaustion on Mac is very much a function of _which_ add-ons you use.

      – If you have a lot of VRAM in your GPU (somehow, e.g. you’re using a flashed Fermi card) then high-texture-res add-ons chew memory. If you don’t have the VRAM, your texture res is down so it’s moot.

      – Not all scenery uses memory equally. Paged orthophoto sceneries are very RAM efficient; osm2xp is quite RAM inefficient because it puts a huge amount of data into the facade engine and the facade engine was never meant to be used in that wide-spread of a manner. (Note the _low_ percentage of facades in the global scenery compared to OBJs, which are more RAM efficient, and compare that to an OSM2XP city import!!)

      – Here’s one insanely RAM-hungry add-on: XSquawkBox. (This one is my own fault – it’s my own code from years ago.) Years ago XSquawkBox just consumed virtual memory because it was designed for computers with 128 MB of VRAM or less…in that world, loading “all” of your CSLs was no problem. Over time, the CSL collection out there has grown and grown, causing XSB’s RAM usage to become more and more problematic.

      So…in your list of options, there was another one, option d: _drop_ some major feature of X-Plane 10 and replace it with 64-bit support. I didn’t see a good trade-off option for this; the only project management option we could have done would have been to defer next-gen city autogen to X-Plane 11 and used the existing v9 cities right into v10.

      Had we done this, it would have saved a ton of time on the schedule – but it also would have cut our RAM usage down, making the 64-bit feature that we were adding in its place a little bit premature and pointless.

      As a final thought: X-Plane has always been about attempting to transition technology during version runs, rather than saving tech until a major version change and just dropping a bomb of new code on everyone. Consider: most of our multi-core technology was rolled out in patches during v9. Had we not done that, everyone would have been waiting for v10 to get any real multi-core support, and the beta for v10 would have been hellish (as it would have been filled with all of the multicore bugs in one single beta). For a company of our size, rolling out tech incrementally makes change possible within our development budget and gets new tech to users _years_ earlier.

      And hey, if you think option a (postpone v10 for 64-bit) is a win, then just use v9 now, and grab v10 when 10.20 goes final. 🙂
      And hey, if you think option b (postpone 64-bit to v11) is a win, just use the 32-bit X-Plane 10 from now until v11 comes out. 🙂

      cheers
      ben

  8. Hello Ben,

    Thanks for your reply. Actually, I don’t really agree with you.

    Like I said, the view left/right and up/down axis can be mapped to joystick axis. So at some point in time the developers must have thought that it would be nice to enable head-tracking via a (virtual) joystick. So the feature I request is only an extension of that thought.

    1. You don’t have to agree with me, but since I am one of the developers, I have slightly better insight into what ‘the developers must have thought’. 😉

      Seriously, the view axis is meant to provide some level of view control but _not_ full head tracking or a full camera interface. That joystick interface was meant to deal with a joystick with a hat switch.

      And honestly, it’s moot. The plugin SDK provides a superior interface to joystick axes for camera control – this why I am telling you to use it. With the plugin interface you can control the camera in a manner that completely covers what you want to do, can be completely automatically configured, and has been stable for about ten years.

  9. Hi Ben,

    Thanks again. I understand that the joystick interface may not be meant for it.

    Actually, I have contacted Sandy Barbour about extending the functionality of his PilotView plugin. Unfortunately he is rather stubborn and neither wants to change his code, nor share it. Hope he changes his mind…

    BTW.: The PilotView plugin implements a TrackIR interface and if I understand correctly, it was there even before the developers made TrackIR support. If the plugin SDK is the best way to control the camera, why did you bother to make a ‘native interface’ (when a plugin already existed)?

    1. Well, it’s his code, so he pretty much gets to do what he wants with. 🙂

      The SDK interfaces are not that complicated, however, and there are a number of example plugins, as well as a number of camera control plugins. I think you will find writing a plugin to be ‘not that bad’, really!

      Re: the native TrackIR interface, I have _no_ idea why it exists, as I did not code it. X-Plane does have native hardware support for a number of random devices, some quite common and some rather obscure. But this is a bit moot – if LR hasn’t offered to do native support of your hardware, your options are, in order of good-to-bad:

      EDIT: let me amend this list.

      1. Write a plugin
      2. Have Laminar integrate your hardware for you.
      3. Try to use the existing joystick interface and the existing UDP interface.

      I think it’s better to write a plugin than have LR integrate your device. The reason: when you write a plugin, you can make your device work the way YOU want – when LR does it, if you don’t like the integration, good luck…we’re very busy and don’t have a lot of time to tweak these things. It is for this reason that I always push for plugin-based integration and not ‘native’ code inside X-Plane.

      GoFlight used to be supported natively inside X-Plane and the results were very limited – we only supported a few devices, in only a few ways, etc. The GoFlight plugin is way better, with complete device support and complete configuration. By having the integration done by the hardware vendor, someone who is really motivated to make the integration good can put in all of the detailed work needed. This is the whole reason to _have_ a plugin system!

      Cheers
      Ben

  10. hey ben, great to see the livery change coming in b6 and more terrain changes, but sadly no Lits on autogen, can you see when that will come; kind of a big drawback from all the goods

    thanks

  11. Hi Ben,

    I think the plugin-system is a good development and I’ll look into it for sure. In the meantime, Sandy seems to have left the door a wee bit open, so my hope on his integration hasn’t completely vanished…

    The path to 64-bit may be long and bumpy: let’s hope it’s worth the trouble 🙂

  12. 64bit port is really exciting but you should complete more urgent and basic features first and then move to 64bit imho.
    Atc is one area which is undeveloped to say the least, what is the plan regarding vfr atc?

    1. I don’t agree. i feel that in order for the good stuff to come, i.e, atc, improved performance, framerate, graphics, auto gen, that a good solid, reliable base needs to be in place for the developers to do their stuff. As ben has said, hardware limitations have moved forward somewhat and you need to bring the core of your software, whatever software it is, in line with current requirements. Larger companies have different departments for such things. I believe LR to be quite a small company, I don’t know how many developers they have but they have to work within the resources they have! I believe 64 bit to be THE way to go. I have already experienced fewr crashes an the few 64 bit flights i’ve had. Whats the point of having superb atc direct you only to have a memory crash before you get to final!

  13. Have you thought of utilizing a 32-bit launcher that checks for 64-bit compatibility before launching the X-Plane executable? On a 32-bit windows system, if you try to just run the desktop shortcut created by the installer (pointing to the 64-bit executable), you just get a generic win32 error message. Not exactly user-friendly. If you had a launcher, it could check for 64-bit compatibility and run the appropriate version of X-Plane without the end-user having to know any different. The 32-bit launcher itself will run fine on a 64-bit system. I suspect this would be pretty trivial to implement, and save less-pc savvy users from having to find the win32 executable.

Comments are closed.