1.8.0 SDK ships no PHX/HPT xclbin files despite docs referencing phoenix/4x4.xclbin

[jdominick05]

Environment

• Ryzen AI Software 1.8.0 (Windows)
• Target: Phoenix / Hawk Point (XDNA1), INT8 CNN inference via the VitisAI ONNX Runtime EP

Problem

The 1.8.0 SDK install does not ship any PHX/HPT xclbin files, despite the documentation correctly and consistently referencing phoenix\4x4.xclbin as the value for the xclbin provider option on these devices.

A recursive search of the entire voe-4.0-win_amd64\ install tree finds zero *.xclbin files. The only xclbin anywhere in the 1.8.0 install tree is data\parts\xilinx\xclbin\strx\base.xclbin (Strix — not applicable to PHX/HPT).

For comparison, the 1.7.1 SDK does ship voe-4.0-win_amd64\xclbins\phoenix\4x4.xclbin (and 1x4.xclbin) at exactly the path 1.8.0's own docs describe.

This looks like a packaging gap rather than a documentation error — the docs are internally consistent about where the file should be, it's just missing from the shipped package.

Reproduction

1. Install Ryzen AI Software 1.8.0 on a PHX or HPT device.
2. Search the install root recursively for *.xclbin.
3. Compare against a 1.7.1 install, where voe-4.0-win_amd64\xclbins\phoenix\4x4.xclbin is present.

Impact

Any attempt to build a VitisAI EP session targeting PHX/HPT under 1.8.0 with the documented xclbin provider option value fails to find the file. Falling back to driver-resolved firmware (omitting an explicit xclbin) is worse, not better: without an explicit xclbin the compiler defaults to AMD_AIE2P_4x4_Overlay (a Strix target), and the run either DPU-timeouts or silently falls back to CPU while the VitisAI EP still reports as active in the session's provider list — a CPU run that looks like an NPU run, with no error to signal it.

Workaround

Point RYZEN_AI_INSTALLATION_PATH (or the xclbin provider option directly) at a 1.7.1 install, which does ship the file, while using 1.8.0 for everything else (export, quantization).

Ask

Could someone confirm whether this is a known packaging gap for 1.8.0, and whether a fix is planned — or whether PHX/HPT INT8 CNN support via this path is being deprioritized as newer silicon (Strix/Strix Halo/Krackan) takes over?

[jdominick05]

Related: #401 (same shape of failure — the EP reports success while quietly doing something else: CPU in an NPU costume here, an unwritten output buffer there).

Adding the workarounds actually tried before filing, in case they change triage:

• Driver-dropped xclbins in C:\Windows\System32\AMD\ (4x4_3.5.0.0-2352, 4x4_3.5.0.0-2160_ipu_2) do exist on this machine, but 1.8's EP rejects both:
  Cannot find or create target with fingerprint=0x080002050018eec1 and 0x0a000205001c8d4c respectively.
• Letting the EP omit xclbin and resolve firmware itself does not fall back to a working state either — it compiles for AMD_AIE2P_4x4_Overlay (a Strix target) and the run then dies with DPU timeout ... ERT_CMD_STATE_ERROR, or in other configurations silently runs on CPUExecutionProvider while VitisAIExecutionProvider still shows in the session's provider list — no exception, no log line marking the fallback.

So the only working path found is pointing RYZEN_AI_INSTALLATION_PATH at a 1.7.1 install for the xclbin while using 1.8.0 for export/quantize — not something a fresh 1.8.0-only install could discover on its own.

To be clear about the ask: I'd rather know honestly that PHX/HPT INT8 CNN support via this path is being deprioritized than get a fix I'm not confident is coming — either answer is useful, I just want to stop guessing.