[CI] Split Windows Dawn builds from GPU tests (#34084)
### Description
<!-- Describe your changes. -->
Split the two remaining Windows Dawn paths in
`.github/workflows/windows_webgpu.yml` into compilation on
`ort-github-win-16-amd-scus-ss` and artifact-only execution on
`ort-github-win-6-a10-scus-ss`.
| Existing check | CPU work | GPU work |
| --- | --- | --- |
| `webgpu_external_dawn_build_x64_RelWithDebInfo` | Configure/build the
external-Dawn test host; validate/export the matching Dawn API package;
stage the executable and runtime DLL tree | Existing inference,
missing-proc-table, host-device, synchronization-rejection and
cache-callback tests |
| `webgpu_dawn_package_build_x64_RelWithDebInfo` | Build package-backed
built-in ORT and shared-library WebGPU plugin variants; preserve
invalid-package and no-native-Dawn-source checks | Existing
package-backed built-in and plugin tests, including the
unrelated-plugin-load-error rejection |
Both original check names remain as always-running gates that fail when
compilation or execution fails or is skipped. The package compilation
still waits for the external-Dawn check to succeed. Neither GPU job
checks out/configures/rebuilds ORT.
Artifacts are bounded to the matching host executable, relative runtime
DLL trees (including nested `D3D12/` dependencies), and exported Dawn
API inputs where needed. Built-in and plugin ORT variants compile in
independent `dawn-package-builtin-build` and `dawn-package-plugin-build`
trees and are staged into separate test directories, preserving
configuration and ABI isolation. Invalid-package checks use a third,
configure-only `dawn-package-validation` tree so expected failures
cannot contaminate either valid build. Both artifact uploads use the
configured default retention to support later GPU-test reruns. The test
model is embedded in the host, so no CTest/source-path relocation or
external fixtures are required. Staging and native-command errors
explicitly fail the build.
The static-plugin, built-in/shared-plugin and minimal-build jobs are
unchanged, as is the shared vcpkg binary-cache setup (restore on all
runs, save only on main). No compiler caching, generator/PCH changes,
DML/CUDA/TensorRT changes, or dependency on unmerged DML work.
Validation performed locally, including the review fixes in
`3b52251b26`:
- `actionlint -shellcheck= -ignore 'label ".+" is unknown'
.github\workflows\windows_webgpu.yml` — passed; only custom-runner-label
diagnostics suppressed, with exact runner identities checked separately.
- `python tools\ci_build\github\windows\package_external_dawn_test.py` —
passed, 4 tests, using an isolated Python environment.
- `python "$env:DAWN_VALIDATION_DIR\validate_dawn_split.py"` — passed.
This uncommitted session-local harness checks YAML structure, unchanged
unrelated jobs/cache, preservation of native build options and test
commands (allowing the intentional build-directory changes and added
configure-only validation), isolated build/validation paths, default
retention, CPU/GPU phase boundaries, artifact producer/consumer names,
and all 32 gate-result combinations. It also executes extracted
PowerShell staging blocks with synthetic build outputs and the real Dawn
exporter, checks PowerShell syntax, relocates payloads to a different
root, verifies nested DLLs and built-in/plugin isolation, and injects
native-command failures. This is not a native build or GPU-inference
result.
- `git diff --check` — passed.
Full native Dawn compilation and GPU inference were not run locally;
this fresh worktree has no built Dawn binaries. They passed in normal PR
CI at `133eb1d9c1`, including runner-to-runner native dependency loading
and GPU execution for both Dawn paths. The subsequent build-tree
isolation changes in `3b52251b26` still require normal PR CI
verification. No CI was manually triggered.
#### Measured CI performance
Compare the successful [baseline run at the exact parent commit
`116967d5d6`](https://github.com/microsoft/onnxruntime/actions/runs/42838644160)
with the successful [PR run at
`133eb1d9c1`](https://github.com/microsoft/onnxruntime/actions/runs/42852672929).
Durations are calculated from GitHub Actions job and step timestamps.
These measurements predate the review changes that isolate both package
builds and add a separate validation configure tree; they are not
timings for the latest revision.
| Metric | Before | After | Improvement |
| --- | ---: | ---: | ---: |
| Full Dawn chain elapsed | 2h 17m 01s | 58m 26s | **57% shorter; 2.35x
faster** |
| GPU-runner time, both Dawn paths combined | 2h 16m 44s | 52s | **99.4%
less** |
| External-Dawn build step | 54m 34s | 17m 36s | **3.10x faster** |
| Package-backed ORT build step | 33m 41s | 13m 19s | **2.53x faster** |
| Package-backed plugin build step | 29m 36s | 10m 54s | **2.72x
faster** |
The full-chain elapsed measurement runs from the external-Dawn job start
through the final package check, including inter-job waits; it is not
the duration of the entire WebGPU workflow. GPU-runner time is the sum
of the Dawn jobs' start-to-completion durations, excluding queue time.
In the measured split run, the two CPU compilation jobs took 55m 26s
combined, while the GPU test jobs took only 18s and 34s, including
artifact downloads, setup and GPU-access verification. All Dawn tests
and both legacy result gates passed.
These are observations from one before/after run pair, not a repeated or
controlled benchmark. They measure CI throughput and GPU-runner
occupancy, not an inference-performance change or a monetary cost
estimate.
### Motivation and Context
<!-- - Why is this change required? What problem does it solve?
- If it fixes an open issue, please link to the issue here. -->
Keep expensive Windows Dawn compilation off GPU runners before
introducing compiler caching, while retaining both source-Dawn and
package-backed ABI/plugin coverage. This is independent of the DirectML
split in #34080 and leaves the separately owned static-plugin split
untouched.
---------
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
