Ocarina of Time (0400486024DEC000 v131072, Mac M2 Pro): reproducible GPU hangs in NPC dialogue and the Impa escort — narrowed to Hi-Z task a5288d0a6c4971fd pipelines (mesh 3439aaa071d868ae / pixel bd09ab5fc4fd7680 light loop); c3[193] grid is sane

Summary

On plain main (eed7c42) the game hangs the GPU (kIOGPUCommandBufferCallbackErrorHang → "GPU access revoked") every time at two story moments:

Kokiri Forest, early NPC conversation: The girl sitting above the shop. Right after the game prompts me to target her and I start talking, as the dialogue camera begins circling her. The frozen frame keeps the NPC drawn; the rest of the scene is gone.
Hyrule Castle, Impa escorting Link out after meeting Zelda. Here the screen flashes white a few seconds before the hang.

Not intermittent for me: 100% reproducible across ~20 runs and several builds. Related: #1843 (same pipeline found independently), #1830, #1326, #1756, #1788, #1690.

Setup

Apple M2 Pro (Mac14,12), macOS 26.6.2, Xcode 27.2, Metal compiler 32023.922
nxnative eed7c42, shader chain 094f939bfef9, build_ipa_from_nsp.py --platform mac-app --gpu g14s, no env changes. Only local change: shader_split.unzs decompresses in-process, because the zstd subprocess pipe stalls the split at ~160,400 files under Python 3.15 on this Mac (doesn't change the app).
NUP: base v65536 + update v131072; all 203,786 .zs files checked (zstd signature + SHA-256), none damaged. (An earlier update-only NUP had 3 zero-filled textures; the clean dump hangs the same.)
Same hangs with DM_UPSCALER=game and metalfx, handheld mode.

Narrowing it down

I added a small switch, DM_NVN_SKIP_MESHKEYS=<key>[,…], in mesh_tasks_draw that drops task/mesh draws whose task, mesh or pixel key matches (DM_NVN_SKIP_FS doesn't apply to mesh draws, so #1756's planned test with it can't drop these).

DM_NVN_SKIP_MESH=1 (all task/mesh draws off) → Kokiri conversation goes through.
Bisecting the task/mesh pipelines (49 in that scene) by key → dropping only mesh 3439aaa071d868ae (task a5288d0a6c4971fd, pixel bd09ab5fc4fd7680 / 7b0a886903a664b2, Model.Product.110 #BNSH@0x11543000) prevents the Kokiri hang every time; every run that draws it hangs. That pipeline is first built a fraction of a second before the hang.
Dropping only e8c667282ba7bd9b + d4171cf9adf0504b (Ocarina of Time's intermittent GPU hangs measured: 0.03-0.27 per 1,000 frames, against 5.00 in the run macOS stopped, lining up with mesh pipelines built while the game ran #1756's triple) → still hangs. Dropping only pixel 7b0a886903a664b2 → still hangs.
With only 3439aaa071d868ae dropped, one session ran 88 minutes with zero GPU errors (Deku Tree → Castle Town), then hung at the Impa escort. There, 11 other new a5288d0a6c4971fd pipelines were in the failed buffer (e.g. meshes 57ed4680e3042998, b903546b6b988e5f, d744d81c38c5831a, 0c75c8aed6290acf, 40a470bb5dbd8f2d).
DM_NVN_SKIP_MESHKEYS=a5288d0a6c4971fd (every pipeline with that task) gets through both scenes, with nothing obviously missing on screen.

What the shaders show

Task a5288d0a6c4971fd: its tile loops are bounded by c3[193].xy. I logged S.ubo[3][0] vec4 193 on the host for every a5288 draw: a sane 32 × 18 (and 1 × 1 for small passes) right up to the hang, never garbage, so the Hi-Z scan in the task is bounded. (This is the suspect DM_NVN_A5288_C3 in Ocarina of Time: diagnostics, off by default: TEXDUMP over a range of frames with depth targets, DM_NVN_A5288_C3 for the task hang #1843 is built to check.) Some draws report 0 × 0.
Mesh 3439aaa071d868ae: no loops, barriers or SIMD ops in its body. Its index writes reach 1 word past the stage array when all 128 lanes write (max_p 126, the Mesh stage memory reserves the primitive index bytes for every block the threads write #1575 case).
Pixel bd09ab5fc4fd7680: a do { … } while (true) loop of min(fp_s0[tile].count, fp_c6[113].x) + 1 iterations over lights. Logged fp_c6[113].x = 1000 in every draw. So the hang implies the GPU-read per-tile counts in fp_s0 are far too high during these scenes, giving up to ~1000 lighting iterations per pixel across the screen, enough to trip the watchdog. The white flash before the Impa hang fits overfull light/tile lists.

Ruled out on this machine

Batching ([0400486024DEC000] Ocarina of Time (macOS): GPU Hang -> 'GPU access revoked', game quits #1788's suggestion): DM_NVN_CUT=4 DM_NVN_CUT_BUSY=0 still hangs (the failed segment is the main scene pass).
Raw global memory through a pointer read when the draw is bound: the host fills each fixed-offset pointer's pool range before the draw (chain 1ffcb6b77740) #1585 (task range pointer), A memory pool's buffer follows its pages when they are unmapped and mapped again (Monster Jam Steel Titans 2 GPU hang) #1616 (pool buffers after remap), the residency fix (now merged): each tested, still hangs.
Upscaler choice, damaged textures, memory (footprint ~4 GB at the Kokiri hang, ~11.7 GB peak in the long session).

Workaround

DM_NVN_SKIP_MESHKEYS=a5288d0a6c4971fd (patch to mesh_tasks_draw, 13 lines; happy to open a PR). Logs from vanilla eed7c42 runs of both scenes are available.

Ruled out the draw-pass ordering race (#1707): ran the same build with DM_NVN_BARRIER=full (every pass waits for the previous one, stricter than #1707's object/mesh stages) and no pipelines skipped (DM_NVN_SKIP_MESHKEYS empty). It still hangs (frame 1303), with a5288d0a6c4971fd_b in all 5 failed command buffers (5/1994, top of the ranking). So the bad tile light counts aren't a pass-overlap race on this machine.

Fixed on current main for me: 8d5d4f1b (chain 0c434f1b68df), vanilla, no DM_NVN_SKIP_MESHKEYS. Both the Kokiri conversation and the Impa escort play through with zero GPU errors, locked 30 fps (GPU p50 ≈ 21 ms). Likely from #1860's uniform bounds (26062f9e) and/or -fwrapv (e4e5ff64). Closing.

Notes from looking at this on an M6 (main, chain f9f01e4f9994 libraries), for #1326, #1605 and this issue.

The pixel shader's light loop isn't it. In bd09ab5fc4fd7680 the loop runs min(count, c6[113].x) + 1 times, so at most 1,001 per pixel, and nothing in it loops again. Every macOS GPU report attached to these issues that says which stage was busy names the geometry stage (fw_ta_state busy, fw_cl_state idle) with restart reason "MMU interrupt", and reefbluesky saw page faults at 0x700 and 0x3400000000, outside every pool. Task and mesh shaders run in that stage; a slow fragment loop would show the fragment stage instead. The task a5288d0a6c4971fd's tile loops are clamped to c3[193] (logged sane above). On builds since ffebfd5, mesh 3439aaa071d868ae has no loops.

An M6 can't show this hang. On the M6, a shader read 4 GB or 1 TB past its buffer, or at address 0x700, returns 0, a wild write is dropped, and the command buffer completes. On M1–M5 the same access gives the page faults above. Saria's opening dialogue drew the a5288d0a6c4971fd / 3439aaa071d868ae pipelines with both pixel shaders on the M6, at 13.6 ms of GPU a frame, with no errors. The M6 also accepts mesh vertex indices past max_vertices (64 up to 4e9). So results from an M6 say nothing about this bug.

Working hypothesis, not confirmed: a shader in those pipelines' task or mesh stage reads or writes a bad device address. Metal's shader validation reports such a load on the M6 (address, buffer, source line), so the next step is a run with validation limited to the a5288d0a6c4971fd pipelines. Full validation stalls at boot.

DM_NVN_SKIP_MESHKEYS stops the hang by not drawing those pipelines; it hides the cause rather than fixing it.

Base M1 (8-core GPU, 16 GB), macOS 26.6.2: first try at validating only the a5288d0a6c4971fd pipelines — the per-pipeline switch is ignored without the global layer

Reproducer: our older local branch (codex/oot-final6 at 23272a83, main as of e2b76d4e plus our picks; its own matching library, chain 90e8d82142f4), a save of our own, docked, 60 fps target, scripted input (DM_KEYS=15:A*12/4), DM_NVN_ISOLATE_TASK=0, headless. It hangs ~25–35 s after the save loads in every run so far (5 of 5: 3 windowed, 2 headless; frames ~1418–1600), kIOGPUCommandBufferCallbackErrorHang, then GPU access revoked; each failed command buffer holds the culling task f75708d176bb6591 (10 of 10), and 7 of 10 also a5288d0a6c4971fd. No shader of the run failed to load.

What we tried, with a local switch that builds the task / mesh pipelines whose task or mesh key is a5288d0a6c4971fd or 3439aaa071d868ae through the MTLDevice with MTLMeshRenderPipelineDescriptor.shaderValidation = MTLShaderValidationEnabled (never from or into a pipeline archive) and logs what the returned state reports:

Without MTL_SHADER_VALIDATION: all 14 such pipelines came back with shaderValidation not enabled, so the field is ignored on this system without the global layer. The run hung as usual (no validation report, which here means nothing).
With MTL_SHADER_VALIDATION=1: the game boots ("Metal GPU Validation Enabled") but runs far too slowly to reach the hang (about 900 frames in 300 s, frames up to 2.8 s), so no a5288 pipeline was built. During boot the layer reported 4,024 times:

Invalid device load at offset 41, executing vertex function: ""
buffer: Out of bounds of user address space, length:1, resident:Read Write
pipeline: "(null)", UID: "07C32766865D5FBB6BFF7BAEBD86FE92DF7E62BB5C521A5FFF4A7996A44754BC" encoder: "6", draw: 0

We can't tell which shader that is yet (the pipelines carry no label). Next on our side: label every pipeline with its shader keys, and with the global layer on, turn validation off for every pipeline outside the list, so the game reaches the scene with only those pipelines validated.

Two small corrections to my comment above: the 5 reproducer runs were 3 windowed and 2 headless (I wrote "headless" for all), and the task a5288d0a6c4971fd is in 7 of the 10 failed command buffers, not "about half" (the culling task f75708d176bb6591 is in 10 of 10). The older branch is codex/oot-final6 at 23272a83, main as of e2b76d4e plus our picks.

Base M1, follow-up: validation limited to the a5288d0a6c4971fd pipelines now runs, and the run dies inside Metal's debug layer before the hang point

Same reproducer as above (host 23272a83, its matching library 90e8d82142f4, docked, 60 fps target, scripted input, DM_NVN_ISOLATE_TASK=0, headless; it hangs ~25–35 s after the load, 5 of 5 so far). This time with MTL_SHADER_VALIDATION=1 loaded globally and, in our local diagnostic build, every pipeline outside the list built with shaderValidation = MTLShaderValidationDisabled (Metal 4 options, legacy and mesh descriptors), the listed task / mesh pipelines built through the MTLDevice with validation enabled, and every pipeline labelled with its shader keys.

Metal honours the opt-out with the layer loaded: the boot ran at 16.6 ms frames (60 fps) up to frame 600, against ~32 ms with 2.8 s spikes when every pipeline was validated.
The listed pipelines were validated: for a5288d0a6c4971fd with meshes d4171cf9adf0504b and e8c667282ba7bd9b (fragment ea1bf96b72e72476), the returned state reports shaderValidation enabled, and the first draw of one of them ran (3 workgroups from 0).
No validation report came from them before the process ended. The only report of the run was in Apple's MetalFX scaler (Invalid device load …, executing fragment function: "MFX_SCALE_SHADER_V1_FRAG", pipeline MFX_ScaleRenderPipelineStateV1), not a game shader.
The run ended at about frame 1,192, shortly before where this save hangs, with a crash in the debug layer rather than a GPU fault:

CRASH sig=5 pc=objc_opt_isKindOfClass+0x30 lr=-[MTL4GPUDebugCommandBuffer applyResidencySets:]+0x344

So up to that point the validated a5288d0a6c4971fd pipelines made no invalid device access, but the run did not reach the moment of the hang. We will look at what the debug layer found in the residency set (a released object would fit it) before trying again.

Base M1, follow-up 2: the debug-layer crash is a buffer used in a residency set after it was freed (repeatable), and the boot report is in a vertex-pulling pipeline

Same reproducer (host 23272a83, matching library 90e8d82142f4, docked, 60 fps target, scripted input, DM_NVN_ISOLATE_TASK=0, headless), with MTL_SHADER_VALIDATION=1.

The crash repeats and is a use after free. Three of the four runs with the layer loaded ended in -[MTL4GPUDebugCommandBuffer applyResidencySets:] (at frame ~1,192, and between frames 300 and 600 in the other two); the fourth, with every pipeline validated and no labels, ran too slowly to get past frame ~900 in 300 s. With NSZombieEnabled=YES it came at 14.8 s, on the title, as:

*** -[MTLGPUDebugBuffer isKindOfClass:]: message sent to deallocated instance 0x918e10d20
bt: ___forwarding___+0x504 _CF_forwarding_prep_0+0x60 -[MTL4GPUDebugCommandBuffer applyResidencySets:]+0x344 -[MTL4GPUDebugCommandBuffer preCommit:]+0x18 -[MTL4GPUDebugCommandQueue _commit:count:options:]+0x174 rec_commit+0x98 mtl_sub_commit+0xf28 ...

So at a commit, a residency set still listed an MTLBuffer that had already been released. Without the debug layer nothing catches that, and a GPU access through a buffer whose pages are gone would fit the MMU faults in the hang reports. This is on our older host; we have not yet checked whether current main does the same (a run of a main-based host with the layer is next).

The validated a5288d0a6c4971fd pipelines made no report before the run ended (it never reached the hang point, ~frame 1,418–1,600 on this save).
The boot report (Invalid device load ... vertex function: "" / buffer: Out of bounds of user address space, length:1, UID 07C32766…): with every pipeline labelled, that pipeline is vs=? fs=29e3c9dd92b8a571_b, i.e. a vertex-pulling stand-in (not a library shader, hence no key) with the terrain pixel shader 29e3c9dd92b8a571 (tera_develop.sharcb). 2,190 such reports in one boot, all in pulling stand-ins (fragment shaders 29e3c9dd…, be57fb15…, 4dd9070f…, 38482ed8…, …), all a 1-byte read "out of bounds of user address space". These are the host's hybrid pulling pipelines reading a vertex stream with no valid address, not the task / mesh stage.

Base M1, follow-up 3: correction and a narrower reading of the debug-layer crash — the residency set is committed on a completion thread while the submit thread commits command buffers

Same reproducer (host 23272a83, matching library 90e8d82142f4; it has now hung in 11 of 11 runs without the layer). We added a local log of every allocation released while the host's residency set (g_res) still listed it, or after removeAllocation but before the set's next commit, with the releasing stack.

Correction to our last comment: nothing is released while the set lists it. Every release we logged (about 200–300 per run up to the hang) happens inside -[IOGPUMetalResidencySet commit] (with the layer: -[MTLToolsResidencySet commit]), i.e. the set kept the allocation alive and dropped it when its removal took effect. So "a buffer used after free" was the wrong reading.
Where those commits run: most come from the upload path's commit-feedback handler, on Metal's completion thread: res_commit ← __up_flush_block_invoke ← -[_MTL4CommitFeedbackDispatch executeBlocksWithCommitFeedback:] ← IOGPUNotificationQueueDispatchAvailableCompletionNotifications. That handler removes the batch's staging buffers from the set and commits the set, while the guest submit thread may be committing command buffers on the queue that uses the same set (rec_commit ← mtl_sub_commit). The debug layer's crash is in -[MTL4GPUDebugCommandBuffer applyResidencySets:] on the submit thread meeting a buffer the other thread's set commit had just released (-[MTLGPUDebugBuffer isKindOfClass:]: message sent to deallocated instance). That fits a race between MTLResidencySet commit on one thread and a queue commit that applies the set on another.
Link to the hang: not shown. In each failed command buffer's last 64 fences there were 34–79 such releases (32 MB / 8 MB upload staging blocks, 64 KB deswizzle parameter blocks, 128 KB pool buffers), against about 1.5 per 64 fences over the whole run; but those windows are the area load, when the upload path is busiest anyway. Current main has the same handler (res_remove of the staging buffers and res_commit() in up_flush's feedback handler), and a main-based host with main's library did not hang on this route in 2 of 2 runs, so this race alone doesn't explain the difference.

Next on our side: serialize the two (no set commit off the submit thread) and see whether the layer still crashes and whether the reproducer still hangs.

Base M1, follow-up 4: serializing the residency set commit with the queue commit removes the debug-layer crash but not the hang

Same reproducer (host 23272a83, matching library 90e8d82142f4, docked, 60 fps target, scripted input, DM_NVN_ISOLATE_TASK=0, headless). In a local diagnostic build every Metal 4 queue commit now holds the lock res_commit takes (g_res_mu), so the upload path's set commit on the completion thread can no longer overlap a command-buffer commit on the submit thread.

With MTL_SHADER_VALIDATION=1 and NSZombieEnabled=YES: the run went its full 120 s to frame ~900 with no crash and no zombie. Without the serialization, the same setup ended in -[MTL4GPUDebugCommandBuffer applyResidencySets:] on a released buffer in 4 of 4 runs that got that far (at 14.8 s with zombies on). So that crash was the race between the two commits.
Without the layer: the game still hung in 3 of 3 runs, at the same place as before (frame ~1,500, kIOGPUCommandBufferCallbackErrorHang ×4, then GPU access revoked), with frame p50 16.6 ms, submit+present p50 0.7–0.8 ms and GPU p50 5.7–5.9 ms in the minute before. The reproducer is now 14 of 14 without the layer.

So the residency set race is real (the debug layer was right to complain) but it is not what hangs this save. We'll leave that path there. Note that holding g_res_mu across a queue commit can deadlock if the commit ever waits for completions while a completion handler wants the lock (see #2098), so it is not a fix to land as is.

@ycarogabriel-lgtm

Looked at the M1 follow-ups on an M4 Pro (main at bbea4c90, Ocarina libraries on chain 0c434f1b68df).

The residency-set crash is in Metal's validation layer, not a buffer the host freed. A residency set holds a strong reference to every allocation it lists until a commit after its removal. A buffer whose last reference is gone stays alive while it's in the set (checked standalone). A small program reproduces the same crash with correct locking. One thread adds a buffer, commits the set, removes it and commits again. Another thread commits empty MTL4CommandBuffers on a queue that has the set. With MTL_SHADER_VALIDATION=1 and NSZombieEnabled=YES it stops within milliseconds:

*** -[MTLGPUDebugBuffer getActiveViews]: message sent to deallocated instance

The same loop on one thread runs 20,000 iterations without a report, and so does the two-thread version without validation. The debug command buffer reads the set at its commit while the other thread's set commit releases a removed buffer. The host commits its set from more than one thread (deferred releases are committed off the submit thread), which Metal allows. So this crash says nothing about the hang. With validation on, it will keep ending runs early.

The pulling stand-ins' reports are real reads, not false positives. t_pull, which checks every vertex format through the pulling fetch against Metal's own, runs clean under MTL_SHADER_VALIDATION=1. So the 2,190 Out of bounds of user address space loads in your boot were real reads. I could not check whether current main still makes them: a validation boot here waits at frame 110 before the title.

Your host predates two fixes that can stop this hang. 23272a83 is main as of e2b76d4e plus your picks. It has neither e4e5ff64 (translated shaders compile with -fwrapv) nor 26062f9e (a read past a uniform binding's size gives 0). Both are in 8d5d4f1b, where the original report's scenes played through with no GPU errors. For mesh 3439aaa071d868ae, -fwrapv changes the compiled code a lot (about 21,000 lines of LLVM IR differ). The task's and mesh's raw global loads are checked against the pool table before they read, so an address in no pool reads 0 rather than faulting.

@ycarogabriel-lgtm could you run the same save and input on current main, without your picks, using libraries built for its chain? If it still hangs there, please attach the log with the failed command buffers' shader list. A run that validates only the a5288d0a6c4971fd pipelines would then be the next step. To avoid the crash above, it needs either validation off for the residency set's other users, or every set commit on the submit thread in your diagnostic build.

Pure main on an M1: the hang did not reproduce in 2 runs that went well past the point where our branch hangs every time

You asked for a run on current main without our picks. Short version: on 6c676444 with a full library for that commit, the route that hangs our older branch 14 times out of 14 (all by frame ~1,418-1,600) ran to frame 4,738 and 5,582 with no kIOGPUCommandBufferCallbackErrorHang, no failed command buffer and no [RED] line. Details and caveats below.

What ran


Commit	`6c676444` (commit date 2026-11-10 11:21 +0800; origin/main when the build started), no local changes
Shader chain	`d403eb0683df`. Full `dmsh_build.py` run for that commit (`shaders 42848: ok 42848`, `lost without failing: nothing`, stamp `inputs 4bd48f723876`), `c1_full.tsv` / `cb_extent.tsv` from the same build
Machine	Apple M1, 16 GB, macOS 26.6.2
Mode	docked, 1920x1080, `DM_FPS_TARGET=60`, `DM_NVN_ISOLATE_TASK=0`, `DM_UPSCALER=metalfx`, headless (no window)
Input	same save and the same scripted input as the hang reproducer (`DM_KEYS=15:A*12/4`), 355 s per run, empty pipeline bundle, a fresh pipeline archive at the start of run 1 that later runs reuse

main has moved on since: it is at 641636e2 now, with chain e1d97965d3f3. That includes 6c3aeb37 (#2077, the plaid terrain after dungeons), which these runs do not have. I did not rebuild for the newer chain.

Results

Run	Last frame	GPU hang	Swap start → end	Lowest free memory	Ended by
1 (cold archive)	1,007	no	5.8 → 6.1 GB	43 %	time limit (see note)
2	4,738	no	6.1 → 10.0 GB	23 %	time limit
3	5,582	no	8.5 → 9.7 GB	23 %	time limit
4	1,418	no	8.5 → 10.8 GB	18 %	my memory guard (free < 20 % twice), not the game

For comparison, on our older branch (pre-ea0c98df base plus our picks) with the same save and input, 14 of 14 runs hung between frame ~1,418 and ~1,600. A failed command buffer held the task shader f75708d176bb6591 in 10 of 10 failures logged.
Runs 2 and 3 went through that window and kept going for about 3,100 and 4,000 more frames.
Runs 1 and 4 never got into that window, so they say nothing about the hang.
I found nothing in the logs about NaN or non-finite values. These runs were headless, so I did not check the screen for the blue/white blocks of Bounded uniform reads are written as select: OCTOPATH TRAVELER's dither-fading trees no longer show blocks on an M1 #2127.

Numbers from runs 2 and 3

Resident: 7.6 GB.
Long frames past frame 1,200, p50: whole frame ~99-104 ms, GPU ~62 ms. These come from [longframe] lines only, so they are not a mean frame time. The power line gives 15.3 fps averaged over the run.

Run 1 note (separate from the hang)

With an empty pipeline archive, frame 106 took 315 s on the submit thread: new pipelines 12 ... 315237.5 ms in all.
The pipeline-count line, however, says bases compiled 26 / 1304.5 ms. So almost all of that time was spent waiting, not compiling.
After that the run was normal, but it used up the time limit before reaching the hang window.
Seen once, on a cold archive, and not investigated. Mentioned only in case it rings a bell.

Caveats

n = 2 runs that got past the window. This is "not reproduced", not "fixed".
One machine, one route, one save.
I am not bisecting which commit between our base and 6c676444 makes the difference. One candidate is ea0c98df (NVN queue dependencies), which our hanging branch does not have, but I have not tested it.

revert: the uniform bounds guard is back in this variant (prova 24b),…

Closing, as you said: on 8d5d4f1b (chain 0c434f1b68df) the Kokiri conversation and the Impa escort play through with no GPU errors, and a run of plain main on an M1 (6c676444) went well past the frame where the older branch hangs. The likely fixes are 26062f9 (a uniform read past the size the game bound gives 0, from #1860) and e4e5ff6 (-fwrapv). If the hang comes back on current main, please reopen with the log's build: line.

Navigation Menu

Repository navigation

Ocarina of Time (0400486024DEC000 v131072, Mac M2 Pro): reproducible GPU hangs in NPC dialogue and the Impa escort — narrowed to Hi-Z task a5288d0a6c4971fd pipelines (mesh 3439aaa071d868ae / pixel bd09ab5fc4fd7680 light loop); c3[193] grid is sane #2011

Summary

Setup

Narrowing it down

What the shaders show

Ruled out on this machine

Workaround

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Ocarina of Time (0400486024DEC000 v131072, Mac M2 Pro): reproducible GPU hangs in NPC dialogue and the Impa escort — narrowed to Hi-Z task a5288d0a6c4971fd pipelines (mesh 3439aaa071d868ae / pixel bd09ab5fc4fd7680 light loop); c3[193] grid is sane #2011

Description

Summary

Setup

Narrowing it down

What the shaders show

Ruled out on this machine

Workaround

Activity

pkimsey commented on Nov 9, 2026

pkimsey commented on Nov 9, 2026

seedds commented on Nov 10, 2026

ycarogabriel-lgtm commented on Nov 10, 2026

ycarogabriel-lgtm commented on Nov 10, 2026

ycarogabriel-lgtm commented on Nov 10, 2026

ycarogabriel-lgtm commented on Nov 10, 2026

ycarogabriel-lgtm commented on Nov 10, 2026

ycarogabriel-lgtm commented on Nov 10, 2026

seedds commented on Nov 10, 2026

ycarogabriel-lgtm commented on Nov 10, 2026

seedds commented on Nov 10, 2026

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions