Wan2.2 T2V A14B: diagonal weave/cross-hatch artifact on Apple M5 Max (mlx 0.32.0); --no-compile changes it to dead gray regions

[hkaynarch-code]

Summary

On an Apple M5 Max (48 GB, macOS 26.5.2), Wan2.2-T2V-A14B generation produces a regular diagonal cross-hatch / weave over the frame, most visible in smooth regions (sky, mist, water). It reproduces on the README's own example command, whose reference output (examples/poodles-wan.gif) is clean, so it looks environment/hardware specific rather than a usage error.

Repro (your exact README Lightning command)

python -m mlx_video.models.wan_2.generate \
  --model-dir <Wan2.2-T2V-A14B-MLX> \
  --width 480 --height 704 --num-frames 41 \
  --prompt "Two dogs of the poodle breed sitting on a beach wearing sunglasses, nodding with their heads, close up, cinematic, sunset" \
  --steps 4 --guide-scale 1 --trim-first-frames 1 --seed 2391784614 \
  --lora-high .../Wan2.2-T2V-A14B-4steps-lora-rank64-Seko-V2.0/high_noise_model.safetensors 1 \
  --lora-low  .../Wan2.2-T2V-A14B-4steps-lora-rank64-Seko-V2.0/low_noise_model.safetensors 1

Expected: clean like poodles-wan.gif. Actual on M5 Max: full-frame diagonal weave.

What I have already isolated

• Not quantization: a bf16 conversion and an 8-bit conversion give the identical weave at the same seed.
• Not prompt/seed/settings: the weave reproduces on your exact command + seed above.
• It is the compiled Metal path: adding --no-compile removes the weave (lower part of the frame renders cleanly) but leaves the upper ~60% of every frame as flat gray (dead region). So both compiled and non-compiled paths are numerically wrong here.

Environment

• Hardware: Apple M5 Max, 48 GB unified, macOS 26.5.2 (25F84)
• mlx 0.32.0, mlx-metal 0.32.0, mlx-video 0.0.1 (git main, installed 2026-07-21)
• Weights converted locally from official Wan-AI/Wan2.2-T2V-A14B via mlx_video.models.wan_2.convert (bf16 and 8-bit, both affected)

Question

Is the M5 Max known to work, and if so, which mlx version produced the clean poodles-wan.gif? I suspect an mlx 0.32.0 Metal-kernel regression (or missing M5 support). Happy to run any diagnostic (specific mlx version, --debug-latents, a single op check) to help narrow it down.

[hkaynarch-code]

Possibly related to #40 (quantized A14B producing fully black videos, with bf16 reported unaffected). This report differs in two ways that may point to a hardware/Metal dimension rather than quantization alone:

1. The corruption here is a diagonal weave/cross-hatch, not black frames.
2. It affects bf16 and 8-bit identically on the M5 Max (so not quantization-specific here).

If #40's black-video failure also turns out to be M-series / mlx-version specific, the two may share a root cause in the compiled Metal path, on M5 here, --no-compile flips the weave into flat gray dead regions instead of fixing it.