Repository navigation
AMD (RX 6600) fixes for Ocarina of Time: GPU hang, fog flicker, exposure - #430
Closed
YunaraDebugs wants to merge 1 commit into
Closed
YunaraDebugs wants to merge 1 commit into
YunaraDebugs wants to merge 1 commit into
Conversation
Tested on an AMD RX 6600 (Windows, driver 0x800161), Kokiri Forest: - AMD: task and mesh programs (OoT's foliage culling) are built without the driver's optimizer. Optimized, they hung the GPU (device lost) one to four minutes into Kokiri, each time with another of them first. RX_VK_MESH_OPT=1: with it. - Readback pages: small GPU results the CPU reads and then resets (OoT's exposure meter) are copied from guest memory into the pool's mirror at the start of each submission, so the CPU's reset reaches the GPU before it adds the next frame. Before, the meter read 2x or 0 about once every two seconds and the exposure stepped (the fog flickering in Kokiri's light); in a 20 s log, 9 bad reads -> 0. RX_VK_NO_RB_REFRESH=1: off. - Sync mode: texture and program releases made while queues are stopped at a wait are kept until the stopped work goes on, instead of making it go early (drain 1). Forced early, a pass read what was not there yet and the ground fog came out thinner for a frame, about every 13th frame. RX_VK_RELEASE_DRAIN=1: as before. - Driver optimizer raced per pipeline (build_raced): the optimized build gets RX_VK_OPT_BUDGET_MS (1500); on failure or timeout a build without it is used, and a late optimized one replaces it. hookshot_noopt.txt remembers programs the optimizer could not build in time. The prepare_run compute warm-up goes through it too. - Write-backs by DMA: a transfer queue and a staging ring take the mirror -> guest copies off the graphics queue; every guest-memory reader waits for copies over its range. RX_VK_WB_DMA=0: off. - AMD buffer-marker checkpoints for device-lost reports (RX_VK_CHECKPOINTS=1) and a readback log (RX_VK_LOG_READBACK_FILE). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
hopefully this gets merged |
juniortesla53-cpu
added a commit
to juniortesla53-cpu/Zelda-OoT-Hookshot-RX5700XT
that referenced
this pull request
Nov 8, 2026
Upstream's NotRexed#296 waits for the GPU before a CPU readback of GPU results. On a Ryzen 5 5500 + RX 5700 XT ~4% of readbacks waited ~18.6 ms each: the game's threads spun in their sleeps and fps fell from ~43 to ~30. The wait is off by default here (RX_VK_READBACK_WAIT=1: on). What it protected, OoT's exposure meter (the GPU adds into it, the CPU resets it to 0), is kept right by the readback-page refresh from YunaraDebugs' PR NotRexed#430: each submission first copies the pages the CPU reads back from guest memory into the mirror, last of the uploads (RX_VK_NO_RB_REFRESH=1: off). Every write-back here is on the queue in order, so the PR's DMA condition is not needed. Tested in Kokiri: fps back to ~40 fullscreen, no white flashes. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
Tested on an RTX 4080 / Windows 11 / Ryzen 9 7900X:
No regression on NVIDIA: same fps range, no white frames, no device lost. Plain |
NotRexed
pushed a commit
that referenced
this pull request
Nov 8, 2026
…queue wait_queue_empty in sync mode (a queue finish, an invalidate that reads back what the GPU wrote, a pool's mapping changing) called sync_drain(2), which forces every queue stopped at an event wait past it. The work those waits are for is mostly not submitted yet: the thread waiting is the one that submits it (holding the waiter 20 ms let only 32 of ~3600 go on by themselves). Forced past, the stopped submission's lit passes read what that work makes before it was made, and the scene came out black, grey or blown out for a frame (HUD and Navi on top), every other frame for seconds in Kokiri Forest. At low frame rates the other queue's work had always arrived first, so this shows once the game runs at speed. A frame probe (RX_VK_PROBE=2) of the dark frames: the same ~120 draws into the 1536x864 scene target came out 0, with the 512x512 compute dispatches recorded before the passes instead of after them. Now a catch-up only schedules what can go on; the rest goes on with its own queue's later work, a present, or sync_watch's hold_ms, as before. RX_VK_CATCHUP_FORCE=1: forced, as before. Complements #430, which does the same for releases (drain 1). Measured over 70 s of Kokiri gameplay (frame log, RX 7800 XT, RADV, foliage-linux-updater release + this): before: 10,000-40,000 waits gone past, 600-2,900 forced by "waits for the replay", 250-1,100 frames flashing after: 264-378 waits gone past, 0 forced by catch-ups, 65-113 frames flashing (3 runs); 60 fps, no hangs or device loss The flashes left line up with the presents' drain(0) (114-362 a run); #430's readback refresh may be what remains. Assisted-by: Claude Opus 5.5 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Owner
|
Thank you, this was very useful. Three parts are ported into main by hand and shipped in https://github.com/NotRexed/Hookshot/releases/tag/ultrawide, each with your env switch and credit: the readback refresh for the exposure meter (it reduced one-frame lighting flicker here too, on an RTX 3060), task/mesh pipelines without the optimizer on AMD, and holding releases while queues are stopped. The DMA write-backs, the per-pipeline optimizer race and the warp profile are not in yet (they conflict with main now and are untested on NVIDIA); if you'd like them in, a rebased PR with just those would be great. |
Closed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes for Ocarina of Time on AMD, tested on an RX 6600 (Windows, driver 0x800161) in Kokiri Forest. Each change has an env switch that turns it off.
GPU hang one to four minutes into Kokiri (device lost)
On the RX 6600, the task and mesh programs of the foliage culling hung the GPU when the driver's optimizer built them. AMD buffer markers showed a different one stuck first each time (918adef1afaa39d4, 6f9142def3b6a978...). Runs with them built without the optimizer never hung, ours and upstream's with
RX_VK_NOOPT=1. On AMD, task and mesh pipelines are now built withDISABLE_OPTIMIZATION; everything else keeps the optimizer.RX_VK_MESH_OPT=1: as before.Fog flickering in Kokiri's light: the exposure meter
#296 made readbacks wait for their write-back, but the meter still read 2x or 0 about every two seconds. The CPU's reset to 0 landed in guest memory after the next submission had synced its mirror, so the GPU added onto the old sum. Small readback ranges (≤ 16 KB) whose write-backs stay on the queue are now copied from guest memory into the mirror at the start of each submission, last of the uploads. Logging the meter at the same spot for 20 s gave 9 bad reads before and 0 after.
RX_VK_NO_RB_REFRESH=1: off.One-frame ground-fog dips
In sync mode, a texture or program release made while queues are stopped at a wait forced the stopped work on at once (drain 1, about 1,000 times a session). That work then ran before what it waits for, and the ground fog came out thinner for a frame, about every 13th frame. Releases made while queues are stopped are now kept until the stopped work goes on, at its wait, a present or
hold_ms. The title and menu text stayed correct with this.RX_VK_RELEASE_DRAIN=1: as before.Driver optimizer per pipeline
AMD's compiler fails some pipelines with the optimizer (-13 on 5fa56485a6b07619) and takes minutes over others. Each pipeline now builds with the optimizer on a below-normal thread, with a budget (
RX_VK_OPT_BUDGET_MS, 1500). If it fails or runs out of time, a build without the optimizer is used, and a late optimized one replaces it.hookshot_noopt.txtbeside the exe remembers the slow and failed ones, so later starts skip the optimizer for those. The prepare_run compute warm-up uses the same path, so a slow optimizer build no longer holds the start.Write-backs by DMA
Mirror → guest write-backs go through a staging ring on a transfer-only queue, which is AMD's SDMA engine. On the RX 6600 this cut GPU time from 18.2 to 14.0 ms per frame in Kokiri. Every reader of guest memory waits for copies over its range: mirror syncs, mirror make/free, guest bindings, texel views, texture flushes and the page table's first fill.
RX_VK_WB_DMA=0: off.Diagnostics
RX_VK_CHECKPOINTS=1: AMD buffer markers around draws and dispatches. A device lost lists what was done, under way and not reached, with each program's stages.RX_VK_LOG_READBACK_FILE=<path>: logs every readback while that file exists.Not tested: NVIDIA, Linux, and AMD cards other than the RX 6600. The DMA, readback-refresh and release changes apply to all GPUs. The optimizer race and the per-stage warp profile (
RX_VK_WARP_WIDE=1, off by default) are also in this change.🤖 Generated with Claude Code