Arm64 workflow enablement

[alinpahontu2912]

Added workflow for arm64 build of torchvision

[pytorch-bot[bot]]

:link: Helpful Links

:test_tube: See artifacts and rendered test results at hud.pytorch.org/pr/pytorch/vision/8947

• :page_facing_up: Preview Python docs built from this PR

Note: Links to docs will display an error until the docs builds have been completed.

:x: 2 New Failures, 2 Pending

As of commit f842b49506cec687642326f7592089430c92827b with merge base 0721867e42841171254c7acaa45fbaf8ee16d3d7 ():

NEW FAILURES - The following jobs have failed:

• Build M1 Wheels / pytorch/vision / build-wheel-py3_9-cpu (gh) Process completed with exit code 1.
• Build M1 Wheels / pytorch/vision / upload / upload-wheel-py3_9-cpu (gh) Unable to download artifact(s): Artifact not found for name: pytorch_vision__3.9_cpu_

This comment was automatically generated by Dr. CI and updates every 15 minutes.

[NicolasHug]

Hi @alinpahontu2912, I see this is related to https://github.com/pytorch/vision/pull/9080 which I'm also a bit confused about.

Can you please share some context about this? As far as I know pytorch currently doesn't support Arm64 Windows. @seemethere @malfet , are we actively trying to support arm64 + Windows? What would be the support model for this platform?

[iremyux]

Hey @NicolasHug , Pytorch supports Windows Arm64. Nightly & 2.7.0 wheels are available, only not on PyPi yet. @alinpahontu2912 is currently working on Windows Arm64 support for torchvision and torchaudio. This PR, https://github.com/pytorch/vision/pull/9080 and https://github.com/pytorch/test-infra/pull/6352 are all a part of this enablement.

[alinpahontu2912]

Hey @seemethere @malfet can you also take a look at these changes?

[NicolasHug]

@alinpahontu2912 @iremyux @aalina23 Thank you for the PR.

Would it be possible to handle these build jobs in a separate repository that you would own, instead of within the torchvision repo?

This would help us manage the fixed maintenance cost associated with new CI jobs. Even if we aren't directly maintaining these jobs, we still have to merge your maintenance PRs and deal with potential failures, which can add noise to our CI. By using a separate repo, you could work more swiftly without being held up by our reviews, and we could avoid the fixed mainenance cost on our side.

Maybe @seemethere can advise on the technical feasibility of this idea?

[alinpahontu2912]

Hey @NicolasHug with the recent test-infra PR that was merged, a build of the arm64 Windows package is already triggered by the new test workflow whenever relevant files are changed. Given this, I think splitting the build logic into a separate repo wouldn’t reduce CI activity and would instead introduce unnecessary complexity and split ownership. We think keeping everything within the current setup is more aligned with how the CI is already structured. Happy to discuss this further, though

[github-actions[bot]]

Hey @malfet!

You merged this PR, but no labels were added. The list of valid labels is available at https://github.com/pytorch/vision/blob/main/.github/process_commit.py