[GSD-13007] [Bug] SDXL consistently crashes on Arc B580 (BMG G21) — drm_neo.cpp:283 Abort / SIGSEGV

## Description

Running SDXL (2.6B parameter UNet) Stable Diffusion on Intel Arc B580 (Battlemage) via ComfyUI consistently crashes across 4 different VRAM management configurations. The crash manifests in 3 distinct error patterns:

1. **`Abort at drm_neo.cpp:283`** (most common) — kernel driver detects GPU context corruption
2. **`SIGSEGV`** in `_calc_cond_batch_outer` — segfault inside XPU backend during UNet forward pass
3. **`UR_RESULT_ERROR_OUT_OF_RESOURCES` (error 40)** — Level Zero resource exhaustion

**SD1.5 (0.86B UNet) works reliably in all configurations.** The crash is specific to large UNets (~2.6B params), pointing to a driver/JIT bug in handling large compute graphs or large kernel submissions on Battlemage.

After any of these crashes, the GPU enters a **zombie state** where all user-space access fails (PyTorch: `XPU device count is zero`, OpenCL: `CL_PLATFORM_NOT_FOUND_KHR`) but the PCI device and `/dev/dri/renderD128` still appear present. **Only a full reboot recovers the GPU.**

## System Information

| Item | Value |
|------|-------|
| **OS** | Ubuntu 26.04 LTS |
| **Kernel** | Linux 7.0.0-27-generic |
| **GPU** | Intel Arc B580 (BMG G21), PCI ID `8086:e20b`, 12GB VRAM |
| **ReBAR** | 16GB |
| **compute-runtime** | `libze-intel-gpu1` 26.05.37020.3-1 |
| **Level Zero loader** | `libze1` 1.28.2-2 |
| **Legacy runtime** | `libze-intel-gpu-legacy1-1` 24.35.30872.45-1 |
| **linux-firmware** | `linux-firmware-intel-graphics` 20260319.git217ca6e4-0ubuntu2 |
| **PyTorch** | 2.12.1+xpu (no IPEX — using native `torch.xpu`) |
| **torchvision** | 0.27.1+xpu |
| **ComfyUI** | commit `77917ed` (latest master, 2026-07-04) |
| **Python** | 3.11.15 (conda env) |

## Environment Variables

```bash
export UR_L0_ENABLE_RELAXED_ALLOCATION_LIMITS=1
export SYCL_CACHE_PERSISTENT=1
export SYCL_CACHE_DIR="$HOME/.cache/sycl"
```

## Steps to Reproduce

1. Install ComfyUI with PyTorch 2.12.1+xpu on a machine with Intel Arc B580
2. Use an SDXL checkpoint (tested with `semiRealIllustrious_v30.safetensors`, 6.94GB)
3. Launch ComfyUI with: `--bf16-unet --fp32-vae --use-pytorch-cross-attention --lowvram`
4. Run a generation at 1024×1024, euler/normal, 20 steps, CFG 7.0
5. Crashes during sampling or VAE decode (varies by config — see matrix below)

## Crash Test Matrix

All tests use the same model (`semiRealIllustrious_v30`, SDXL, 6.94GB), workflow (1024×1024, euler/normal, 20 steps, CFG 7.0, seed 42, no LoRA):

| # | Launch parameters | Crash stage | Error |
|---|-------------------|-------------|-------|
| 1 | `--reserve-vram 3 --enable-dynamic-vram --bf16-vae` | During sampling | `drm_neo.cpp:283` Abort |
| 2 | `--enable-dynamic-vram --bf16-vae` (removed reserve-vram) | VAE decode | `drm_neo.cpp:283` Abort |
| 3 | `--lowvram --bf16-vae` | VAE decode | `drm_neo.cpp:283` Abort |
| 4 | `--lowvram --fp32-vae` | During sampling (`_calc_cond_batch_outer`) | `SIGSEGV` (segfault) |

**SD1.5** (`dreamshaper_8.safetensors`, 2.13GB, 0.86B UNet, 512×768) works reliably across ALL configurations — ~3.5GB VRAM peak, ~30s per generation, zero crashes.

## Key Observations

1. **Not an OOM issue**: The crashes occur even with `--lowvram` (CLIP offloaded after encode) and `--fp32-vae`. VRAM peak is ~9-10GB vs 12GB physical. The total VRAM reported by PyTorch is 11.33GB (not 12GB), and Level Zero has additional ~1.5GB hidden allocations invisible to PyTorch.

2. **Model-size-dependent**: SD1.5 (0.86B params) always works. SDXL (2.6B params) always crashes. The threshold for crash is somewhere between these.

3. **Configuration-dependent crash location**: The crash moves between sampling phase and VAE decode phase depending on parameter configuration, suggesting multiple fragile code paths rather than a single bug.

4. **BF16 VAE is deterministically broken on B580**: Tests #2 and #3 both crash at VAE decode when using `--bf16-vae`. FP16 VAE produces black images (known: Xe doesn't support native FP16). Only `--fp32-vae` avoids the VAE crash, but then the UNet sampling phase crashes instead.

5. **compute-runtime 8509 regression**: We are aware of existing reports of 8509-series regressions causing ComfyUI crashes. Our version (26.05.37020.3) appears to be affected.

6. **Zombie GPU state**: After any crash, the GPU is unrecoverable without reboot — `torch.xpu.is_available()` returns `False`, `clinfo` shows 0 platforms, but PCI device still visible. This suggests kernel driver state corruption.

## VRAM Budget (for reference)

SDXL parameter counts verified by scanning safetensors headers:

| Component | Parameters | BF16 Size |
|-----------|-----------|-----------|
| UNET (`model.diffusion_model`) | 2,567,090,691 | 4.78 GB |
| CLIP-G + CLIP-L | 817,847,299 | 1.52 GB |
| VAE | 83,836,611 | 0.16 GB |
| Activations (1024×1024) | N/A | ~2.5-3 GB |
| PyTorch allocator overhead | N/A | ~0.5-1 GB |
| **Total peak** | | **~9-10 GB** |

## Related Reports

- ComfyUI Discussion #476: Multiple Arc users reporting OOM → Bus Error → UI crash pattern
- Intel IPEX Issue #781: UR error during ComfyUI SD tutorial
- openSUSE forum: B580 ComfyUI/PyTorch crashes, suspected kernel/firmware bug

## Request

Can the Intel GPU driver team investigate Battlemage (BMG G21) stability with large (>2B parameter) UNet models? The `drm_neo.cpp:283 Abort` may be a Battlemage-specific bug that hasn't been reported before. We're happy to provide additional logs or run diagnostic tests.

Start by reproducing the SDXL failure with the provided ComfyUI, PyTorch XPU, and Arc B580 configuration, then inspect the crash around drm_neo.cpp:283 and the reported _calc_cond_batch_outer path. Compare the failing SDXL runs with the working SD1.5 case and collect driver or Level Zero diagnostics; done means identifying and fixing the large-UNet Battlemage stability failure or documenting a confirmed upstream dependency.

Written by the indexing model from the issue text.