Skip to content

Conversation

garyo
Copy link
Contributor

@garyo garyo commented May 6, 2025

Fixes #160, which see.

@garyo garyo requested review from john-paulsmith and revisionfx May 6, 2025 20:31
@john-paulsmith
Copy link
Contributor

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.

@garyo
Copy link
Contributor Author

garyo commented May 8, 2025

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.

@garyo
Copy link
Contributor Author

garyo commented May 9, 2025

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.

@garyo garyo force-pushed the add-windows-install-locs branch from 902260c to fc02647 Compare October 13, 2025 17:36
@garyo
Copy link
Contributor Author

garyo commented Oct 13, 2025

@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.

@revisionfx
Copy link
Contributor

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).

@garyo
Copy link
Contributor Author

garyo commented Oct 13, 2025

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?

@revisionfx
Copy link
Contributor

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?

@garyo
Copy link
Contributor Author

garyo commented Oct 13, 2025

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.

@revisionfx
Copy link
Contributor

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.

@revisionfx
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Windows ARM64 and ARM64EC support

3 participants