Graphics device lost during deep interactive zoom (open; crash reports wanted)

[WindySnowOwl]

Status: known open problem, maintainer-filed to track it and collect field reports. If your graphics device is lost during a deep zoom, the crash report from your machine is the single most useful thing you can send — please attach it here.

What happens

The graphics device is lost during an ordinary interactive deep zoom, and the app either restarts its renderer or exits. It is uncommon and not tied to one vendor: it has been reproduced on an AMD RX 6800 XT and, once, on an RTX 3080 on stock settings during a normal zoom.

Why it is still open

At deep interior views the time a frame takes is not predictable from how much work it nominally asks for. The clearest capture we have is a frame that was doing about a twenty-fourth of the work its budget allowed and still took 1216 ms — right on the driver's ~1 second watchdog — while a frame a minute earlier did thirty-four times more nominal work in less time. A controller that prices work by iteration count therefore cannot see the dangerous frame coming.

A run of fixes has made this much rarer:

• long computations are split along the iteration axis so no single piece runs unbounded;
• a size allowance earned on a cheap region is discarded the moment a frame comes within ~2× of the watchdog;
• the region bookkeeping is indexed in octaves, so its resolution no longer degrades exactly where losses happen;
• the smallest piece of work issued is derived from the worst speed actually measured, not a constant.

What none of that does is recall a dispatch already in flight, which is what actually kills the device. Bounding that means never issuing a dangerous piece in the first place, and predicting which piece is dangerous from a nominal count is the thing measured to be impossible above. So this is a well-instrumented open problem, not a solved one.

How you can help

• If it happens to you, attach the crash report. It is written automatically to the config directory's logs/ folder and is meant to be readable. It records the render size, the series-approximation skip, and the in-flight state — exactly what is needed and what cannot be reproduced on the maintainer's hardware.
• A deliberate reproduction is worth even more than analysis of the existing capture. The signature is a zoom that repeatedly returns toward home at depth. fractadyne --autodive N --autodive-home 3 (with N ≥ 32) drives that path headlessly.
• If you have written a deep-zoom renderer and bound a single GPU dispatch against the driver watchdog, how you decide the size of one submission is genuinely wanted — see the announcement thread.

For maintainers

Tracked in TODO.md under "FIELD DEVICE LOSS 2026-08-22"; leads closed in v0.2.40-beta.139–142. Crash-manifest stamps for res=, sa_skip and in-flight state landed in beta.135/138/141, so a capture from a current build carries more than the 2026-08-22 one did.

[WindySnowOwl]

New field capture — RTX 3080, current build (v0.2.41-beta.88), and this time with a repeatable trigger.

Trigger: a deep interior minibrot (period ~3992, ~1.8e16×) with Iterations (base) set to its 10,000,000 maximum. Pressing "find minibrot" (M) during a zoom jumped onto the minibrot's own scale, and the device was lost about ten seconds later. So the earlier "once, on stock settings" 3080 loss now has a concrete companion: max iteration base at a deep interior view.

What the capture shows (all from the auto-written crash report + log):

• Because the view is interior, the reference orbit never escapes — it grew to ~7.45 million samples, and building that reference alone hung the app for 100–160 seconds at a stretch.
• A single in-flight GPU pass accumulated ~44 seconds in the lethal band before the size-shedding throttle kicked in and collapsed it to the floor window (256 iterations).
• The device was lost anyway, after the throttle had already shed to the floor. That's the interesting part: at a giant-reference interior view the dominant cost may be the per-pixel access into the reference buffer, which shrinking the iteration window (what the throttle does) doesn't reduce.

Shipped in response (v0.2.41-beta.89): a crash-loop guard — separate from the loss itself. The auto-restart had been restoring the exact crashing view and re-crashing on it (each relaunch spent ~30 s rebuilding that same enormous reference before dying again). Now a relaunch after a device loss opens at the home view — the rest of the session is restored, just not the location that was too demanding to render — and it will not auto-restart a third time after two crashes in a row.

Still open: the loss itself. The clearest next lever from this capture is a guard-rail that warns or soft-caps the iteration base when the reference is partial and enormous (an interior view whose orbit fills the buffer without escaping), independent of the frame-cost throttle work already done.