gpu-error: webgpu · nvidia maxwell · Windows

gpu-error — GPUValidationError: Destroyed texture [Texture "Surface cache"] used in a submit.

• While calling [Queue].Submit([[CommandBuffer from CommandEncoder "renderContext_12"]])

Renderer WebGPU · nvidia maxwell · 1920×1031 @1x · r180 · post: dof+smaa · 217 textures in 40 models
Render incidents 1 (gpu-error)
Build 470f796 · Origin https://dev.wartabletactics.com · Map Côte 213 · Phase Draft · Turn 0

Incidents so far:

• +2066.4s gpu-error: GPUValidationError: Destroyed texture [Texture "Surface cache"] used in a submit.
• While calling [Queue].Submit([[CommandBuffer from CommandEncoder "renderContext_12"]])

(×90)

Console, last lines:

• warn: [frame] 4656 ms between frames in "menu -> level" (this frame's own work 290 ms: frame:splatBake 6, frame:render 274; unattributed 10)
• warn: [frame] 281 ms between frames in "menu -> level" (this frame's own work 14 ms: frame:render 13; unattributed 1)
• warn: [frame] 86 ms between frames in "menu -> level" (this frame's own work 3 ms; no labelled span)
• warn: [stall] 90 ms in "menu -> level" — over the 85 ms DSP budget, the mixer missed 1 buffer(s)
• warn: [frame] 126 ms between frames in "menu -> level" (this frame's own work 4 ms; no labelled span)

Diagnostics attached as wtt-render-report.json (game state included).

I found and fixed the cause of forum report #303. It isn't specific to Maxwell GPUs: it's a three.js r180 bug, and anyone can hit it. I reproduced it on your Mac. The fix is committed on the branch but not merged or pushed, and I'm waiting for your OK.

What was happening

• The report is "Destroyed texture [Texture "Surface cache"] used in a submit", 90 times in the 1.5 s before the report was sent. That's every frame. It came from build 470f796 (current main) on Côte 213, after two board builds.
• A second, larger board makes the surface cache replace its texture pair with a bigger one and destroy the old pair 4 frames later.
• three r180 only rebinds the first object of each shader to the new texture. The shader's objects share one change-watcher, and it doesn't notice a texture swap. So every other bush and house piece kept drawing from the old pair. Once that pair was destroyed, every frame failed.
• Before the destroy it was also wrong without any error: those meshes were reading an out-of-date lighting texture.
• In headless Chrome on Metal, making the texture grow once on Côte 213 gave the exact reported error on every frame from then on.

The fix

• New src/render/textureSwapRefresh.ts: when a mesh is still bound to a texture its shader has since replaced, it now gets refreshed. It's installed at renderer start-up like the two existing r180 workarounds. The black-screen report's patches now includes textureSwapRefresh.
• The fix sits in the renderer rather than the surface cache, because any texture swap on a shared shader could hit the same bug.
• I also added a note in surfaceCache.ts and updated CLAUDE.md (the surface-cache paragraph and the r180-workarounds list).

Checks

• Same live test with the fix: the texture grew 512² → 768² → 1024² with no errors. Across 145,757 draws that read that texture, none were still pointing at the old one. Without the fix, 87 errors appeared within 1.5 s.