TL;DR: If MiniMax H3 in Maestro / WanGP "finishes" a generation but the file is a tiny (~50 KB) solid-grey clip on an AMD GPU, open Advanced Settings → H3 Text Encoder and make sure it is GGUF Q4_K_M, not GGUF Q2_K. The 2-bit Q2_K encoder is unreliable for H3 on the ROCm-for-Windows build. Everything else I tried — TDR registry tweaks, reboots, resolution cuts, rolling Maestro back a version — was a dead end.
The setup
- GPU: Radeon RX 7900 XTX (RDNA 3, gfx1100), 24 GB VRAM
- RAM: 32 GB
- OS: Windows 11
- App: Maestro AMD (a Pinokio wrapper around Blizaine/Maestro, which is built on the WanGP pipeline), running the MiniMax H3 image-to-video model in its reference (
ref2va) mode with four reference images and the turbo LoRA.
H3 had worked for me for days. Then, one evening, every generation started coming out wrong.
The symptom
The job runs to completion. The console prints Task 1 completed, New video saved. But the saved MP4 is about 49 KB, and every frame is a flat, featureless grey — RGB(128, 128, 128). Video encoders compress a constant grey field down to almost nothing, which is why the file is so small.
Often, right as the progress bar reached the end, Windows would also throw:
AMD software detected that a driver timeout has occurred on your system.
Two clues turned out to matter a lot:
- It was deterministic. The same seed produced a byte-for-byte identical grey file every time.
- It survived everything. Rebooting didn't help. Neither did rolling the app back to the previous version.
The rabbit holes (so you can skip them)
I spent the better part of a night on wrong theories. In order:
1. "It's an fp8 NaN"
H3's transformer runs in fp8 on this build, and fp8 overflow producing NaN, decoded to grey by the VAE, is a plausible story. But there was no NaN in any log, and the failure was perfectly reproducible — NaN blow-ups from numerical edge cases usually aren't. Moved on.
2. "The Windows GPU watchdog is killing the decode"
Windows has a feature called TDR (Timeout Detection and Recovery) that resets the graphics driver if a single GPU operation doesn't return within ~2 seconds. That "driver timeout" popup is TDR firing. The standard fix is to raise the limit in the registry:
reg add "HKLM\SYSTEM\CurrentControlSet\Control\GraphicsDrivers" /v TdrDelay /t REG_DWORD /d 60 /f
reg add "HKLM\SYSTEM\CurrentControlSet\Control\GraphicsDrivers" /v TdrDdiDelay /t REG_DWORD /d 60 /f
I set both to 60 seconds and rebooted. Still grey. A single GPU op that overruns 60 seconds isn't a tuning problem — and the output was still deterministic, which a timeout-induced corruption shouldn't be.
3. "The Maestro update broke it"
The failures started shortly after an app update. That update's changelog said "reduce H3 memory overhead," and it had rewritten the exact file that appeared to be failing — the H3 video VAE. This looked like a slam dunk: five good generations before the update, almost nothing but grey after.
Maestro AMD has a one-click Roll back last update, so I used it, dropping back to the previous release. The logs confirmed the old code path was running.
Still grey. That killed the theory — and it was the most convincing one I had.
4. "A model file got corrupted"
Briefly I thought I'd found it: one of the encoder files had a modification timestamp that seemed to line up with the exact minute things broke. Then I checked it properly with stat and I'd simply misread the date — the file was the original download, untouched, and it had produced good videos earlier that same day.
Things that were real but not the cause
- RAM pressure. 32 GB is genuinely marginal for H3. The memory manager (mmgp) logged "full requirements 19,987 MB while estimated available reservable RAM is 13,021 MB" and ran permanently in a degraded, partial-pinning mode. During a failing decode, free RAM sat at 0.4 GB and the disk was thrashing. This made everything slower — but good runs had happened under the same pressure.
- The "VAE Tiling" setting. Maestro has a VAE Tiling dropdown (Auto / Full / Medium / Aggressive) that sounds exactly like what you'd want here. On H3 it does nothing — H3's VAE has its own tiling baked in at a fixed size and ignores that setting. It only affects Wan, LTX, and Hunyuan.
What actually fixed it
The whole time, I was running the GGUF Q2_K text encoder — a 2-bit quantization of the 32B Qwen3-VL encoder H3 uses. I'd picked it earlier to save RAM. The wrapper's own default and documentation point to GGUF Q4_K_M and note Q2_K is only a low-RAM fallback.
I switched Advanced Settings → H3 Text Encoder → GGUF Q4_K_M, kept the same seed and resolution that had been producing grey, and hit generate.
A real 9.1 MB video, first try.
Why the symptoms were so misleading
Once you know it's the encoder, the whole picture makes sense:
| What I saw | Why |
|---|---|
| Same seed → byte-identical grey file | The encoder deterministically produces broken embeddings — garbage in, garbage out. Not a race, not a timeout. |
| Survived reboots and the app rollback | The encoder choice is a saved setting; the file on disk never changed. Rollback only touches app code, not models or settings. |
| Dropping resolution / frame count did nothing | If the conditioning signal is nonsense, the output is nonsense at any size. |
| The "driver timeout" popup | A secondary effect. With almost no free RAM, the (already doomed) final decode crawled for 8-9 minutes — long enough for Windows' watchdog to reset the GPU. The reset didn't cause the grey; the grey was baked in upstream. |
The mechanism: a broken text encoder feeds the diffusion transformer meaningless conditioning → the transformer settles on a near-constant latent → the VAE faithfully decodes that constant to a flat grey frame → you get a 49 KB video and a "success" message.
Takeaways
If you're on AMD and H3 gives you flat-grey output:
- Switch the H3 Text Encoder to GGUF Q4_K_M first, before touching anything els)e. Q2_K is not worth the grief on ROCm.
- A byte-identical grey file across seeds means bad input — a model file or an encoder — not a driver or timing problem. Different noise per seed would point the other way.
- The "AMD driver timeout" popup is usually a symptom, not the disease. Chase the output first. (And the "Don't ask me again" checkbox in that dialog only hides the message — it doesn't stop the GPU reset.)
- 32 GB RAM is the practical floor for H3 at real video lengths, and you'll be at the edge of it. Reboot before big jobs, keep the Director LLM on CPU, close your browser, and start small.
- The VAE Tiling dropdown does nothing for H3 — don't waste time on it.
Days lost, and the fix was one dropdown. Hopefully this saves someone else the night.
Written by cekli.com