feat: add Intel Arc (XPU) torch backend to launcher

[wesd6r]

Summary

Add an Intel Arc (XPU) GPU option to the launcher install flow, so users can install Invoke with the xpu torch backend.

InvokeAI already ships first-class Intel XPU support (torch==2.13.0+xpu, torchvision==0.28.0+xpu, and the intel-xpu-backend-for-triton wheel triton-xpu==3.7.2) via its xpu extra and the whl/xpu PyTorch index. The launcher, however, only exposed NVIDIA, AMD and no-GPU options and mapped them to cuda / rocm / cpu, so Intel Arc users could not install through the launcher.

Changes

• src/shared/types.ts: add intel to GpuType and GPU_TYPE_MAP ('Intel Arc (XPU)').
• src/main/util.ts: getTorchPlatform returns 'xpu' for 'intel' (macOS still returns 'cpu').
• src/shared/pins.ts: accept the xpu key in the torchIndexUrl schema, so the legacy install path can resolve https://download.pytorch.org/whl/xpu.
• src/main/install-manager.ts: widen getInvokeExtras' torchPlatform type to include 'xpu', so uv sync --extra xpu / invokeai[xpu]==... is passed through.
• InstallFlowStepConfigureGpuPicker.tsx: add the Intel Arc (XPU) button.
• InstallFlowStepReview.tsx: add the an Intel Arc GPU review label.

Notes

• This only works for Invoke releases that contain the xpu extra (6.14.0+). On older releases the extra is filtered out by the existing getDeclaredOptionalDependencies() guard and the install falls back to cpu.
• Verified end-to-end: uv sync --extra xpu --frozen --no-install-project resolves torch==2.13.0+xpu, torchvision==0.28.0+xpu and triton-xpu==3.7.2, and a real install via the launcher (Invoke v6.14.0-rc2) completed successfully.

[wesd6r]

Adds an Intel Arc (XPU) GPU option to the launcher install flow. InvokeAI already supports xpu via its xpu extra (torch 2.13.0+xpu / triton-xpu); this wires intel -> xpu so the launcher can install invokeai[xpu]. Requires Invoke 6.14.0+. Locally verified: tsc/eslint/prettier pass, and an end-to-end launcher install (v6.14.0-rc2) installed torch==2.13.0+xpu and triton-xpu successfully. CI did not auto-run on this fork PR - happy to adjust if any check needs it.

[wesd6r]

Hi maintainers — requesting review and a CI run.

This PR wires an Intel Arc (XPU) option into the launcher install flow, mapping it to torch's xpu backend so the launcher can install invokeai[xpu] (which pulls torch==2.13.0+xpu and triton-xpu).

InvokeAI already supports XPU natively through its xpu extra, so this simply connects the launcher to that existing path.

What changed:

• src/shared/types.ts: add intel to GpuType / GPU_TYPE_MAP
• src/main/util.ts: getTorchPlatform returns 'xpu' for intel
• src/shared/pins.ts: accept the xpu torch index key
• src/main/install-manager.ts: widen the torchPlatform type
• InstallFlowStepConfigureGpuPicker.tsx + InstallFlowStepReview.tsx: add Intel Arc option / label

Verified locally:

• tsc --noEmit, eslint, prettier all pass.
• End-to-end launcher install (Invoke v6.14.0-rc2) successfully installed torch==2.13.0+xpu and triton-xpu.

CI status: on the fork (wesd6r/launcher) this branch passes Run Code Quality Checks and Run Tests. Upstream required checks are not running on this fork PR — could you approve/run the workflows? Happy to adjust anything if needed.

Thanks!

[iwr-redmond]

6.14.1 may be needed first. That is the tag attached to the PR in the core codebase.

[lstein]

Sorry for the delay. I'll give this a review. Release will probably be coordinated with 6.14.1.

[lstein]

Thanks for this — the happy path is solid. I verified against InvokeAI v6.14.0 upstream that the "xpu" extra is declared, registered in [tool.uv] conflicts, mapped in [tool.uv.sources] for torch/torchvision/triton-xpu, and backed by a torch-xpu index pointing at whl/xpu; its pins.json carries xpu for both win32 and linux. On current stable this does exactly what it says.

The problem is every other version. Both issues below end the same way: a user selects Intel Arc (XPU), the install exits 0 and reports Installation completed successfully, and they get a torch build that cannot drive an Arc GPU — with no error surfaced.

---

1. Intel + any release below 6.14.0rc1 silently installs CUDA torch

src/main/install-manager.ts:605-608, reached via the new src/main/util.ts:85-86.

