Skip to content

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

Description

@MyNameIsZRN

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

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 Create readme.md #2 and Can neo be built on Windows? #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

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    OS: LinuxIssue specific to Linux distributions (Ubuntu, Fedora, RHEL, etc.)Status: Needs FeedbackWaiting for additional information from reporterType: BugGeneral bug report, unexpected behavior or crash

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions