[Tasks] Add gfxVersion to AMD GPUs in hardware.ts

[julien-c]

Summary

• Add gfxVersion optional field to HardwareSpec interface — the AMD equivalent of NVIDIA's computeCapability
• Populate gfxVersion for all 24 AMD GPU entries, derived from GFX targets (LLVM ISA)
• Stacked on [Tasks] Add computeCapability to NVIDIA GPUs in hardware.ts #2010

Test plan

• npx tsc --noEmit passes
• Grep confirms all 24 AMD GPUs have a gfxVersion entry

---

Note

Low Risk
Low risk: adds a new optional metadata field (gfxVersion) and populates it for AMD GPU SKU entries, with no behavioral or control-flow changes.

Overview
Adds an optional gfxVersion field to HardwareSpec as the AMD counterpart to NVIDIA computeCapability.

Populates gfxVersion across all AMD GPU entries in SKUS (e.g. MI-series and RX-series) to record the corresponding GFX/LLVM ISA target.

^{Written by Cursor Bugbot for commit a356048. This will update automatically on new commits. Configure here.}

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

[cursor]

Lossy encoding of gfx90a as numeric gfxVersion 9.1

Medium Severity

The MI250 and MI210 use LLVM target gfx90a, where a is a hex digit. The gfxVersion: 9.1 encoding breaks the implicit bijective mapping that all other entries follow (e.g., 9.42 ↔ gfx942, 11.01 ↔ gfx1101). A consumer reconstructing the --offload-arch target from 9.1 would produce gfx910 instead of gfx90a. Using number as the type for gfxVersion makes hex-containing targets like gfx90a inherently lossy — unlike NVIDIA's computeCapability, GFX targets are string identifiers that can contain hex characters.

Additional Locations (2)

• packages/tasks/src/hardware.ts#L588-L589
• packages/tasks/src/hardware.ts#L38-L39

 

[julien-c]

i know but i think it might be fine no?