For the last few weeks we’ve had the Vulkan/Metal version of X-Plane in a private test program with third party developers, letting them kick the tires to discover the limits and bugs in our plugin compatibility code.

While the initial bridge to connect OpenGL-based plugins to X-Plane worked pretty well, compatibility wasn’t perfect and we had a few bugs. We also realized that we needed to change the design of that bridge to get much better compatibility. That rework of the bridge is now done and things are looking quite a bit better on all fronts.

We found one unexpected result from this redesign: when we finished rewriting the bridge, we ended up with code that could, in the case of Vulkan only, be used for 3-d drawing. This means we can now support OpenGL-based weather/cloud plugins from inside a Vulkan render, which we did not think was possible before.

The Skymaxx and xEnviro developers are in our private test program and have been great about jumping on new builds while remaining radio silent while we test this new tech. I am pleased to now be able to say: it works!

Those pics are a special build of SkyMaxx running in 11.50 in Vulkan mode. No more having to pick – you can have your third party clouds and Vulkan at the same time.

The Details: Vulkan, not Metal

3-d drawing compatibility will be available for Vulkan, but not Metal. The technique we are using is not available on OS X, so running a cloud plugin on Mac will require the OpenGL driver, not Metal. This isn’t something we can fix with some future bit of cleverness – it’s a limitation of OS X’s APIs. (We would revisit this if Apple introduced a new API but I do not expect this to happen.)

To be clear: on Windows what we are supporting is 3-d OpenGL drawing by plugins inside the Vulkan renderer, not native Vulkan rendering by plugins inside the Vulkan renderer. Native Vulkan rendering by plugins is an incredibly complex SDK problem, and not something we are looking at for 11.50.

2-d Drawing Just Works; 3-d Drawing Requires a New Plugin

For plugins that draw in 2-d we’ve gone for a “just works” level of compatibility; while we have seen some plugins that need to update due to illegal techniques and bugs, our goal is that a well-authored add-on just works even when Vulkan and Metal are in use.

By comparison, OpenGL drawing inside Vulkan is going to require plugin authors to sign up for a new 3-d drawing callback. We’re making this opt-in because, during the beta, we’ve found a lot of add-ons using 3-d drawing callbacks inappropriately, and 3-d drawing callbacks are no longer free. By requiring plugins to opt-in when they _really_ want 3-d drawing in Vulkan, we should get better performance.

The new 3-d drawing callbacks are really only meant for custom drawing like clouds. Other techniques like adding objects to the sim and drawing markings are better handled with other APIs. Our plan is to have detailed guidance on what technique is best for developers by the time we are ready for public beta.

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.

