[Tracking] AMD rendering: white silhouettes, block squares / grid lines, no anti-aliasing (networks in software) #1006
Labels
No labels
accessibility
autorelease: pending
autorelease: tagged
bug
dependencies
documentation
duplicate
enhancement
github_actions
good first issue
help wanted
invalid
question
testing wanted
wontfix
No milestone
No assignees
2 participants
No due date set.
Dependencies
No dependencies set
Reference
MagicBeanDev/Hookshot#1006
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
This issue collects every open report of AMD-specific rendering problems, so there is one place to follow it. The individual reports were closed pointing here; their logs, screenshots and discussion stay in each linked issue.
Summary
AMD-specific picture problems on Windows:
Affected GPUs and versions
Evidence from the logs
RX_VK_ASTC_RGBA8=1works around it.RX_VK_UNEVEN_BC=0turns it on for testing, and the thin grid lines on Hyrule Field may come back on AMD until it is redone.RX_VK_BC_LAYERS=<n>restores multi-layer runs.Workarounds
RX_VK_ASTC_RGBA8=1(uses more VRAM).Reports merged here (9 issues, about 25 people)
Adding a report
Please update to v2.0.6 first (https://github.com/NotRexed/Hookshot/releases/tag/v2.0.6; Update next to Play in the launcher). Please add: GPU, driver version, screenshot, version, and
hookshot_log.txt.All tracking issues
Full
hookshot_log.txtfrom v2.0.6 on an RX 6700 XT as requested in #1017: https://gist.github.com/kafasam/87d289c0f48d93eb5ed45a3431cf9ef8Context: 10 programs failed at the title, 11 in Hyrule Field; the same session ran 4K output (HOS_OUTPUT_RES=2) + Resolution 75% + FG2, with visible symptoms of textures not loading / arriving late on area re-entry (Kokiri after Hyrule Field hung a long while before textures filled in), ~22 fps real in Hyrule Field, failed-programs count unchanged from v2.0.5. Happy to run any instrumented build or capture frames.
Follow-up from the same RX 6700 XT (v2.0.6, 4K output / Resolution 75% / FG2): two log patterns that look like the texture side of this tracker.
1. Slow ASTC(BC3) uploads stalling frames during play — streaming a new texture costs 21–27 ms each on the upload thread, e.g. in Hyrule Field (and stacking on area re-entry, which we see as multi-second hangs while textures fill in):
2. The import pool never releases:
imports: 81 live (2208 MB), 63 retired still imported (1840 MB), 0 retired given back (0 MB)— 1243 live textures and climbing across a session. Retired memory is never returned, so the game keeps importing/re-uploading rather than reusing.Given the failed compute programs on AMD are also texture-side (our counts in #1017), we're testing
RX_VK_ASTC_RGBA8=1next to bypass the BC3 re-encode entirely — will report whether the slow uploads and the streaming freezes disappear.RX 6700 XT follow-up on the
RX_VK_ASTC_RGBA8=1test we said we'd run: it bypasses the BC3 re-encode but is not viable at this game's texture volume on a 12 GB card.Live numbers from Hyrule Field/Lon Lon Ranch, same session shape as the earlier reports (4K output, Resolution 75%, FG2):
So the 16–27 ms ASTC(BC3) slow uploads stand as the least-bad path here; the streaming stalls and area-entry hangs remain (reproduced at Lon Lon Ranch on v2.0.6 with the default path). The failed-compute-programs connection in this tracker remains our best explanation for why the re-encode is slow on AMD while the same content streams fine elsewhere — everything still points at the texture-side compute kernels.
AMD testers: green diagonal stripes on v2.0.6+ (RX 7600 report on Discord)
v2.0.6 turned on two AMD-only shader changes. If you see bright green diagonal stripes on trees, terrain or characters, please try each of these and reply with what changed (one at a time, same spot):
Make a file
test.batin your game folder (next tohookshot.exe) with:Then the same with
set RX_VK_NO_NAN_GUARD=1instead. Please include your GPU, driver version andhookshot_log.txt. Thanks!crashing also on 6800xt, freezing and closing the app.
RDNA2 report for the stall side of this tracker, v2.0.7 (source 9b541c9c), Windows 11, RX 6900 XT 16 GB (AMD proprietary 2.0.353 / Adrenalin 26.10.1), i7-9700K, 32 GB. Saves moved over from another build; Hyrule Field, then Castle Town and back out.
Picture: no green blobs or block squares on this card. Between stalls 38–41 fps (
vi: ... fps over the last 5.0 s). Terrain holes where the sky shows through the hills in Hyrule Field, which is #994. The image networks are left out as expected (not translated: a network left out on this card).Stalls: single submits of many seconds, nearly all of it in
draw:79 slow submits in that session. Leaving a house, breaking pots and opening the menu each brought one on. The lines right before the 43 s one were the terrain material arrays being decoded and re-encoded, with the texture budget at its cap:
So the textures sat at the 6 GB cap from
vk_texture.cpp(min(allowed * 0.7, 6 GB), the comment about 16 GB cards in #105/#106), with ~2.3 GB of the driver's allowance still unused. My guess was eviction and re-decode churn of those 90-layer arrays, so I tried:RX_VK_NOOPT=1RX_VK_NOOPT=1+RX_VK_VRAM_MB=8192So raising the budget didn't remove them, and I'm reporting this as data rather than a cause. What stands out is that the time is booked under
drawwithpipelinesnear zero, so it isn't the driver building pipelines (RX_VK_NOOPTis set). The build is gone from this PC now, so I can't capture more, but the numbers may help whoever looks at the AMD stalls.RX 6700 XT v2.0.9 data point (built from source, same settings as all our reports): the CPU-side fixes deliver real gains in bursts — GPU time dropped from 24-34 ms to 5.9 ms and fps hit 35.8 in open Hyrule Field (vs 17-30 on v2.0.7), with slow uploads nearly eliminated (4 vs 60+). But the core issues persist: 11 failed programs (same count as v2.0.7), memory still never released (3.5 GB imported, 0 retired given back), and town entries still overwhelm the texture pipeline (1.8 fps under load, 100+ pool imports at 50-57 ms each). The v2.0.9 texture fixes (#961/#963) help retention but don't fix the import speed or the compute program failures. Happy to test any instrumented build that targets the failed programs.
RX 7800 XT / Windows 11, main
0828863+ #1130, default settings: what the picture looked like and one log line that might matter.program … not translated: a network left out on this card, 10 rejected computes on 1920x1080 targets). Textures and shadows look posterised in places (flat patches on Link's face, on rock and on the frozen ground in Zora's Domain); on my earlier build, which ran the TAAU network for real on this card, the same kind of scene looked smooth. I have not yet put one next to the other in the same spot, so this is a guess.vk: storage buffer NOT bound (reads zeros): program da7a7ab28b8e73d9 stage 1 c5+0 addr 0x4180000000000200 size 0x20. It is a vertex stage reading its buffer from constant c5 with an address whose high word is0x41800000(16.0 as a float), the same kind of case as the comment inglobal_memory_to_storage_buffer_pass.cppabout foliage programs taking float constants for a buffer address. It prints from about a minute after the start (the log stops at 40 lines), so I cannot tell if it is the program that draws the Zoras. A vertex stage reading zeros could break an animation, but that is only a suspicion. I will check it on a session in Zora's Domain with the program's buffers logged.Two open fixes for AMD, tested on an RX 5500M:
Status from an RX 7800 XT (RDNA3, Windows 11, v2.0.12), in case it helps this tracker. Everything here is linked to where it is discussed; nothing is a confirmed fix.
matrix multiplies in software (the cooperative matrices lack 16x8x16 f16); the default for the TAAU network is then the stand-in. Experiments with a 16x16x16 path: #1284 (comment below the first one).RX_VK_PRESENT_QUEUE=1on; one session, no A/B, details and the NEAREST sampler list in #1117.6f76660; a possible cause (uncleared staging tail) is in that PR's thread, unverified.Summary for this tracker: what I have found on an RX 7800 XT (RDNA3, 16 GB, Windows 11, driver 0x8001a0, Ryzen 7 5800X3D) with builds based on v2.0.12, in one place, each linked to where the detail is. Everything marked hypothesis is not confirmed; nothing here is a finished fix.
Confirmed on this card
RX_VK_FSR_FG=0removes it; frames are then also evenly spaced (600 of 600 shown frames 7-9 ms, against ~16% in 9-12 ms with FSR). Same as @SaKenLpB's report. #1588, #995.5aae8ca50840019464x64,3e753d8ad4012b7b130x130), and this driver exposesVK_EXT_attachment_feedback_loop_layout(hypothesis: the grey squares). #1117.RX_VK_PRESENT_QUEUE=1coincided with no squares in ~10 minutes in two places (one session; hypothesis: timing hides a race). #1117.Checked and not as first thought (so nobody repeats it)
texture_frame()bumpsdestroy_gen); the cost is a descriptor rebuild after every deferring frame, not a stuck texture. #995.What this driver also exposes (for anyone looking at CPU cost or hangs):
VK_EXT_descriptor_buffer,VK_EXT_device_fault,VK_AMD_buffer_marker,VK_EXT_graphics_pipeline_library,VK_EXT_shader_object,VK_EXT_device_generated_commands,VK_KHR_pipeline_binary,VK_EXT_memory_priority,VK_EXT_pageable_device_local_memory.I am preparing small, separate, default-off PRs (diagnostics for the stalls above, and the cooperative-matrix route as a draft) and will link them in the threads.
Issue still keeps happening after changing RX_VX_ASTC_RGBA=1, here is my log with my Rx 9070xt. Sidenote: Performance increased massively with editing this setting. Perfomance jumped from 60-80 to constantly over 200fps
hookshot_log.zip
Note on the ground/floor textures going wrong after playing for a while: a second player now sees it on v2.0.14 (Dodongo's Cavern 2F, the wooden floor smeared and streaked; reloading the save fixes it for a while), next to the RX 9070 XT report above (fixed by a restart). That pattern, getting worse with play time and cleared by a reload, may belong to the VRAM-growth family (#1710, #993) rather than to AMD only; the floor in Dodongo's is also #1717.
From Discord (aris, RX 9070 XT): the texture glitch started about 10 minutes into the first session, and it stays after restarting the game. Since a restart clears memory and VRAM, something kept on disk may be carrying it over.
Anyone seeing the same: please try this once and say whether it clears the glitch:
hookshot_programs*.bin(and its.idx) andmkw_vk_pipelines*.bin.If that clears it, a bad cached translated program is the lead.
The smeared / wrong floor textures aren't AMD-only: on Discord an RTX 5060 Ti 16 GB shows the same smeared floor in the Kakariko graveyard (v2.0.14, 40 fps), and an RX 9070 XT gets it at random places (Kokiri Forest, Hyrule Field, Death Mountain). With an NVIDIA card showing it too, the cause is most likely in Hookshot's own texture streaming or caches rather than the AMD driver. Related: #993, #1717, #1710.
More reports of this, collected here:
More reports of this, collected here:
Same on XFX AMD Radeon 6700XT running Windows 10 LTSC 2021 IoT
is it fixed?
Tracker upkeep note (merged pull requests and code checked against main
51da0464; no new test run was made for it).The older summary's ‘no anti-aliasing’ description is now too broad: main includes #1115's FXAA stand-in, #1552's guarded RGB9E5 gameplay fallback and #2166's fixed-resolution FSR path, alongside several subgroup and cloth fixes. Full native matrix-network support is still not present for every AMD device: main
51da0464selects 16×8×16 f16 hardware and otherwise retains network admission limits and stand-ins. #1975 owns staged-matrix support, with separate BC-attachment and RADV-shuffle work in #2001 and #1893. Please mark the completed subcases but keep this tracker open; a ‘network left out’ message alone does not diagnose a texture-decoding failure.