Jump to content

Sign in to follow this  
GSalden

Update from PMDG

Recommended Posts

9 minutes ago, eaim said:

So are there any limitations in using webassembly, I seem to remember some devs claiming that it's limits usage to a single core?

According to the latest SDK ( 0.8.0 ), WASM modules have the following limitations:

- The Windows API is not supported

- C++ Exceptions are not supported

- C++ Threads are not supported

- GDI+ Wrapper is incomplete

About multi-core usage, lacking of support of C++ threads means a single WASM module cannot create new threads on its own, so it will run on a single thread. However, when I inquired with Asobo about this, several months ago, they replied they were already looking into parallelizing WASM modules so, at least, each one would run in its separate thread, which would help if there are many of them installed. I don't know this is already in the current version of the sim, the docs are not clear about it. Also, I believe Asobo had plans to allow multi-threading even inside a single module, but in this case the docs specifically say it's not there yet.

From a "port existing C++ code", the lack of C++ Exceptions might be more serious, but of course it depends if the original code used them in the first place and, if you use 3rd party libraries that comes as C++ source code, they might use them a lot, and might be difficult to modify code that is not yours.

Same as the lack of support for Window API, it might be a big problem or no problem at all, depending what the original code did.

And same for the incomplete GDI+ wrapper, it might be a big problem or no problem at all, depending which GDI+ functions were used in the original code.

  • Like 1

Share this post


Link to post
Share on other sites
6 hours ago, eaim said:

So are there any limitations in using webassembly, I seem to remember some devs claiming that it's limits usage to a single core?

Sorry if it's stupid question as programming wise I'm a bit out of date, I done my A level computer science 35+ years ago.

inNative has thread support: innative-sdk/innative#57innative-sdk/spec documents the current WebAssembly standard implemented by inNative, including any proposals like threading. As for compiling modules utilizing the threading proposal's instructions, I'm not sure, but you should be able to ask the MSFS devs (or, worst case, the inNative devs in their Discord) about how to compile with threading from at least Clang. https://rustwasm.github.io/2018/10/24/multithreading-rust-and-wasm.html is an older blog post discussing compiling Rust to WASM with threads support.

This is a non-obvious feature, so thanks for your question!

  • Upvote 1

Share this post


Link to post
Share on other sites
On 11/30/2020 at 4:14 AM, bb010g said:

Hi, programming nerd here to set the record straight on some MSFS 2020 things.

Flight Sim 2020 uses inNative (source code) to compile WebAssembly (WASM) into native machine code via LLVM. (Check the credits and you'll see inNative listed.) Restated for programmers, inNative is a WASM LLVM frontend, compiling WASM into LLVM IR and then letting LLVM do its normal thing. LLVM is the same backend that Clang, one of the major C++ compilers (alongside GCC & MSVC), uses. WebAssembly code can be compiled to native code completely before execution, and, depending on how you invoke inNative, any native API can be used from WASM modules. With the right configuration, you can compile arbitrary normal Windows C++ programs to WebAssembly and then to native code via inNative and have them execute virtually identically (modulo optimizations). (MSFS 2020 does not allow for this usage, by design.)

Microsoft Flight Simulator 2020 is not interpreting WebAssembly like your browser would, but instead utilizing it as a portable, well-designed, low-level, sandboxed language. Instead, WASM modules can provide native performance to the same code on essentially any platform MSFS wants to run on, without extra development work.

WebAssembly by itself offers no platform-specific APIs (they're considered unnecessary bloat), but it does offer the ability to import functions from the "host". inNative allows arbitrary C ABI (application binary interface) functions to be exposed to WebAssembly modules, which may import them if they please, like how a linker traditionally functions, linking libraries (like SOs or DLLs) together.

MSFS is not constrained in what it exposes by its use of WebAssembly, and as such any missing SimConnect functionality is most likely due to normal difficulties of implemention & integration with the sim.

File system APIs have also been brought up a decent amount here in what I've read, and exposing those is also in MSFS's court. I believe MSFS implements or is implementing WASI, the WebAssembly System Interface, a standard for file-system APIs in WASM? Note that whatever is chosen, it will basically perform as fast as C++ code compiled directly from source to LLVM IR & then native through Clang, given the same interface. The choices of file-system interfaces exposed may effect performance, but this is something you can reasonably bring up to Asobo as an extension to their existing host function set that would really improve your add-on. Any function added there would be accessible with full native performance from your WASM modules.

inNative not only can perform AoT (ahead-of-time) compilation, but also JIT (just-in-time) compilation via LLVM's JIT API. For the JIT, a WASM module is compiled to LLVM IR by inNative and then to native code by LLVM that can then be executed right on the spot, instead of the native code being output to a file or other longer-living storage. This isn't used much AFAIK, and I don't think may be used on the Xbox at all(?), but it can help make development smoother (less time waiting between testing iterations). (The fact that inNative is an AoT compiler is a large part of why it was chosen, AFAIK. Official add-ons can use the same SDK as community add-ons and be compiled before deployment for the Xbox, so that no code has to be compiled (security hazard) or interpreted (performance hazard) on the Xbox.)

Also, on the topic of WebAssembly & graphics APIs (e.g. DirectX), they're really separate issues. WebAssembly doesn't target shader or GPU compute programming in the same way C++ doesn't normally target those. You'll instead have APIs for talking to the operating system & graphics drivers (which can be exposed to WASM no problem & without damaging performance), and then separate languages like HLSL (OpenGL, DirectX) or SPIR-V (Vulkan) that some of those APIs deal with for encoding high-performance GPU programs. MSFS is free to choose graphics backends independent of WebAssembly, and whatever they decide to expose via WASM host functions will cost no performance (compared to the same functions in directly native code).

Yeah, well, that's just, like, your opinion man.

  • Like 2

Share this post


Link to post
Share on other sites
18 minutes ago, Scottoest said:

Yeah, well, that's just, like, your opinion man.

Haha made me laugh this, well played 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

  • Tom Allensworth,
    Founder of AVSIM Online


  • Flight Simulation's Premier Resource!

    AVSIM is a free service to the flight simulation community. AVSIM is staffed completely by volunteers and all funds donated to AVSIM go directly back to supporting the community. Your donation here helps to pay our bandwidth costs, emergency funding, and other general costs that crop up from time to time. Thank you for your support!

    Click here for more information and to see all donations year to date.
  • Donation Goals

    AVSIM's 2020 Fundraising Goal

    Donate to our annual general fundraising goal. This donation keeps our doors open and providing you service 24 x 7 x 365. Your donation here helps to pay our bandwidth costs, emergency funding, and other general costs that crop up from time to time. We reset this goal every new year for the following year's goal.


    39%
    $9,930.00 of $25,000.00 Donate Now
×
×
  • Create New...