Windows Arc B580/G21: native CUTE attention forward hangs after PR #659

[yzwzhanghao2]

Summary

After PR #659 was merged, the Windows Torch 2.13 CUTE sidecar builds and imports successfully for an Arc B580/G21 target, but every tested native CUTE attention forward hangs in a CPU busy wait. The equivalent PyTorch SDPA controls complete with finite output.

This issue tracks the unresolved G21/B580 runtime problem from my earlier PR comment:
#659 (comment)

Environment

• GPU: Intel Arc B580 (G21), PCI ID 0xE20B, intel_gpu_bmg_g21
• Driver: 32.0.101.8974
• OS: Windows
• Python: 3.13.12
• PyTorch: 2.13.0+xpu (torch.version.xpu == 20260000)
• oneAPI compiler/ocloc: 2026.1
• oneDNN: 3.11.2
• sycl-tla: 2fc09973bfdf15755090fcb0e3b6ad236408a992
• PR Omni: add Windows Torch 2.13 CUTE and SolAttn #659 head tested: affc2ea6
• Built wheel: omni_xpu_kernel 0.2.0b2+torch213.bmg
• Wheel SHA256: 4E35336F68E15FCCFB13A90B4F1FBFD9975DA6C946F9969A485F17994B7F68EE

Build detail

PR #659 hard-codes the Windows CUTE AOT target to bmg-g31. I made one isolated build-only change allowing WINDOWS_CUTE_AOT_TARGETS["bmg"] to be overridden and built with bmg-g21.

The resulting wheel imports successfully, and all of these report True:

• cute.is_available()
• supports_d128_bhld()
• supports_minimax_h3_vae_d64()
• supports_sol_attn()

Reproduction results

PyTorch SDPA controls complete normally and return finite output. Native CUTE forward hangs for all tested layouts:

1. MiniMax H3 QKV-backed BF16, shape [1, 56, 31, 128], Q/K stride [7168, 128, 21504, 1]: first attempt exceeded 124 seconds; repeat exceeded 34 seconds.
2. Dense BF16 BHLD [1, 4, 31, 128]: exceeded 34 seconds.
3. Legacy FP16 BLHD [1, 256, 8, 128]: exceeded 34 seconds.

Observed behavior:

• CPU busy wait; no Python exception and no explicit DEVICE_LOST.
• Process uses about 1.4 GiB RAM and must be terminated.
• Fresh Torch XPU device/matmul health checks pass after every terminated probe.
• I stopped before running Sol-Attn forward or the real H3 [1, 56, 7461, 128] gate.

Device policy observation

omni_xpu_kernel.device.info(0) reports:

• bmg_sku=unknown
• kernel_profile=generic-bmg

The documentation describes generic BMG as the B70-compatible default. SYCL reports 5 slices x 4 subslices, and ocloc ids bmg-g21 maps to 20.1.0, so the scheduler-unit query is nonzero and the device image target appears consistent.

Expected behavior

Either:

• the G21/B580 native CUTE forward completes and matches the finite PyTorch SDPA result, or
• the runtime rejects unsupported G21 hardware cleanly instead of advertising the capability and hanging.

Questions

1. Is the Windows CUTE path expected to support G21/B580, or currently only G31/B70?
2. Should PCI ID 0xE20B be classified with a G21/B60 policy rather than generic-bmg?
3. Is oneAPI 2026.0 required, or should 2026.1 work?
4. Is there a known-good small forward probe or G21 tile/policy override I should test?

I can provide the standalone minimal reproducer and test a targeted patch on the physical B580.