Follow standard CMake semantics for CUDA architecture suffixes

[Sammy-Dabbas]

Description

setup_cuda_architectures in cmake/external/cuda_configuration.cmake was non-standard in two ways (#29598): only the last -virtual entry was kept, so 86-virtual;120-virtual dropped PTX for 8.6; and a suffix-less arch like 86 became 86-real only, dropping its virtual arch.

This tracks real and virtual architectures in separate lists. A suffix-less arch enables both (standard CMake: 86 gives 86-real and 86-virtual), -real/-virtual entries are kept as given, and all -virtual entries are preserved. The accelerated a and family-code f handling apply to both, and CMAKE_CUDA_ARCHITECTURES_ORIG is the deduplicated union.

Motivation and Context

Fixes #29598. Thanks @cschreib-ibex for the reference patch; this builds on it, fixing that its -virtual regex only matched even digit counts (so 100-virtual/120-virtual fatal-errored) and predated the f family branch. Verified the list logic with a cmake -P harness; nvcc compilation should be confirmed by CI.

[Copilot]

Pull request overview

This PR fixes ONNX Runtime’s CUDA architecture normalization in setup_cuda_architectures to follow standard CMake semantics, ensuring both SASS (-real) and PTX (-virtual) handling is correct and that multiple -virtual entries are preserved (fixing #29598).

Changes:

• Split normalization into separate “real” and “virtual” cleaned lists so multiple -virtual entries are retained.
• Make suffix-less architectures (e.g., 86) enable both 86-real and 86-virtual as standard CMake does.
• Normalize accelerated (a) and family (f) handling across both real and virtual variants and expose the deduplicated union via CMAKE_CUDA_ARCHITECTURES_ORIG.

[cschreib-ibex]

Thanks for writing the PR.

FYI I also discovered today that the logic of forcing all "accelerated" archs (90, 100, 101, 110, 120) to the *a-virtual/*a-real architecture family, which is also non-standard, can be problematic because these architectures are not forward compatible. See CUDA docs:

Application binaries that include PTX version of kernels with architecture conditional features using sm_100a or compute_100a in order to take full advantage of Blackwell GPU architecture, are not forward or backward compatible. For example, PTX compiled for compute_90a (Hopper) are not supported on the Blackwell architecture.

So for example, if you select 120-virtual in CMake, this will be turned into 120a-virtual for onnxruntime, and the embedded PTX will not be forward compatible with newer GPUs. If this is the only virtual architecture in the list, effectively this means the resulting binaries will not work on newer GPUs.

At present this can be circumvented by adding at least one "non-accelerated" virtual architecture (e.g., 89-virtual) to the list.