[eserscor]

Description

Move the existing per-type HasCudaEnvironment(is_float16 ? 530 : 0) check to the start of RunModelWithRandomInput, before constructing the random generator, allocating token offsets, or generating inputs, weights, and biases. Unsupported environments now report GTEST_SKIP() before any OpTester is constructed.

The shared guard covers TestWithRandomData, TestWithRandomDataWithRBP, and TestWithRandomDataLargeSeq. Supported GPU FP32/FP16/RBP/large-sequence dimensions, seeds, inputs, tolerances, reference comparisons, and minimum CUDA architectures are unchanged. The guard remains per invocation: lack of FP16 support does not prevent the mixed-type cases from exercising supported FP32 inputs. No CI, build optimization, cache, or image changes.

Validation — head b8eda7e79f5c9787ae23670802a2179fc0a2418f:

• Linux ARM64 Debug CI: passed. The draft PR job built and tested successfully on ort-github-linux-16-arm64-eus2-ss, the same CPU runner pool as the reference. Its provider-test command was /onnxruntime_src/build/Debug/Debug/onnxruntime_provider_test "--gtest_output=xml:/onnxruntime_src/build/Debug/Debug/onnxruntime_provider_test.Debug.results.xml" — passed; 7,024 tests selected, including all three random-data cases, each explicitly reported skipped. This is not a zero-match pass.
• git diff --check — passed.
• .\.venv\Scripts\clang-format.exe --dry-run --Werror onnxruntime\test\contrib_ops\packed_attention_op_test.cc — passed with clang-format 20.1.8.
• Windows x64 CPU-only Debug: in an isolated .venv, after call "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Auxiliary\Build\vcvars64.bat", ran .venv\Scripts\python.exe tools\ci_build\build.py --build_dir build\n --config Debug --update --build --parallel 12 --skip_submodule_sync --cmake_generator Ninja --target onnxruntime_provider_test --disable_memleak_checker — passed. Build log confirms packed_attention_op_test.cc.obj recompiled and the executable relinked. Cache confirms Debug and CUDA OFF.
• From build\n\Debug: onnxruntime_provider_test.exe --gtest_filter=PackedAttentionTest.TestWithRandomData* --gtest_list_tests — exit 0; listed exactly the three existing random-data tests.
• From the same directory: onnxruntime_provider_test.exe --gtest_filter=PackedAttentionTest.TestWithRandomData* --gtest_output=xml:C:\Users\erscor\.copilot\session-state\893b4970-454c-4884-9b9c-2c936909fed7\files\packed-attention-cpu-debug.xml — exit 0; 3 selected, 3 skipped, 0 failures. Local x64 XML reports 10 ms / 4 ms / 0 ms for random data / RBP / large sequence; gtest reports 16 ms suite time, 19 ms including global setup/teardown. These are separate x64 results, not the ARM64 performance comparison below.

Local build notes: Visual Studio generation first hit Windows' 260-character MSBuild path limit, so validation used Ninja in this worktree. The initial default Debug executable compiled successfully and selected/skipped all three tests, but its experimental Windows memory-leak checker exited -1 at shutdown; even --gtest_list_tests alone reported shutdown leaks. The clean local validation above uses the repository-supported --disable_memleak_checker option locally only; Debug optimization settings are unchanged. No repository build settings were edited.

CUDA hardware/runtime is unavailable locally. GPU execution was not performed locally; the original architecture expression and supported GPU path were inspected for unchanged behavior. CPU-only runs verify early gating, not GPU numerical correctness.

Motivation and Context

The CUDA-only random-data tests previously generated large CPU fixtures before checking whether CUDA was available. Measured Linux ARM64 Debug comparison, using the completed reference job and successful after-change draft PR job:

Test (PackedAttentionTest. prefix)	Before	After	Saved
TestWithRandomData	266,632 ms	4 ms (skipped)	266,628 ms
TestWithRandomDataWithRBP	133,346 ms	3 ms (skipped)	133,343 ms
Two reported slow tests	399,978 ms	7 ms	399,971 ms (~6m40s)
TestWithRandomDataLargeSeq	10,943 ms	0 ms reported (skipped)	10,943 ms
All three helper callers	410,921 ms	7 ms	410,914 ms (~6m51s)

The reported slow pair's runtime fell by 99.998%, measured on the same ARM64 Debug CPU runner pool. Millisecond timings are rounded by gtest; 0 ms does not mean literally zero elapsed time.

