[Windows][BMG] Sol-Attn forward_cute causes DEVICE_LOST on Arc B580 while prepare succeeds

[yzwzhanghao2]

Summary

I tested the new BMG Sol-Attn path from llm-scaler commit 3ac20587ed77b3e8adb100ca56fa0fbabb062db5 on Windows 11 with an Intel Arc B580.

The Windows sidecar can be compiled and loaded after two host-portability adjustments, and omni_xpu_sol_attn.prepare runs successfully. However, the first omni_xpu_sol_attn.forward_cute execution causes a Level Zero device loss, even with the smallest upstream-style BF16 D128 input.

I understand that setup.py currently filters CUTE/Sol-Attn out on Windows. This report is intended as a minimal reproduction and a request for guidance on the missing Windows BMG runtime support.

Environment

• GPU: Intel Arc B580, PCI Device ID E20B
• Driver: 32.0.101.8974
• OS: Windows 11, build 26100
• Python: 3.13.12
• PyTorch: 2.13.0+xpu
• oneAPI DPC++: 2026.1.0 Build 20260617
• Visual Studio Build Tools: 17.14.37
• llm-scaler: 3ac20587ed77b3e8adb100ca56fa0fbabb062db5
• ComfyUI-SolAttn_xpu: 5f1c4aac3ca32a00b0b4c15ddbb7cb53fa43344d
• SYCL-TLA: 2fc09973bfdf15755090fcb0e3b6ad236408a992

Isolated Windows build

I compiled these three sources into a Torch-loadable .pyd:

• cute_fmha_torch.cpp
• sol_attn_prepare.cpp
• sol_attn_torch.cpp

The build used the same BMG AOT and SPIR-V extension intent as the Linux CUTE branch:

• -fsycl-targets=spir64_gen
• backend target -device bmg
• SPV_INTEL_split_barrier
• SPV_INTEL_2d_block_io
• SPV_INTEL_subgroup_matrix_multiply_accumulate

Two build-only portability adjustments were needed:

1. Explicitly initialize the installed VS 2022 Build Tools before oneAPI.
2. In a private include overlay only, replace the host type alias ushort with equivalent standard C++ unsigned short in mma_xe_legacy_spirv.hpp.

The upstream checkouts were not modified. The resulting sidecar loads through torch.ops.load_library() and registers both prepare and forward_cute.

Built sidecar:

• Size: 1,588,736 bytes
• SHA-256: 4BE1F0F50B84CB1AFE8D6DAAF1D9B15051E2E1D04F9A75054C84E8323B363BA3

Minimal reproduction

prepare completes and synchronizes successfully. The failure occurs only after forward_cute.

import torch

torch.ops.load_library(r"<path-to-built-cute_fmha_torch.pyd>")
ops = torch.ops.omni_xpu_sol_attn

# Sanity check passes.
basic = torch.ones((64,), device="xpu", dtype=torch.float32)
torch.xpu.synchronize()
print(basic.sum().item())  # 64.0

shape = (1, 31, 1, 128)
q = torch.zeros(shape, device="xpu", dtype=torch.bfloat16)
k = torch.zeros_like(q)
v = torch.zeros_like(q)
scale = 128 ** -0.5

prepared = ops.prepare(q, k, v, float(scale), 1.0, 0, 0, 0, 0)
torch.xpu.synchronize()  # succeeds

print([tuple(t.shape) for t in prepared])
# [(1,1,1,128), (1,1,1,128), (1,1,1,128), (1,1,1), (1,1,1)]

output = ops.forward_cute(q, k, v, *prepared, float(scale))
torch.xpu.synchronize()  # DEVICE_LOST

Actual error:

RuntimeError: level_zero backend failed with error: 20
(UR_RESULT_ERROR_DEVICE_LOST)

An H3-style strided QKV view with shape [1, 129, 2, 128] fails in the same way.

After the test process exits, a new Python process can run ordinary XPU tensors normally, so the device recovers and the failure is isolated to the CUTE/DPAS forward launch.

Expected behavior

The minimal all-zero BF16 D128 input should complete and return a finite all-zero output, as in the upstream Sol-Attn correctness tests.

Questions

1. Is Windows BMG CUTE/Sol-Attn runtime support currently expected to work, or is Linux the only supported path at this commit?
2. Are different Windows compiler/linker/AOT flags required for the CUTE sidecar?
3. Could this be related to the 256-GRF launch property, Block2D/SPIR-V extensions, or the Windows Level Zero launch path?
4. If useful, I can provide the exact compile command and the isolated source overlay diff.

[gc-fu]

Hi, we will see what we can do about this~