Blown-out brightness / glitches on AMD RX 9060 XT: 10 “network” compute programs rejected (cooperative matrix 16x8x16 f16) #196

Closed

opened 2026-11-07 15:22:24 +00:00 by luscakk · 1 comment

luscakk commented

2026-11-07 15:22:24 +00:00

(Migrated from github.com)

Hi,

Disclosure: I asked Claude to analyze my log and write this report, including the suggested solutions. I’m not a graphics developer, so the diagnosis and the proposed fixes are AI-generated hypotheses based on the log. They may be wrong or incomplete. The log excerpts and shader hashes are real and copied directly from my attached log, so please verify them against your own knowledge of the renderer.

I’m getting blown-out brightness and other graphical glitches on an AMD Radeon RX 9060 XT (Vulkan 1.4). Going through the log, this is what seems to be the cause.

What the log shows

At boot:

vk: matrix multiplies in software (the cooperative matrices lack 16x8x16 f16)

Shortly after the intro video, 10 compute programs are rejected:

vk: program not translated: a network left out on this card
vk: rejected compute (...) grid ...

Per-frame stats then report 0 programs (10 failed) and draws (12 skipped).

Rejected program hashes:

e409733c45530d75
8306877b7dc8784b
de3c10dba4ff39d3
a41c78faa56ccf7d
e959b9b1451491c0
5a4d7378db437fed
8b73eaee02efc5e4
14140d4c1dbe754f
4c2c129fe950b041
3f6f2b1d671badcd

These look like a post-process network chain. The inputs are 1920x1080 and 960x540 images, and the last one writes a 2560x1440 output (fmt 0x38). Since these passes are skipped, the frame doesn’t get its final processing, which would explain the blown-out brightness.

The TAAU network is also replaced by a simple upscale:

the TAAU network fd029a317a9a4b94 is stood in for (an upscale of its input)

Possible solutions (hypotheses)

Map the 16x8x16 f16 cooperative matrix to the 16x16x16 shape that RDNA3/RDNA4 exposes, padding the N dimension (or running two 16x8 tiles per 16x16 op). That may let the networks run natively on AMD.
Provide a generic fallback path for these networks, using plain compute with shared memory or subgroup ops instead of cooperative matrices. It would be slower but correct.
At minimum, add a safe passthrough (tone-mapped/identity output) when a network can’t be translated, instead of leaving the output image unwritten, so the frame doesn’t come out with wrong exposure.

Secondary observations

VRAM sits at the limit for much of the session (6805 MB used of 6805 MB allowed), with constant texture retiring and a few multi-second stalls (e.g. slow submit: 5306.0 ms).
Large ASTC textures are kept as BC3, which may add color artifacts. I’ll test with RX_VK_ASTC_RGBA8=1.

hookshot_log.txt

I’m happy to test any build or flag you want me to try. The full log is attached.

Thanks!

Hi, Disclosure: I asked Claude to analyze my log and write this report, including the suggested solutions. I’m not a graphics developer, so the diagnosis and the proposed fixes are AI-generated hypotheses based on the log. They may be wrong or incomplete. The log excerpts and shader hashes are real and copied directly from my attached log, so please verify them against your own knowledge of the renderer. I’m getting blown-out brightness and other graphical glitches on an AMD Radeon RX 9060 XT (Vulkan 1.4). Going through the log, this is what seems to be the cause. What the log shows At boot: vk: matrix multiplies in software (the cooperative matrices lack 16x8x16 f16) Shortly after the intro video, 10 compute programs are rejected: vk: program <hash> not translated: a network left out on this card vk: rejected compute <hash> (...) grid ... Per-frame stats then report 0 programs (10 failed) and draws (12 skipped). Rejected program hashes: e409733c45530d75 8306877b7dc8784b de3c10dba4ff39d3 a41c78faa56ccf7d e959b9b1451491c0 5a4d7378db437fed 8b73eaee02efc5e4 14140d4c1dbe754f 4c2c129fe950b041 3f6f2b1d671badcd These look like a post-process network chain. The inputs are 1920x1080 and 960x540 images, and the last one writes a 2560x1440 output (fmt 0x38). Since these passes are skipped, the frame doesn’t get its final processing, which would explain the blown-out brightness. The TAAU network is also replaced by a simple upscale: the TAAU network fd029a317a9a4b94 is stood in for (an upscale of its input) Possible solutions (hypotheses) Map the 16x8x16 f16 cooperative matrix to the 16x16x16 shape that RDNA3/RDNA4 exposes, padding the N dimension (or running two 16x8 tiles per 16x16 op). That may let the networks run natively on AMD. Provide a generic fallback path for these networks, using plain compute with shared memory or subgroup ops instead of cooperative matrices. It would be slower but correct. At minimum, add a safe passthrough (tone-mapped/identity output) when a network can’t be translated, instead of leaving the output image unwritten, so the frame doesn’t come out with wrong exposure. Secondary observations VRAM sits at the limit for much of the session (6805 MB used of 6805 MB allowed), with constant texture retiring and a few multi-second stalls (e.g. slow submit: 5306.0 ms). Large ASTC textures are kept as BC3, which may add color artifacts. I’ll test with RX_VK_ASTC_RGBA8=1. [hookshot_log.txt](https://github.com/user-attachments/files/34522412/hookshot_log.txt) I’m happy to test any build or flag you want me to try. The full log is attached. Thanks!

NotRexed commented

2026-11-07 19:39:17 +00:00

(Migrated from github.com)

Thanks. Lighting that is too bright (bloom, overexposure) or too dark (shadows, faces, NPCs) is tracked in #36. https://github.com/NotRexed/Hookshot/releases/tag/foliage-linux-updater brings EvilOOT's lighting work (Link, signs and ferns are lit again, and the game's own fog), so please try it; what remains is followed in #36. Closing as a duplicate.

❤️ 1

Commenting is not possible because the repository is archived.