[omni_xpu_kernel] Test Report: 0.2.0b1 + comfy-kitchen XPU fork 0.2.28 on Windows (torch 2.13 / oneAPI 2026.1 / Arc B580)

### 1. Test Environment

| Component | Version |
|---|---|
| OS | Windows 11 Pro x64 |
| GPU | Intel Arc B580 (BMG, `intel_gpu_bmg_g31`) |
| Python | 3.13.x (ComfyUI Aki portable embed) |
| PyTorch | **2.13.0+xpu** |
| oneAPI | 2026.1 (icx 2026.1.0) |
| oneDNN | 3.11.2 (dnnl 2026.0) |
| omni_xpu_kernel | **0.2.0b1+torch213.bmg** (locally built) |
| comfy-kitchen | 0.2.28 XPU fork @ `575741da` (locally built) |
| ComfyUI | 0.31.1 |
| ComfyUI-OmniXPU | latest (adapters/ structure, llm-scaler main) |
| ComfyUI-GGUF-XPU | `39671fe7` (official pin) |
| ComfyUI-nunchaku-XPU | `5cf4fa98` (deployed, 16 nodes registered) |
| comfy-aimdo | 0.4.13 XPU (**not enabled** during this report, see §7) |

### 2. Kernel — Windows: recommended build vs. actual build

**Official path (WINDOWS_PORTABLE.md)**: torch 2.12.0+xpu + oneAPI 2025.3.3 + oneDNN 3.9.1 (dnnl 2025.3), dedicated venv, `pip wheel --no-build-isolation`, artifact `omni_xpu_kernel-0.2.0b1+torch212.bmg`.

**Actual build (this report)**: torch 2.13.0+xpu + oneAPI 2026.1 + oneDNN **3.11.2** (dnnl 2026.0), using the ComfyUI embed Python directly (`pip wheel --no-build-isolation`). Artifact `omni_xpu_kernel-0.2.0b1+torch213.bmg` (25,111,707 B).

Notes / pitfalls hit:
- dnnl 2025.3's `dnnl.dll` depends on `sycl8.dll`, which oneAPI 2026.1 no longer ships (only `sycl9`) — using the matched 2026-series oneDNN (3.11.2) avoids the mismatch entirely.
- PATH ordering is critical: a `compiler/2025.3/bin` entry placed *before* `2026.1/bin` silently switches `icx` to 2025.3 and fails compiling torch 2.13 headers (exit 1104).
- Kernel smoke (RMSNorm fp16 + ESIMD SDP head_dim=128) passes against fp32 references.

### 3. Kitchen — Windows: recommended build vs. actual build

**Official path**: clone `xiangyuT/comfy-kitchen-xpu`, build combined wheel, install, deploy custom node.

**Actual build (this report)**: clone @ `575741da` (README/main mirror pin, matching our kernel/OmniXPU lineage), `pip wheel --no-deps` (pure-Python, no compiler needed). All 16 direct dependencies already present in the environment → **zero pip mutation** (torch/torchvision untouched, avoiding the known `facexlib → torchvision → torch CPU` trap).

Validation: `list_backends()["xpu"] = {available: True, disabled: False, capabilities: 39}`; `triton` unavailable on Windows (expected, `COMFY_KITCHEN_ENABLE_TRITON_WINDOWS` opt-in).

### 4. Launch environment (bat)

```bat
:: OmniXPU
set OMNIXPU_ENABLE=1
set OMNI_ATTN_BACKEND=torch
set OMNI_XPU_REQUIRE_CUTE=0

:: ComfyUI launch (Aki portable)
python main.py --lowvram --reserve-vram 1.0 --preview-method none --use-pytorch-cross-attention
```

Notes:
- `OMNI_ATTN_BACKEND=torch`: Windows default (no CUTE); ESIMD sidecar available but not enabled by default.
- `--lowvram` is currently kept as a fallback for large-model workflows (see §7 — AIMDO not enabled). No `OMNI_COMFYUI_RESERVE_VRAM_GB` needed since `--reserve-vram 0.5` is used directly.

### 5. Model test summary

All routes below are confirmed via either same-process A/B comparison or `OMNIXPU_DEBUG=1` kernel traces.

