Fix Linux arm64 Debug build_test_pipeline cpuinfo cache miss

[prathikr]

Description

Restores the pytorch/cpuinfo dependency pin in cmake/deps.txt and cmake/vcpkg-ports/cpuinfo/portfile.cmake to the previously cached revision used by CI.

This keeps the local Snapdragon/Oryon MIDR decoding changes intact while removing the dependency update that caused the Linux arm64 Debug build_test_pipeline job to fail during vcpkg setup.

Motivation and Context

The failing job was blocked before the ONNX Runtime build started because vcpkg tried to fetch a newer cpuinfo archive that was not available in the Microsoft internal asset cache. The workflow uses --use_vcpkg_ms_internal_asset_cache with origin downloads blocked, so the missing cache entry caused the job to fail.

Restoring the known-good cached cpuinfo revision is the smallest fix that unblocks the failing GitHub Actions job without changing the intended Snapdragon CPU detection behavior added in the PR.

[yuslepukhin]

The issue reports two warnings:

"Error in cpuinfo: Unknown chip model name 'Snapdragon(R) X Elite...'" — from the pytorch/cpuinfo library (upstream), not ORT's code
"Unknown CPU vendor. cpuinfo_vendor value: 0" — from ORT's VendorInfoInit() in cpuid_info_vendor.cc:244
Warning #2 occurs because cpuinfo_get_processor(0)->core->vendor returns cpuinfo_vendor_unknown (0) — this happens when the upstream cpuinfo library (the vcpkg dependency) doesn't recognize the chip. ORT's own decodeMIDR is only used in the ArmWindowsInit() path to populate core_uarchs_, not to set the vendor.

So this PR fixes the uarch detection (ORT will know cores are Oryon) but may not fix the vendor warning unless the vcpkg cpuinfo package is also updated to a version that recognizes Snapdragon X Elite. The vcpkg cpuinfo at commit 403d652 already has Oryon support (confirmed above), so if ORT is building against that version, both issues should be resolved. But the PR description doesn't address this dependency.

[yuslepukhin]

What I'd Do Differently

Add the #if CPUINFO_ARCH_ARM64 guard explicitly instead of leaving it as a comment. The upstream cpuinfo guards case 0x001 with this ifdef because Samsung Exynos also uses part 0x001 but matches via the combined variant+part mask in a different implementer branch. While there's no actual collision here (they're in separate implementer switches), making the guard explicit mirrors upstream and documents intent:

#if defined(_M_ARM64) || defined(__aarch64__)
    case 0x001: /* Qualcomm Oryon (Snapdragon X Elite / X Plus) */
      *uarch = cpuinfo_uarch_oryon;
      break;
    case 0xC00:
      *uarch = cpuinfo_uarch_falkor;
      break;
    case 0xC01:
      *uarch = cpuinfo_uarch_saphira;
      break;
#endif

Verify/document the cpuinfo vcpkg version — confirm that ORT's deps.txt or vcpkg baseline already pulls a cpuinfo version with Oryon support (commit 403d652 or later). If not, the vendor warning persists.

Add a unit test — ORT's AGENTS.md states all changes need tests. A simple test calling decodeMIDR with the Oryon MIDR value (implementer='Q'=0x51, part=0x001 → MIDR like 0x51xxxxxx with part bits set to 0x001) and asserting cpuinfo_uarch_oryon would be appropriate. Other parts have no tests either, so this is a pre-existing gap, but worth adding for a new entry.

Consider also handling Oryon in the narrow-load check comment — The existing logic after decodeMIDR only checks for A53/A55 as narrow-load cores. Oryon is a wide core so the current behavior is correct by falling into else { is_armv8_narrow_ld_.push_back(false); }. No code change needed, but a comment noting Oryon is explicitly wide could aid future maintainers.

[github-actions]

You can commit the suggested changes from lintrunner.

[yuslepukhin]

Need to make sure that we are pulling the right cpuinfo dep.

[yuslepukhin]

The PR title says "fixes Snapdragon X Elite CPU not recognized" but the fix only addresses ORT's internal decodeMIDR path (Windows ARM64 MIDR registry reading). The other reported warning ("Error in cpuinfo: Unknown chip model name...") comes from the upstream pytorch/cpuinfo library's Windows ARM SoC chip name parser (arm/windows/init.c).

No test for unknown Qualcomm part number (e.g., MakeMIDR('Q', 0xFFF)) — would test the commented-out default: branch. Minor gap.

[qti-vaiskv]

cpuinfo has added support for Oryon v3 chipset as well: pytorch/cpuinfo@002c213

We should be pulling these changes from cpuinfo to detect different oryon cpu generations and also update the ORT's internal decodeMIDR to handle cpuinfo_uarch_oryon_v3

[Copilot]

Pull request overview

This PR updates ONNX Runtime’s ARM MIDR (Main ID Register) decoding and associated cpuinfo integration so Qualcomm Oryon (Snapdragon X Elite/X Plus) and related cores map to known microarchitectures instead of “unknown”, reducing downstream mis-detection and confusing warnings on Windows on Arm.

Changes:

• Add Qualcomm Oryon / Oryon V3 uarch IDs and decodeMIDR mappings; recognize Cortex-A78C as Cortex-A78.
• Add a new gtest unit file validating MIDR-to-uarch decoding.
• Patch the vcpkg cpuinfo port to include Oryon V3 and Cortex-A78C decoding.

Reviewed changes

Copilot reviewed 6 out of 6 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
onnxruntime/test/common/cpuid_uarch_test.cc	Adds unit tests for MIDR decoding (Qualcomm + ARM implementers).
onnxruntime/core/common/cpuid_uarch.h	Extends ORT’s internal uarch enum with Oryon / Oryon V3.
onnxruntime/core/common/cpuid_uarch.cc	Updates MIDR decoding switch to recognize A78C, Oryon, and Oryon V3.
onnxruntime/core/common/cpuid_info.cc	Clarifies narrow-load detection comment for Windows ARM uarch classification.
cmake/vcpkg-ports/cpuinfo/portfile.cmake	Adds a new cpuinfo patch to the vcpkg port.
cmake/vcpkg-ports/cpuinfo/add_oryon_v3_and_a78c.patch	Patches upstream cpuinfo to add Oryon V3 and A78C handling.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[yuslepukhin]

The patch you created will update only vcpkg builds but not buildes based on deps.txt. Thus it will produce different builds.

You need to bring a new dependancy and eliminate the need for the patch.

Bump both deps.txt and portfile.cmake to a newer cpuinfo commit that includes 002c213 natively (eliminating the need for the patch entirely)