AcademySoftwareFoundation
Add Windows ARM64 plugin install locations with rationale
On reflection, I think the search logic should be reversed. We don't yet know if developers will find limitations or performance degradation using the Arm64X wrapper, so it makes sense to search the native location first.
On reflection, I think the search logic should be reversed. We don't yet know if developers will find limitations or performance degradation using the Arm64X wrapper, so it makes sense to search the native location first.
Good point. It does make sense to look in the "most native" folder first. I'll make that update.
On reflection, I think the search logic should be reversed. We don't yet know if developers will find limitations or performance degradation using the Arm64X wrapper, so it makes sense to search the native location first.
Done.
@john-paulsmith @revisionfx Is this all set to go now? I know it doesn't have cross-built examples/libs yet, that would be a separate PR.
ArmX64 is just a bundle of x64 and arm64 - it should not affect performance. However for some reason MS did not do like Apple and have a bundle that works also on x64. ArmEC like BMD does (running x64 binaries within ARm64 app is what can cause performance hit, primarly for stuff using AVX512 as neon intrinsics are only 128).
ArmX64 is just a bundle of x64 and arm64 - [...] ArmEC like BMD does (running x64 binaries within ARm64 app is what can cause performance hit. [...]
Yes, but the question at hand is: is the spec change in this PR correct and complete and ready to merge, or does it need to be tweaked?
I dunno because on Windows Mixing Arm64 and Arm64EC binaries in the same process is not supported - is Resolve Arm64EC? If so would mean we would need 2 ARM compile?
What would you like me to change, if anything?
-
Win32- for Microsoft Windows (Intel x86, 32 bit) -
Win64- for Microsoft Windows (Intel x64, 64 bit) -
Win-arm64ec- for Microsoft Windows (ARM64EC) -
Win-arm64- for Microsoft Windows (ARM64) -
Win-arm64x- for Microsoft Windows (ARM64X)
Windows Architectures ^^^^^^^^^^^^^^^^^^^^^
As of 2024, Windows supports Arm64 CPUs. It uses two distinct ABIs, Arm64 for native code, and Arm64EC for x64/Arm64 compatibility, in which x64 apps running in emulation on Arm64 hardware can interoperate with x64 DLLs (also in emulation) or Arm64EC DLLs (which are native Arm64 code with x64-compatible calling conventions). Arm64EC apps cannot load native Arm64 DLLs, only Intel or Arm64EC.
Windows also supports an Arm64X "fat" binary PE format which contains both Intel/Arm64EC and Arm64 binaries.
Search Order: Since apps built natively for Arm64 ("Arm64" abi) can only load Arm64 DLLs, those apps should attempt to load plugins from the "Win-arm64" folder first, then "Win-arm64x". Arm64EC hosts (running on an Arm64 system) should try the "Win-arm64ec" folder first, then "Win-arm64x". Arm64EC hosts can also use x64 DLLs, so they may try "Win64" as well, but should prefer the other folders to avoid running the plugin in emulation. An Arm64X host will be running either its Arm64EC branch or its Arm64 branch depending on how it's launched, so it should load plugins according to the above depending on the current mode.
Note that there is no "fat binary" format on Windows that contains Intel x64 and arm64 code.
I can confirm that Resolve WIndows Arm is EC (just downloaded). WIll try this week what happens if we download our AMD64 plugins on that machine :)
Meaning we will likely at some point need to have two distinct builds anyway on Windows Arm. Arggh! Then seems it would be more practical to just have ARM64X folder which supports all - it's just a bundle - a one time thing for app to choose the right dll to load in a single folder. I say that before I see what happens to GPU support in different modes... We also need ARM64 for linux.
I just checked for fun, our AMD64 plugins already load fine on Resolve ARM built, except for GPU mode. That I need to check as it's a yet unknow GPU string likely. Resolve runs on OpenCL.