You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
On Windows with arm64, Win-arm64 should be used (vs. current Win32 and Win64 which are Intel-specific)
Windows 11 will soon be supporting two new architectures, arm64 and arm64ec. No machines currently support this, but such machines are expected in summer of 2024. According to Microsoft, arm64ec supports running Intel code in emulation, within an arm64 application on an arm64 CPU. This should allow Intel-based plugins to run in an arm64ec host. Native arm64 applications will presumably fail to load an Intel dll, so the spec should be specific about where plugins for each architecture are installed.
The doc above says:
Arm64EC apps can load Intel DLLs and Arm64EC DLLs, but not Arm64 DLLs.
Arm64 apps can only load Arm64 DLLs.
Intel apps cannot load Arm64 nor Arm64EC, naturally.
There is also an Arm64X "fat" binary PE format which contains both Intel/Arm64EC and Arm64 binaries. See Microsoft doc.
We will need to confirm once machines and host apps are available, but I believe this will work:
An Arm64EC host should attempt to load plugins from Win-arm64x, then Win-arm64ec, and then from Win64.
An Arm64 native host should load plugins from Win-arm64x, then Win-arm64.
An Arm64X host will be running either its Intel/Arm64EC branch, or its Arm64 branch, so should load plugins according to the above depending on the current mode.
Requested change:
Add Win-arm64ec, Win-arm64, and Win-arm64x install folders to the spec along with the notes above.
Impact
This will impact all hosts and plugins which want to support Arm64 on Windows.
Documentation Impact
The only change to the doc (the spec) is to update the install dirs list, and add rationale as per the discussion in this issue.
The text was updated successfully, but these errors were encountered:
Open Effects Proposal for Standard Change
Please read the contribution guidelines first.
Standard Change Workflow
standard change
tagfeature/PROPOSAL-NAME
branch)maintainer merges PR to master which closes PR and issue
Requirements for accepting a standard change:
Summary
OpenFX plugins are installed in standard locations, based on the ABI architecture. See https://openfx.readthedocs.io/en/main/Reference/ofxPackaging.html#installation-directory-hierarchy for the current list.
On Windows, the spec currently says:
Windows 11 will soon be supporting two new architectures,
arm64
andarm64ec
. No machines currently support this, but such machines are expected in summer of 2024. According to Microsoft,arm64ec
supports running Intel code in emulation, within an arm64 application on an arm64 CPU. This should allow Intel-based plugins to run in an arm64ec host. Nativearm64
applications will presumably fail to load an Intel dll, so the spec should be specific about where plugins for each architecture are installed.The doc above says:
We will need to confirm once machines and host apps are available, but I believe this will work:
Win-arm64x
, thenWin-arm64ec
, and then fromWin64
.Win-arm64x
, thenWin-arm64
.Requested change:
Win-arm64ec
,Win-arm64
, andWin-arm64x
install folders to the spec along with the notes above.Impact
This will impact all hosts and plugins which want to support Arm64 on Windows.
Documentation Impact
The only change to the doc (the spec) is to update the install dirs list, and add rationale as per the discussion in this issue.
The text was updated successfully, but these errors were encountered: