Transient visual glitches after long play: texture corruption on ground/deck, fog gust flicker, one-frame green flash on autosave (NVIDIA) #386

Closed
opened 2026-11-07 23:20:04 +00:00 by Bronnzy · 4 comments
Bronnzy commented 2026-11-07 23:20:04 +00:00 (Migrated from github.com)

Builder version

foliage-linux-updater (source build of ba594da)

How you built

From source (see #384 for the pipeline)

Game files given to it

A .nup (build e0f3ccfa)

The error

Three transient visual glitches observed in one long session (~180k presents across two runs, RTX 5070 Ti, no crash):

1. Texture corruption on large ground/deck surfaces (~present 50000, exiting the Great Deku Tree area). Deck planks and ground textures broke into wrong/garbled content, then recovered after an area change. The log shows the live texture count spiking to its session peak (1740 textures, 3972 MB) right around the corruption, and 5-9 textures made per frame for a stretch — consistent with a texture being re-created/re-bound wrong rather than a lost allocation. No errors logged.

2. Fog gust flicker (Lost Woods → Deku Tree approach). The volumetric fog alternates between fully present and absent frame-to-frame. Log context: sustained 62-68 MB/frame mirror write-back in that area, occasional upload bursts (8.3 uploads / 3 MB in a frame). Same family as #303, #320.

3. One-frame green flash on autosave. A full-screen green tint for a single frame whenever the game autosaves. Log shows nothing anomalous in that window (no DEVICE_LOST, no skipped-frame burst, no upload spike) — likely the swapchain/present path briefly showing a wrong-format or partially-updated image. Fits the "exposure flashes" family of #296 and the green flicker of #342 (whose swscaler crash is a different, movie-decoder failure).

All three are transient and the session continued normally after each. Frame dumps for the texture-corruption window are reproducible on request (same save, same area).

Visual Studio or Build Tools version, and Windows SDK version

MSVC 14.44, SDK 10.0.26100

Operating system and free space on the output drive

Windows 11, ~60 GB free

Confirmations

  • On the newest release, and it still fails there.
  • Open issues searched before filing.
  • No game files or anything built from them is attached.
### Builder version foliage-linux-updater (source build of `ba594da`) ### How you built From source (see #384 for the pipeline) ### Game files given to it A .nup (build `e0f3ccfa`) ### The error Three transient visual glitches observed in one long session (~180k presents across two runs, RTX 5070 Ti, no crash): **1. Texture corruption on large ground/deck surfaces (~present 50000, exiting the Great Deku Tree area).** Deck planks and ground textures broke into wrong/garbled content, then recovered after an area change. The log shows the live texture count spiking to its session peak (1740 textures, 3972 MB) right around the corruption, and 5-9 textures made per frame for a stretch — consistent with a texture being re-created/re-bound wrong rather than a lost allocation. No errors logged. **2. Fog gust flicker (Lost Woods → Deku Tree approach).** The volumetric fog alternates between fully present and absent frame-to-frame. Log context: sustained 62-68 MB/frame mirror write-back in that area, occasional upload bursts (8.3 uploads / 3 MB in a frame). Same family as #303, #320. **3. One-frame green flash on autosave.** A full-screen green tint for a single frame whenever the game autosaves. Log shows nothing anomalous in that window (no DEVICE_LOST, no skipped-frame burst, no upload spike) — likely the swapchain/present path briefly showing a wrong-format or partially-updated image. Fits the "exposure flashes" family of #296 and the green flicker of #342 (whose swscaler crash is a different, movie-decoder failure). All three are transient and the session continued normally after each. Frame dumps for the texture-corruption window are reproducible on request (same save, same area). ### Visual Studio or Build Tools version, and Windows SDK version MSVC 14.44, SDK 10.0.26100 ### Operating system and free space on the output drive Windows 11, ~60 GB free ### Confirmations - On the newest release, and it still fails there. - Open issues searched before filing. - No game files or anything built from them is attached.
NotRexed commented 2026-11-08 02:44:30 +00:00 (Migrated from github.com)

Thanks for the log: the corruption starts right when the texture count peaks (~1740 textures, ~4 GB), which is when the renderer starts evicting textures to stay in budget. The new releases change that (#341: only textures unused for 60 frames are evicted, it was 8, and evicted render targets no longer come back empty), and the device-lost fix is in too. Please rebuild with https://github.com/NotRexed/Hookshot/releases/tag/device-lost-fix and tell me if the corrupted textures or the green flash at autosave still appear after a long session (with hookshot_log.txt if they do).

Thanks for the log: the corruption starts right when the texture count peaks (~1740 textures, ~4 GB), which is when the renderer starts evicting textures to stay in budget. The new releases change that (#341: only textures unused for 60 frames are evicted, it was 8, and evicted render targets no longer come back empty), and the device-lost fix is in too. Please rebuild with https://github.com/NotRexed/Hookshot/releases/tag/device-lost-fix and tell me if the corrupted textures or the green flash at autosave still appear after a long session (with hookshot_log.txt if they do).
Bronnzy commented 2026-11-08 06:26:38 +00:00 (Migrated from github.com)

Rebuilt from current main (46ea554, includes the eviction change and the device-lost fix) and retested with a long session. Results so far:

Texture corruption: appears fixed. The old build corrupted ground/deck textures right when the texture count peaked (~1740 textures). The new session went far past that point — the live texture count reached 3036 textures (5326 MB) at peak, and 1793–2708 while re-crossing the same areas — with no corruption visible, no skipped draws, and no DEVICE_LOST, across ~62,000 presents. That includes the exact area and action where the old build broke (exiting the Great Deku Tree after the boss). The eviction threshold change looks like the right fix.

Green flash on autosave: not reproduced yet. No autosave coincided with a flash so far; the only present-side anomalies are a few slow present: 15-16.5 ms events that line up with scene loads, not saves. Will keep watching; will confirm either way after the next longer stretch.

Fog gust flicker: still present, and that is expected — your design notes list the fog cause as open (docs/design.md: "Fog's cause is open"), with the fog running on the visual workaround. On NVIDIA the flicker shows the same way as reported: the fog volume alternates dense/absent frame-to-frame in the Lost Woods and Deku Tree areas. Filing detail if useful: it happens in areas where the fog's mirror write-back runs ~55-68 MB/frame sustained, but upload activity itself is quiet (~0.07 uploads/frame), so it looks like a state/read-back ordering issue in the fog integration rather than a texture-upload problem. Happy to split this into its own issue if you prefer.

Session stats for reference: mean ~59 fps since boot, dips <40 fps only twice (one pipeline-creation burst of +79 pipelines at the Deku Tree exit cutscene, one scene load), 0 shader translation failures (the old build had 105 permanent ones).

Thanks for the quick turnaround on the eviction change.

Rebuilt from current `main` (46ea554, includes the eviction change and the device-lost fix) and retested with a long session. Results so far: **Texture corruption: appears fixed.** The old build corrupted ground/deck textures right when the texture count peaked (~1740 textures). The new session went far past that point — the live texture count reached 3036 textures (5326 MB) at peak, and 1793–2708 while re-crossing the same areas — with no corruption visible, no skipped draws, and no DEVICE_LOST, across ~62,000 presents. That includes the exact area and action where the old build broke (exiting the Great Deku Tree after the boss). The eviction threshold change looks like the right fix. **Green flash on autosave: not reproduced yet.** No autosave coincided with a flash so far; the only present-side anomalies are a few `slow present: 15-16.5 ms` events that line up with scene loads, not saves. Will keep watching; will confirm either way after the next longer stretch. **Fog gust flicker: still present, and that is expected** — your design notes list the fog cause as open (`docs/design.md`: "Fog's cause is open"), with the fog running on the visual workaround. On NVIDIA the flicker shows the same way as reported: the fog volume alternates dense/absent frame-to-frame in the Lost Woods and Deku Tree areas. Filing detail if useful: it happens in areas where the fog's mirror write-back runs ~55-68 MB/frame sustained, but upload activity itself is quiet (~0.07 uploads/frame), so it looks like a state/read-back ordering issue in the fog integration rather than a texture-upload problem. Happy to split this into its own issue if you prefer. Session stats for reference: mean ~59 fps since boot, dips <40 fps only twice (one pipeline-creation burst of +79 pipelines at the Deku Tree exit cutscene, one scene load), 0 shader translation failures (the old build had 105 permanent ones). Thanks for the quick turnaround on the eviction change.
Bronnzy commented 2026-11-08 07:03:35 +00:00 (Migrated from github.com)

Correction to my comment above: the texture corruption is not fixed. It came back on Hyrule Field — my earlier verdict only covered up to the Deku Tree exit.

What changed my read: three transient corruption forms, all tied to budget-pressure eviction, all captured in one continuous session (108,000+ presents):

  1. Deku Tree bridge (~present 72000): wooden planks render as a dark tiled pattern — same class as the original report's deck planks.
  2. Hyrule Field dirt path (~105000): dark cross-stitch garbage in some frames, recovering to correct a few seconds later (two captures of the same spot show the recovery).
  3. Hyrule Field grass slope (~107400): a flat dark quadrilateral where a terrain chunk should be — a GPU-rendered texture evicted and coming back empty.

Log context (the budget is the story):

  • textures 6094 MB of budget 6144 MB (99.2% full), VRAM 12.1 GB of 14.9 GB allowed. At the square-quad moment the split was: decoded ASTC 1514 MB, rendered 2083 MB (108 drawn in one frame), other 416 MB — the "rendered" class is exactly the one the eviction code describes as coming back empty/garbled.
  • 8,196 textures retired between presents 90000-105000 (38,744 over the session); the corruption frames line up with the sweep activity (pool remade larger, sweeps of 366/393 textures).
  • No DEVICE_LOST, no skipped draws; fps mean ~47 in the field (framegen 2x reads ~144 on the overlay).

So the 60-frame eviction fix genuinely improved things — the old build corrupted permanently at ~1740 textures, this build peaks at 3189 with only transient glitches — but Hyrule Field's texture volume overruns the 6144 MB budget and the sweep still loses textures the game is actively using. The GPU-rendered ones are the worst case: the last_value > completed guard does not save them all, and a "remade larger" pool change may drop their storage.

Two more things seen in the same stretch:

  • Fog flicker confirmed on Hyrule Field too: fog density alternates frame-to-frame at the castle drawbridge (absent → thick band, same spot seconds apart). Consistent with what I reported above for the Lost Woods.
  • A freeze-then-crash in combat against flying enemies — the second crash today with the identical signature c0000005 at n_nvnTextureBuilderSetSwizzle +0x2d (first was the ocarina sheet, filed as #500). Same null/freed texture-builder dereference, so the crash is not ocarina-specific; near the crash the log shows mesh-program work for the flying enemies and repeated upload over a drawn image warnings. Details in #500.

Full redacted log attached (32,500 lines, paths stripped, no game content) — the sweep/budget numbers come straight from it.

[log attached below]

Correction to my comment above: **the texture corruption is not fixed.** It came back on Hyrule Field — my earlier verdict only covered up to the Deku Tree exit. **What changed my read: three transient corruption forms, all tied to budget-pressure eviction, all captured in one continuous session (108,000+ presents):** 1. **Deku Tree bridge (~present 72000):** wooden planks render as a dark tiled pattern — same class as the original report's deck planks. 2. **Hyrule Field dirt path (~105000):** dark cross-stitch garbage in some frames, recovering to correct a few seconds later (two captures of the same spot show the recovery). 3. **Hyrule Field grass slope (~107400):** a flat dark quadrilateral where a terrain chunk should be — a GPU-rendered texture evicted and coming back empty. Log context (the budget is the story): - `textures 6094 MB of budget 6144 MB` (99.2% full), VRAM 12.1 GB of 14.9 GB allowed. At the square-quad moment the split was: `decoded ASTC 1514 MB, rendered 2083 MB (108 drawn in one frame), other 416 MB` — the "rendered" class is exactly the one the eviction code describes as coming back empty/garbled. - **8,196 textures retired between presents 90000-105000** (38,744 over the session); the corruption frames line up with the sweep activity (`pool remade larger`, sweeps of 366/393 textures). - No DEVICE_LOST, no skipped draws; fps mean ~47 in the field (framegen 2x reads ~144 on the overlay). So the 60-frame eviction fix genuinely improved things — the old build corrupted permanently at ~1740 textures, this build peaks at 3189 with only transient glitches — but Hyrule Field's texture volume overruns the 6144 MB budget and the sweep still loses textures the game is actively using. The GPU-rendered ones are the worst case: the `last_value > completed` guard does not save them all, and a "remade larger" pool change may drop their storage. **Two more things seen in the same stretch:** - **Fog flicker confirmed on Hyrule Field too**: fog density alternates frame-to-frame at the castle drawbridge (absent → thick band, same spot seconds apart). Consistent with what I reported above for the Lost Woods. - **A freeze-then-crash in combat against flying enemies** — the second crash today with the identical signature `c0000005` at `n_nvnTextureBuilderSetSwizzle +0x2d` (first was the ocarina sheet, filed as #500). Same null/freed texture-builder dereference, so the crash is not ocarina-specific; near the crash the log shows mesh-program work for the flying enemies and repeated `upload over a drawn image` warnings. Details in #500. Full redacted log attached (32,500 lines, paths stripped, no game content) — the sweep/budget numbers come straight from it. [log attached below]
NotRexed commented 2026-11-08 09:56:25 +00:00 (Migrated from github.com)

The one-frame lighting flicker was reduced in release ultrawide (exposure readback from PR 430) and faster-fps (texture write-back before eviction). Please update from https://github.com/NotRexed/Hookshot/releases/latest and open a new issue with a log if you still see corruption after long play.

The one-frame lighting flicker was reduced in release ultrawide (exposure readback from PR 430) and faster-fps (texture write-back before eviction). Please update from https://github.com/NotRexed/Hookshot/releases/latest and open a new issue with a log if you still see corruption after long play.
Commenting is not possible because the repository is archived.
No milestone
No assignees
1 participant
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
MagicBeanDev/Hookshot#386
No description provided.