60 comments on “Cloud Add-Ons and Vulkan Episode IV: A New Hope

  1. Awesome update! Thanks Ben. Sounds like good progress is being made and I love it when it results in such positive “side-effects”!

  2. Ben, thanks for the update.

    I’m sad about the implications for metal but maybe you guys can just buy/hire both someday and Sherlock it into X-plane.

    I am super excited. I won’t pester you about the public beta, but just know my heart jumped when I got the notification in my rss reader of a new blog post.

    I hope your CDN bill is all paid up because when you do release, yikes!

  3. So if you don’t use third party vendor such as SkyMaxx and xEnviro for cloud drawing, but utilize native X-Plane, it should “just work” with native Vulkan? And how would Linux meet Vulkan?

    1. Native cloud drawing will just work on Vulkan, Metal, GL, everywhere – that has always been true since day 1. There was never a risk that internal x-plane rendering wouldn’t work because our code runs on the native driver.

      Linux runs Vulkan, so in theory, the bridge will just work. If there are driver bugs specific to Linux then it won’t.

      1. “Soon”

        Anyway, as it happens often, MAC users are left behind due to Apples limitations. When you say Metal needs to use the GL drivers, I am confused. Specifically, will it be possible for Mac users (via some other way) to use this cloud feature too? Or will Sky Max not be usable on Mac ?

        Will there be any other limitations for Mac users? Scenery add on airports or airplanes? While getting better performance is great, it may not be worth it if add ons wont work or take months to be updated

        1. SkyMaxx on Mac will require X-Plane to be using the GL driver, not the Metal driver to run. This is the same as what we expected from the beginning of the Vulkan/Metal private beta.

          The only Mac-specific limitation I can think of is that this new hook for 3-d drawing under a modern driver for cloud add-on plugins will not run on Mac. So it would limit other weather-drawing plugins that are adapted to Vulkan and OpenGL only too.

          1. Hi,
            no expert but Apple has a Metal OpenGL interop sample.. “Mixing Metal and OpenGL Rendering in a View“.. isn’t that all that is needed for supporting OpenGL plugins on Metal?

          2. Just to clarify, we already do have OpenGL and Metal interop through our existing bridge (same as we did before this announcement). This bridge on Metal supports 2D drawing only though, so that includes aircraft panels as well as window/widget drawing. What doesn’t work is the 3D drawing support that Vulkan now has. For that we would need a way to share our depth buffer. Unfortunately the sharing mechanism, IOSurface, has very limited support for what can be shared (it essentially boils down to 2D rectangle textures with a small handful of colour formats, no depth formats). There is a more high level API as well in Core Video, where sharing of data would go through a CVPixelBuffer. Unfortunately that one is just a very slim wrapper over IOSurface and has the same caveats as just using an IOSurface directly, ie no support for sharing a depth buffer.

      2. That last sentence could be read as you do not cover Linux in the private beta. I hope that is not the case!

        My assumption is, whenever I read Windows in your Vulkan posts, I can safely substitute it by Linux.

        1. Linux _is_ in the private beta – the private builds are for three platforms and there are a lot of Linux users. The thing to note is that Linux is a tiny fraction of our overall user base (< 2%) but represents a disproportionately large part of the beta program because a lot of third party devs are using Linux as a dev environment. I'd guess we might be 25% linux inside the private beta, which is devs-only. This surprised us at first - we knew there'd be "extra Linux" but we didn't expect that much. Those devs have definitely caught and reported Linux bugs.The issue with the 3-d drawing callback is that the weather add-on guys we have in our program are Mac/Win (SkyMaxx) and Win-only (xEnviro) so neither of them have tried the bridge on Linux. If anyone out there _is_ writing a Linux weather add-on, they should ping us, but we just don't have the real world test coverage. Given the bugs we've found on Windows with plugin bridging and the OS-specific parts, I have to consider 3-d bridging to be untested compared to the rest of Linux.

  4. Thanks for the update Ben. Great to hear of the collaborations fuelling progress. Looking forward to testing your efforts.

  5. I am really excited that there is a cooperation between Laminar and xEnviro, yes I know that it is a 3d party, but xEnviro is a great product for X-Plane in creating realistic weather, if the two areas can be better refined, then the benefits for both are very high if they are far better intergrated together, and more efficient.

    1. Totally agree with this. Glad it got worked out because there was a bit of concern around that in early rounds. This is indeed wonderful news.

  6. I read an article saying Khronos partnered with Valve, LunarG and the Brenwill Workshop to create an SDK which brings Vulkan to MacOS and iOS. Can this effort be used by Laminar Research or is it not available? Google “Khronos Brings Vulkan to macOS, iOS, After Apple Refuses to”.

    1. MoltenVK, the effort by LunarG, Khronos and Valve to bring Vulkan to macOS is unfortunately not usable by us. It’s not a real Vulkan driver, instead it implements a subset of the Vulkan specification on top of Metal. So it obviously still has all the limitations that Metal had. We already have a renderer backend that supports Metal natively, there would be very little reason to put an intermediate translation layer inbetween us and Metal. On top of that, the Vulkan backend as it stands right now, uses features that Metal/MoltenVK does not support. So adopting MoltenVK would gain us nothing that we don’t have, but we’d lose a bit of performance overhead.

      1. I am so happy about the close and transparant contact between developer and customer! Very great, thanks for all your effort! Learning about the features of Xplane every day, as practising for my current license when the weather outside is mehhhhh. Thank you!

        Happy LAPL TMG pilot

  7. Great to hear things are moving forwards again and as you know we’re all anticipating the Vulkan release. You mentioned that both Skymaxx and XEnviro have been part of the private testing program, which are both great products although somewhat resource intensive. Are you able to disclose any indicative performance gains with regards to those products and the transition to XPlane with Vulkan, compared to Xplane pre Vulkan.

    1. I am not, but I can say that I _expect_ them to have _no_ performance gains – cloud add-ons tend to be GPU bound and they’re running in OpenGL, so nothing here would make them faster.

      The net win to the user is that their users may be able to run a Vulkan X-Plane with them, so the users can get the X-Plane CPU-side gains while running the add-ons.

  8. Thank you for the update. I’d not so secretly hopes this might be the case.

    Any chance this means xenviro/skymaxx can finally get linux support?

    1. I don’t think so. If they don’t support Linux already in 11.41 (where there is _no_ difference in platforms) this implies they are not on Linux because it doesn’t make sense to do a port of their tech for an extremely small percentage of our user base. (We have never seen Linux adoption break 2%. Ever.) . If anything, the Vulkan situation makes this harder – all of the existing difficulty of porting for Linux remains, plus there is a risk that the GL->Vulkan bridge could be buggy in ways unqiue to Linux (since it depends on some OS-specific stuff to share textures).

      Our experience has been that the GL-Vulkan interop is buggier than the rest of the Vulkan driver – it’s sort of the only area where we’ve had to report things.

      1. Thanks, on first reading it sounded like cross platform sdk things that didn’t exist before had been created, making it easier for them to support. Will you still be working on the lighting and weather anyway – or was this that?

          1. I have low expectations for any weather improvements based on virtually unanimous end user requesting over the past decade plus. I sincerely hope you make some real headway in this area.

            The lighting though, hopefully will be a quick and easy fix. The current dingy post nuclear war world of X-Plane has single handedly created a shader cottage industry, that gives people the lighting effects they desire.

  9. What’s to prevent this becoming a crutch rather than a bridge? Is there an incentive for 3rd parties to put in the work to change to Vulkan if their existing openGL code is going to still work. What’s the performance cost to the end user of 3rd parties retaining the old slower api and not investing the time to update?

    Im afraid this short term win could be a long term loss.

    1. Two things:
      1. The bridge is only for actual native drawing. So _all_ other use cases have better alternatives and need to be ported. That’s not changing. So for example, if you use XPLMDrawObject, you have to move to XPMInstance (which is now at least available for two years). There’s a carrot and stick for that. The carrot is that XPLMInstance works with particles, and the stick is it doesn’t work in Vulkan.

      2. The second thing to note is that there _is no_ native Vulkan path for plugins, therefore this isn’t a crutch stopping people from writing native Vulkan code.

      WE are stopping people from writing native Vulkan code – a path for the weather plugins we considered but decided against. Here’s the fundamental problem: Vulkan leaves a lot of graphics tasks that OpenGL used to do for us — managing memory is the big one but there are others. So to make an SDK for plugins to draw in Vulkan we’d have to have a stable memory management API on top of Vulkan that’s plugin ready that _is not going to change_ so that they can use it to interact safely with X-plane and not have their add-ons broken.

      That’s tech we just don’t have – our memory management is still under development and we’re going to learn things in the beta that require changes. So we’re using GL for the cloud add-ons right now because a big chunk of the driver stack is effectively standardized inside OpenGL.

      The other thing to note is: I don’t think Vulkan is necessarily a really good way for plugins to draw. Have you ever seen Vulkan’s “hello triangle”? It’s 1300 lines of code to draw one triangle. Without textures! The cloud add-ons tend to be bottlenecked on _GPU_ power and can keep the CPU side costs low relatively easily – that’s the case with our clouds too. And most GL drawing in X-Plane is 2d glass cockpits and UI. Vulkan is a very big, low level, dangerous hammer for this kind of dev. If anything, most plugin authors could use a _higher level_ graphics API, e.g. one that anti-aliases lines automatically, not a lower level one.

      (Finally it’s worth noting that while we’ve had people offer to port to Vulkan, _no one_ has offered to port to Metal. The Mac is in a weird place – with somewhere between 25 and 30% of the user base, it’s big enough that a notable chunk of users care if it’s missing, yet it’s a real dev cost to port to it, since Vulkan and Metal are so different. So a cross-platform API like GL is a win…if you’re making a glass cockpit you can get another 30-50% growth in the accessible users by not using Vulkan.)

      Vulkan is a win for us because we’re drawing the whole world and that process is often CPU bound and needs to be multi-core.

  10. Are you going to fix the contrail in version 11.50? Four lines of code in the shader make its color normal, white. Or do you have an agreement with the developer of xVision utility? “We will not fix the trail, and you can earn more money.” It was a joke.

  11. Hello Ben, are Mac users going to see any improvement in performance with Metal. As stated earlier we do seem to be the poor relations in many things XP. I would be more than happy with things running a bit smoother

    1. Yes – CPU costs are improved a lot with Metal – if you’re CPU bound you’ll get more autogen or you can turn on scenery shadows.

      But beware – if you’re running at a huge resolution there’s a risk you overpowered you Mac’s GPU. In this case, Vulkan won’t help.

    1. I don’t know – it depends on what they do. Reading back the frame-buffer and re-drawing it _does_ work (if done carefully) but modifying shaders or state in an unsupported way does not.

  12. look carefully that you do not make a complete revolution of a good sky of a good sea and with clouds worthy of being called such (and not simple images) ms2020 will overwhelm you … do your calculations well! you are still with the clouds of 5 years ago maybe! give this simulator a twist!

  13. Do you guys have or know of a good infographic that shows the relationship of Vulkan, Metal, OGL, and how you are stacking/abusing them? It would be interesting to see and might help some of us devs. Thanks.

  14. Looks nice, are you guys planing to add more commercial airplanes like Airbus A320 , Boeing 777 and etc. cuz some third party addons doesnt work for me

  15. When 11.5 is released will it still be advisable to stay on MacOS Mojave or update to Catalina? Is there any advantage with MetaL on Catalina?

  16. If I understood this correct…
    Aircrafts with 2D-panels will work as before even after the implementation of Vulcan and 3D-panels will, in some cases, work with issiues. Correct ??
    Question then..
    If I have an aircraft with a 3D-panel but also hardwarepanels with switches, knobs and encoders (that is I don´t manouver switches and knobs on the screen with the mouse coursor or some 3D-gloves plugin but through actual switches and knobs on my hardware panels), will that also work as before after updating to ver. 11.50 (with Vulcan-support) or will there be issiues as well?

  17. To Summarize, i could deduce to saying that the road-map to x-plane 12.0 is to finalize a *Stable Memory Management API* in order to pave-way for full stack Vulkan Support covering (Core + Plugins).

    This further goes that OpenGL support for Cloud-Addons might or might not be needed for Xplane 12. This really depends on the strategic decision of Laminar as they lead the design and set standards for the next-gen platform.

    1. We are not promising a Vulkan API in the future. We don’t know if we’ll do one. Stable Vulkan internals are _necessary_ for such an API, but not sufficient. We’ll re-examine when it’s not impossible. But as I’ve said in other comments, I’m not sold on Vulkan as a graphics API for add-ons.

      The GL 3-d drawing callback that makes clouds work with Vulkan in 11.50 may not work in future major releases – we can’t guarantee the rendering pipeline won’t have changed a ton.

  18. Great news!! What about VRSS, FFR and DFR for VR? It would improve fps quite a lot. Any news about that in vulkan xplane? Thanks

  19. I understand the need to be able to handle existing plugins, so plugin compatibility code implemented is a need… but do you also provide Vulkan API’s? Third Party plugins will eventually need to be moved from OpenGL to Vulkan.. This will also benefit any x-plane 12 development because you may choose to remove the OpenGL compatibilty code and that will speed up x-plane further..

    1. We do not provide Vulkan APIs at this time, and I do not expect to remove OpenGL plugin rendering for 2-d rendering callbacks in the forseeable future. It would be useful for X-Plane to drop OpenGL because Metal and Vulkan provide similar modern threading guarantees that are quite different from OpenGL, but we could run plugins via the bridge indefinitely. There’s no clock for people to rewrite their panels.

Leave a Reply

Your email address will not be published. Required fields are marked *

Please do not report bugs in the blog comments.
Only bugs reported via the X-Plane Bug Reporter are tracked.