Add support for Windows ARM64

[anthony-linaro]

This adds proper support for building for Windows ARM64 devices. using MSVC.

It does actually work right now, but only by complete accident, and with no SIMD enabled - this enables everything properly.

As part of this, I updated the version of sse2neon used to one compatible with MSVC - the particular hash I used is the exact one that Blender uses, which is known working (there were some issues with the base 1.7.0 release).

Commands used:

mkdir build
cd build
cmake -G"Ninja" ..
cmake --build .
ctest

All tests pass. This is using VS2022, I wouldn't really use VS2019 for ARM64 platforms if I'm honest.

I didn't test any of the GPU things, although GLUT may work, as I added ARM64 support to FreeGLUT a few years ago.

Addresses #1859 (so probably of interest to @num3ric also)

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: anthony-linaro / name: Anthony Roberts (9977dea, 04a723a, 79c0fc8, 53fb3d3)

[num3ric]

Love it, thanks for the work! Hopefully the CLA & failing tests can be resolved.

[num3ric]

Any reason you couldn't pick an official version number here?

[anthony-linaro]

Long story short, we uncovered some issues with 1.7.0 in Blender on various platforms, and needed to update to a non-versioned commit, as they only version sse2neon once a year - the issues may or may not affect OCIO, but this is at least a known working and tested version that Blender uses.

[anthony-linaro]

I'll have a dig into those tests and try and figure it out - I don't have those platforms to hand, so will be some guesswork involved.

For the CLA, I'm trying to find out who our internal person is that is responsible for EasyCLA so thay can approve it under our corporate account - I'll find out at some point soon I'm sure

[anthony-linaro]

Have fixed a small buildfile issue - I am hoping this may resolve the mac issues (sse2neon accidentally got disabled in some configurations).

I have also fixed some additional issues I encountered while debugging (namely it wasn't actually using sse2neon properly outside of the cmake test, oops).

I have been building with python off, there seems to be some sort of Access Violation Exception, but I'm not sure what it is caused by - for now, the rest of the test suite passes so it should be fine.

[anthony-linaro]

CLA now done!

[num3ric]

Have you tried (cross-)compiling -A ARM64 from an x64-based PC? Unfortunately #1859 isn't fully addressed here, since compiling this PR still fails for me unless I add:

    if(MSVC)
        set(CMAKE_SYSTEM_PROCESSOR ${MSVC_CXX_ARCHITECTURE_ID})
    endif()

If not, I get OCIO_ARCH_X86 1 and CpuInfo.cpp fails per issue.

PR looks good otherwise though!

[anthony-linaro]

I had not, mainly on the account of me not having a suitable x64 machine to hand 😄

I'll get one set up for development and give it a go

[anthony-linaro]

Commit pushed, should allow cross-compilation. Tested with the command line:

cmake -A arm64 .. -DOCIO_BUILD_PYTHON=OFF

On a Windows x64 machine - the binaries produced appear to run correctly on my ARM64 machine

[anthony-linaro]

Thanks for the approval, @num3ric - is there someone else who needs to review this for it to go in?

[doug-walker]

@anthony-linaro , thanks for the contribution. Regarding reviews, the project requires a minimum of two reviewers.

This PR makes significant changes to the build system which are not fully tested by our CI, so we definitely need more people to test. This includes validating that the various Mac builds were not affected.

Are you looking for this to go in OCIO 2.4.x or could it wait until 2.5 next fall?

[anthony-linaro]

Thanks for the reply @doug-walker - ideally sooner rather than later, so 2.4.x - this would mean Windows ARM64 would be properly compatible with the VFX Reference Platform 2025, rather than having to wait another year (well, once my USD PR is merged, too).

VFX reference platform compatibility is something that has been requested by a few external partners, and it would probably be a disappointing answer for me to give them, if I told them they need to wait another year, or maintain an out-of-tree patch

[num3ric]

+1 on prioritization, to get rid of patches on our next engine release.

Also confirming on my end that this PR successfully resolves #1859.