[QC][ARM] Windows on Arm support

[khmyznikov]

Is it possible to have the triton with Qualcomm backend? X2 Elite looks very beefy in both GPU and NPU.
I'm wondering if we can investigate test builds with stubbed support.

[woct0rdho]

Let's continue the discussion in woct0rdho#119 . Now Triton officially publishes wheels on Linux + ARM CPU, so there should be nothing x86-specific in the core Triton, and Windows + ARM CPU should be doable.

The first step is to build Triton's interpreter mode on Windows + ARM CPU, which does not require a GPU, and people are already doing this on macOS + ARM CPU. You can try to build following BUILD.md . Also, you need to build LLVM (Currently the upstream does not provide prebuilt LLVM on Windows + ARM CPU). If you successfully builds this and runs the unit tests, please share your experience.

Then we can have a Vulkan (SPIR-V) backend. The Intel-forked Triton is already doing this, and let's see how well we can compile SPIR-V to other chips.

[khmyznikov]

@woct0rdho isn't that repo stalled? Could you explain the fact the repo got moved to here? Is it got the official status?

[woct0rdho]

triton-windows has been supported by AMD people, so we have moved the development to the triton-lang organization and it's not anymore a one-man project of mine. I'd be happy to see it also supported by Qualcomm people :)

[khmyznikov]

@woct0rdho seems like it's impossible to continue in the old one 😂

[woct0rdho]

Indeed, let's continue the discussion here

[praso-qc]

Hi @woct0rdho,

Quick update on the Windows on Arm64 bring‑up for Triton.
We now have a successful native ARM64 build. The current state is interpreter‑first (no JIT or backend execution yet), which aligns with the direction discussed in this issue.

============================
Summary of code changes :

CMake : Added a TRITON_CPU_ONLY mode and gated out GPU-dependent components:
- Disabled bin/ targets in CPU-only (avoids linking GPU target libs).
- Gated lib/Analysis, lib/Conversion, lib/Target and GPU dialect subdirs so CPU-only builds don’t require NVIDIA/AMD dialect TableGen headers.
- Reduced Python extension link dependencies to core MLIR/LLVM only (no NVPTX/AMDGPU libs).

Python native bindings : Added CPU-only stub bindings to keep _C.libtriton importable without GPU:

• cpu_only_stubs.cc for minimal functions needed by Python config (getenv/getenv_bool) plus no-op hooks.
• llvm_cpu_only.cc to avoid linking heavy LLVM components (MIRParser/PassPlugin/X86 init) and expose a cpu_only marker.

Python package import gating : Patched python/triton/init.py so CPU-only mode does not auto-import runtime/jit/backends (prevents make_tensordesc_args import error path).

============================

At this point:

• import triton works cleanly on Windows on Arm64
• _C.libtriton loads with cpu_only: True
• This is an interpreter‑first bring‑up, as expected

Questions:

1. Do these changes look reasonable from an upstream perspective?

2. For next steps on Windows on Arm64, would you recommend:

   • continuing with triton‑windows and moving towards a backend (e.g. Vulkan/SPIR‑V) for Snapdragon, or
   • shifting to triton‑cpu (https://github.com/triton-lang/triton-cpu) for a true CPU backend execution path (acknowledging it is experimental)?

Thanks for the guidance.

[woct0rdho]

Hi @praso-qc , great to hear the news!

I haven't tried to build the interpreter mode for a while and I'm a bit surprised to see that there is not a simple switch to build the interpreter mode without any backend (despite build-macos.yml looks simple). If the changes are OS-agnostic, I think you can make a PR for them in the upstream Triton repo.

After you build the wheel, can you pass the unit tests for the interpreter?

I don't know much about backends, but I guess people would be more excited to see a GPU backend rather than a CPU one. Also, I haven't checked whether triton-cpu supports ARM CPU now.

[khmyznikov]

@woct0rdho I'm wondering if there are any roadmaps or requirements for merging this fork into the main. Some of our partners are confused about its "official" status and hesitant to contribute. Do you know anyone from the core maintainers who might have an answer? I'm referring not specifically to arm64, but to the Windows branch in general.

[woct0rdho]

The upstream Triton developers are a small team with limited bandwidth to merge Windows support, so I think triton and triton-windows will remain two packages in the foreseeable future. Search 'Windows' in their issues and you'll see their attitude.

One reason that the triton-windows repo exists is to have a place for Windows users to ask questions, which is a different landscape from the compiler issues that the upstream Triton developers focus on.

I'm aiming to add Windows support without changing Linux behavior in this repo, so you can use this repo as an upstream for both Linux and Windows. Please correct me if there is any Linux behavior changed. (The only one I can think of is fp8 support.)

Previously a roadblock preventing triton-windows from becoming a dependency of torch was that I don't have the bandwidth to support AMD GPU. Now AMD is working on it, see #2 for the progress. This repo is already merged into AMD's TheRock build pipeline. Although TheRock is not exactly official, at least it means this repo has passed AMD's supply chain audit.

There is only one remaining test failure on RDNA3 consumer GPU. We're waiting for the fix to be merged in LLVM and in the upstream Triton, or we can just skip this test. I hope this happens before releasing Triton 3.7 in April. When the CI for AMD GPU fully passes, this repo will look much more mature, then I'm planning to make it a dependency of torch, and seeking a CI for Nvidia GPU.

I think adding a new backend is out of scope of this repo. Intel, Huawei, MooreThreads are all maintaining their own forks. The upstream Triton is working on an out-of-tree extension system to make it easier. There are still some designs to be settled, see intel/intel-xpu-backend-for-triton#6291 , and 'Triton Extensions on Windows' in https://github.com/triton-lang/triton/blob/main/docs/meetups/05-05-2026/notes.md

Interestingly, there is a community-made backend for Apple GPU, and it's being discussed to make it work with the extension system, see triton-lang#9701

[woct0rdho]

I've documented the branches and development workflows at https://github.com/triton-lang/triton-windows/blob/readme/BUILD.md#branches-in-this-repo

[khmyznikov]

@woct0rdho I'm worry about having multiple forks for windows... Not sure it's the right way. triton-windows-amd, triton-windows-nvidia, triton-windows-qc, etc... But at the same time, is it feasible to keep everything together?

[woct0rdho]

Coordinating the PyTorch ecosystem across multiple vendors is surely beyond my personal opinions. But in my opinion, everyone maintaining a fork seems more practical than everyone working in the same repo. Also, you don't need a fork specifically for Windows, and you can use this repo as an upstream for both Linux and Windows.

Take PyTorch itself as an example: There are in-tree backends such as Nvidia CUDA, AMD ROCm, Apple MPS, and out-of-tree backends such as Google XLA, Huawei CANN (Ascend), MooreThread MUSA. Maybe we can first start building a forked repo and see whether it's maintainable. (Although AFAIK Qualcomm only have some inference libraries but haven't had a PyTorch backend yet?)

An example of everyone working in the same repo is maybe the Linux kernel, and I don't know much about it...

Also let's start a discussion in the pytorch repo, see pytorch/pytorch#178368