Thank you for your advice…got G.Skill Trident Z Neo…latencies nice and low with CAS @16. Hope it works with my rig.

MY GOD YES going 32GB of ram is worth it more so if your running orthos

and not just XP11 DCS and even on the desktop >16GB fixes everything

Thanks Ben,

This explanation is vivid enough – that even non-developers grasp by now a
very deep insight beyond a hypothetical generic developer.
I enjoy much this type of elaboration. As 20 years ago, I was much fond of OpenGL on SGI, and had some wild hobby to master coding that API as being perceived the future of 3D graphics.
Its amazing how far things has developed.

Based on the recent progressions; is there any emerging estimation today about release date for xp 11.50 ?

First, to be clear, the presence of other apps rendering on Metal and Vulkan doesn’t have any implication on whether _plugins_ should render directly in Metal and Vulkan to X-Plane’s windows. It may imply that it’s not crazy to have the sim itself render in Metal and Vulkan, but that’s not surprising – the whole point of 11.50 is that X-Plane uses these modern APIs and we’ve been saying they’re a great fit for a simulator for years now.

The question at hand is whether an add-on running as a guest inside X-Plane’s process can use these APIs to render to X-Plane’s windows, effectively sharing the Vulkan and Metal resources.

The answer is: it is not (yet) supported because we need to solve every problem of resource sharing and coordination for every shared resource to make this work, and we haven’t done that yet.

With OpenGL, most of the resources for rendering are hidden inside the GL driver, so if I give you a function call and our GL context is bound, you can just go glBegin() and boom – you’re rendering. Behind this seemingly simple mechanism is a huge amount of complexity inside the driver.

With Metal and Vulkan, most resource management is up to the app.

So there is nothing stopping a plugin from starting its own Vulkan or Metal instance, rendering to a texture, reading that texture back, and then using those bits. That can be done now. It’s not useful (because it would be very slow) but it’s possible.

But to render to our window you have to share our allocator, our render pass, our command buffer, your pipelines have to be render-pass compatible, we have to have scheduling rules for command buffers, any texture you want to use hast o be spec’d, etc. In other words, there’s a ton of internals that would need to be specified into a very complex XPLM API.

At that point if we change ANY internals, that API becomes completely broken. So at a minimum, we’re going to wait until we damn sure like our Vulkan/Metal back-ends before even thinking about how to build an API on top of them. Doing so now would be like building a house while the foundation cement hasn’t cured.

Finally, as I’ve said before, I don’t believe that Vulkan and Metal are particularly good APIs for what plugins want to do. If you have a use case where you truly believe you’re being held back by using GL and not Vulkan, ping me, and we’ll talk. But it’s worth noting that the requirements to write high performance OpenGL code (which most add-ons _do not do_) are a subset of the requirements to write _any_ Vulkan and Metal code. So a true perf problem would be one where, even after writing the high perf OpenGL, the code still isn’t fast enough.

Ben…many thanks for your reply, fingers crossed. I am thinking but holding back for some add-ons atm as I need the frames for VR. Can I trouble you with one more question please ? Will it be beneficial under Vulkan to go from 16GB ram to 32 ? I am not on budget but like most of us don’t like wasting money on hardware I do not need. My spec is I7700 oc @ 5 GHz, 2080Ti. XP is on a M.2 EVO drive. I hope you can celebrate with a drink your success next week ! 🙂 Cheers, Michael

The intent here is: if you need to draw na object, use XPLMInstance. If you need to do something non-drawing, use another dataref. Etc. In other words, don’t use 3-d drawing CBs in the SDK unless you have your own proprietary 3-d drawing code.

I wonder what does it mean: “other APIs”, the only 3D drawing APis/Framework I’m aware of are: OpenGL, Direct-X, Vulkan and Metal.
In some cases I use the XPSDK instancing, but now it won’t be supported by Vulkan (I wonder why if the OpenGL bridge looks promising ?)

Could someone in Laminar elaborate on the “other APIs” ?

Thanks
Thanks