Below MIN_BOOTSTRAP_INSTALL_VERSION, the --index flag is the only thing steering torch. Fetching the real, immutable pins.json from upstream tags:

tag	torchIndexUrl keys
v5.10.0, v6.9.0, v6.13.0, v6.13.8	cuda / cpu / rocm — no xpu
v6.14.0-rc1	cuda / cpu / rocm — no xpu
v6.14.0-rc2, v6.14.0	+ xpu

xpu first appears at v6.14.0-rc2 — i.e. only in versions that take the bootstrap path, where line 605 never executes. So pins.torchIndexUrl[platform].xpu is undefined on every version that actually reads it, and those tags are frozen.

Trigger: Linux x64 or Windows x64 → Version step → Manual → 6.13.8 (ManualVersionEntry only validates PEP440 syntax) → GPU step → Intel Arc (XPU) → Install.

Line 229 passes null as torchPlatform on the legacy path, so invokeExtras is []; line 606's falsy guard then drops --index entirely. uv pip install invokeai==6.13.8 therefore resolves torch from default PyPI. Checking the actual wheels: on linux_x86_64 that is the CUDA build — an 821 MB wheel that hard-depends on nvidia-cuda-nvrtc-cu12, nvidia-cudnn-cu12, nvidia-cublas-cu12 and friends (~2 GB more), none of which can drive an Arc GPU. On Windows it's the 216 MB CPU-only wheel. Meanwhile line 315 logs - Torch platform: xpu.

This is unique to the new option — amd finds rocm and nvidia finds cuda in every legacy pins.json back to 5.x. intel is the only GpuType whose legacy lookup misses.

Side effect: the xpu key added to zPlatformIndicies in src/shared/pins.ts:8 is required for line 605 to typecheck, but has no runtime effect today, since no release that reaches that line publishes the key. It becomes load-bearing only once this is fixed.

2. v6.14.0-rc1 takes the bootstrap path but has no xpu extra — same outcome

Using the @renovatebot/pep440 compare the launcher itself imports, compare('6.14.0-rc1', '6.14.0rc1') === 0, so rc1 is bootstrap-eligible. But rc1's pyproject.toml declares only cpu/cuda/rocm (its [tool.uv] conflicts list confirms it — XPU landed in rc2).

So invokeExtras = ['xpu'] is filtered out at line 263, the loop at line 535 adds no --extra at all, and uv sync --frozen resolves the no-extra universe → base torch>=2.7.0,<3.0 from PyPI → the CUDA build on Linux again. The only signal is a single yellow Skipping undefined Invoke package extras: xpu at line 266, scrolled off in the PTY log.

One correction to the PR description, which says older releases are safe because "the extra is filtered out by the existing getDeclaredOptionalDependencies() guard and the install falls back to cpu":

• On the legacy path that guard is never reached — invokeExtras is already empty there, because line 229 passes null.
• There is no cpu fallback anywhere in the code. It falls back to whatever PyPI resolves, which on Linux is CUDA, not CPU.

The guard prevents a crash, not a wrong install.

---

Suggested fix

Fail fast in startInstall rather than degrading silently:

• if torchPlatform === 'xpu' and !useBootstrapInstall → updateStatus({ type: 'error' }) naming the minimum XPU-capable version (6.14.0rc2);
• if torchPlatform === 'xpu' and !declaredExtras.has('xpu') → same, instead of the current warn-and-continue.

More broadly, the silent if (torchIndexUrl) fall-through at line 605 should probably be an error for any non-cpu platform whose index is missing — that would also cover the pre-existing AMD-on-Windows-legacy case.

Two unit tests would lock both down: getTorchPlatform('intel') and getInvokeExtras('intel', …) currently have no coverage, and the pins.test.ts fixture has no xpu key.

Minor, non-blocking

• The GPU picker renders the Intel Arc button on macOS (InstallFlowStepConfigureGpuPicker.tsx:20), where getTorchPlatform returns 'cpu' for every type while the review step asserts "You have an Intel Arc GPU." Not a regression — amd has the same wart — but the launcher asserts darwin arm64 only, so no supported Mac can ever have an Arc GPU.
• tsc, eslint, prettier, knip and vitest (90 tests) are all green on this branch.

[wesd6r]

@lstein — thanks for the thorough review. Both failure modes you identified are fixed on this branch (commits 566dcb1, 4a82f99):

[lstein]

Thank you very much for all the work you put into this. Unfortunately I messed up and did not realize that the probes you added were already contained in the earlier PR 137 that was just merged into main. This work has been superseded, and I apologize for the misfire.