| Workflow | Path taken (verified) | Evidence | Perf |
|---|---|---|---|
| Krea2 GGUF Q4_0 (`UnetLoaderGGUF`) | kitchen xpu dequant → `omni_xpu_kernel.gguf` | same-process A/B | **+32%** (2.71 vs 4.00 s/it, no LoRA) |
| Flux2 Klein FP8 | OmniXPU fp8 adapter → kernel `fp8_gemm` | `fp8_gemm first use` | 3.16 s/it |
| kr2fp_wa4 INT4 (WA4 node) | kernel direct `svdq` oneDNN INT4 GEMM + norm | `onednn_int4_gemm` JIT | 3.84–6.27 s/it (steady) |
| QwenImage 2512 (GGUF Q2_K) | OmniXPU norm adapter → ESIMD `rms_norm`/`layer_norm` | debug: `op=rms_norm/layer_norm backend=esimd` | ~6–7 s/it |
| **Lumina2 (Z-Image-Turbo INT8 ConvRot workflow)** | **norm (ESIMD) + `int8_swiglu_mlp` → omni_xpu fused kernel** (lumina.FeedForward, ConvRot INT8 weights) | debug: `op=int8_swiglu_mlp backend=omni_xpu module=lumina.FeedForward route=shared_up+fused_swiglu+convrot+quant+prequant_down` + `op=rms_norm/layer_norm backend=esimd` | **1.23 it/s (fastest so far, incl. debug overhead)** |
| SDXL fp16 | not routed (no Omni hit) | — | no negative impact |

Debug tooling used: `OMNIXPU_DEBUG=1` (patches/debug.py) prints per-call kernel trace (`stage=kernel op=... backend=esimd/omni_xpu tensor=...`); OmniXPUStatus node `fused/fallback` counters are more reliable than first-use log lines.

### 6. Local modifications to upstream main (test environment)

The tested kernel was built from upstream `intel/llm-scaler` main **plus three local commits applied only in the test environment's local clone (not pushed)**:

| Commit | Change | Why |
|---|---|---|
| `22b3503` | `bindings.cpp`: re-add the Windows oneDNN linker `/alternatename` pragmas | The #593 refactor dropped this fix; without it the Windows link fails (LNK2019 on `dnnl_primitive_attr_set_scales_v3` / `dnnl_primitive_attr_set_zero_points_v2`) |
| `9018970` | `_version.py`: add `"2.13"` to the supported torch-minors whitelist | Upstream whitelists 2.10–2.12; building against torch 2.13 is rejected otherwise (corresponds to the torch213 stage in WHL_BUILD_INSTALL.md §10) |
| `28f0853` | `setup.py`: `VALIDATED_ONEDNN_VERSION` `(3,9,1)` → `(3,11,2)` | Upstream validates dnnl 2025.3 (oneDNN 3.9.1); this environment uses dnnl 2026.0 (oneDNN 3.11.2), which otherwise fails the version check |

### 7. Notes / Known gaps

- **MiniMax H3 acceptance workflow NOT tested yet.** With AIMDO XPU disabled ([issue #3](https://github.com/xiangyuT/comfy-aimdo-xpu/issues/3): PR#4 introduced unbounded VRAM growth / no eviction → step-1 hang), large near-VRAM-capacity workloads currently fall back to `--lowvram` paging, which masks kernel gains. Will re-run the H3 acceptance once AIMDO XPU is fixed and re-validated (including local PR#4 `323c0e0` verification).

- Windows limitation: no CUTE FMHA; attention stays on PyTorch SDPA (validated head_dim 64/128 FP16/BF16).

---

Compared with the previous kernel release (0.1.0b8.dev0), which required per-workload toggles (e.g. OMNIXPU_ENABLE=0 for certain INT4 models), the current 0.2.0b1 + comfy-kitchen XPU fork stack works with one single environment configuration (OMNIXPU_ENABLE=1, OMNI_ATTN_BACKEND=torch, OMNI_XPU_REQUIRE_CUTE=0) across the vast majority of the workflows we tested — GGUF, FP8, INT4 (WA4) and norm-heavy architectures all route correctly without any per-model switches.

Thanks to the authors for the excellent work: the Windows build path (build-windows-xpu.cmd, ze_loader.def), the oneDNN version validation, the XPU fork of Comfy Kitchen, and the indexless tensor device fix ([#2](https://github.com/xiangyuT/comfy-aimdo-xpu/pull/2)). The whole stack is now genuinely usable on Windows with torch 2.13.

Start by reading WINDOWS_PORTABLE.md and WHL_BUILD_INSTALL.md §10, then compare the reported torch 2.13 and oneDNN 3.11.2 build with the documented commands and local commits. Reproduce the Windows build and kernel smoke checks, then document any required upstream changes and the remaining AIMDO/H3 acceptance gap.

Written by the indexing model from the issue text.