The whole provider-test CTest entry went from 2,112.21 s to 1,706.48 s, an observed reduction of 405.73 s (19.21%). Treat that as descriptive, not a controlled whole-suite attribution: the reference selected 7,019 tests and the PR merge selected 7,024, and these are different CI runs/commits. The pair alone accounted for 18.94% of the reference provider-test time; all three accounted for 19.45%.

The supplied cold-run reference pair is consistent (266,686 + 133,286 ms); the supplied ARM64 Release reference pair was 2,333 + 1,170 ms. The additional ARM64 Release measurements are reported below; no GPU performance timings are claimed.

Independent change based on main; does not modify or stack on #34163 or the ccache experiment.

Cross-platform impact

Combined gtest time for all three existing random-data tests (including the large-sequence case):

Configuration	Before	After	Saved
Linux ARM64 Debug	410,921 ms	7 ms	410,914 ms
Linux x64 Debug + ASan	56,309 ms	6 ms	56,303 ms
macOS ARM64 Debug	14,912 ms	0 ms reported	14,912 ms
Windows x64 Release (two executions)	6,625 ms	2 ms	6,623 ms
Linux ARM64 Release	3,598 ms	1 ms	3,597 ms
Linux x64 Release	2,442 ms	0 ms reported	2,442 ms
Linux x64 Release / Python 3.14	2,451 ms	0 ms reported	2,451 ms

Total measured aggregate test execution removed: 497,242 ms (8m17.242s) across these jobs, not an equivalent decrease in elapsed PR/CI time. Every after-change occurrence explicitly reports skipped; all compared jobs succeeded. Windows runs the provider tests twice (regular and example-plugin executions), and both executions are included. Gtest rounds timings to milliseconds.

Sources: Linux before / after; macOS before / after; Windows before / after. Linux compares the earlier experiment reference with this PR; macOS/Windows use successful main runs at this branch's base commit, 6080d7c. These are separate runs, not controlled repeated benchmarks.

Total workflow elapsed time: estimate versus observation

No net end-to-end workflow reduction was observed in these particular run pairs. Using the first job's started_at through the final job's completed_at (excluding initial runner queue delay, but including later job scheduling gaps), GitHub reports:

Workflow	Before execution span	After execution span	Observed change
Linux CI	46m31s	51m06s	4m35s longer
MacOS CI Pipeline	86m42s	94m44s	8m02s longer
Windows x64 Release	33m54s	34m04s	10s longer

Including initial queue time, creation-to-final-job-completion was Linux 49m48s -> 54m33s, macOS 86m46s -> 94m49s, and Windows 43m14s -> 66m28s. In particular, the Windows after-run waited about 32m24s before its job started, versus 9m20s before; this is not test runtime.

The fixture savings are directly visible in individual test timings, but build/configuration/cache state, scheduling, other tests, and different commits confound whole-workflow comparisons. The ARM64 Debug provider-test entry itself decreased by 405.73s (19.21%), while the entire ARM64 Debug job increased from 43m38s to 50m22s; other work more than offset the test savings in this pair.

All-else-equal critical-path estimate: ARM64 Debug was the last-finishing Linux job in both runs. Removing its measured 410.914s of fixture work would shorten the reference Linux workflow execution span from 46m31s to about 39m40s: approximately 6m51s, or 14.7%, provided other timings remain fixed and no other job becomes the bottleneck. This is a modeled potential wall-clock saving, not an observed workflow speedup. Savings in parallel Linux jobs do not add to that critical-path reduction. The measured macOS CPU Debug job was not the final-finishing job (the ARM64 iPhone simulator was), so its 14.912s saving alone does not shorten that workflow's critical path. For the single-job Windows workflow, the isolated all-else-equal saving is about 6.623s (0.33% of baseline execution time).

Builds that do not execute these tests receive no benefit. Supported CUDA paths still generate and exercise the original fixtures; no GPU computation speedup is claimed.

[Copilot]

🟢 Approval recommended

No active review issues were identified for the change that skips unsupported CUDA configurations before random-input generation.

No open issues 🎉

What changed in this PR

Moves the CUDA availability check ahead of PackedAttention random-input generation, avoiding expensive fixture setup on unsupported environments.

Changes:

• Reports unsupported configurations as skipped before constructing an OpTester.
• Preserves per-type CUDA requirements and supported GPU test behavior across all three random-data tests.

No actionable findings.

File	Description
onnxruntime/​test/​contrib_ops/​packed_attention_op_test.cc	Moves the shared CUDA guard before random-data allocation and generation, removing the later conditional wrapper.

_{Review effort: Balanced}