MagicBeanDev/Hookshot

Archived

Watch

Fork 0

Flickering short white horizontal lines with Upscaler "Game's own" below 100% render resolution (RTX 2060 Super) #2455

Closed

opened 2026-11-11 19:49:39 +00:00 by MoonCloud02 · 3 comments

MoonCloud02 commented

2026-11-11 19:49:39 +00:00

(Migrated from github.com)

Hookshot version

Source build of main at b744b1ec (hookshot v2.1.0-rc.3-70-gb744b1ec, first line of the log), newer than v2.1.0.

What kind of problem

Graphics (missing, black or wrong-coloured things, lighting, flicker)

What happened

Short white horizontal lines flash on and off all over the picture, constantly.

Isolated by changing one setting at a time:

Upscaler	Render resolution	Lines
Game's own	Auto (dynamic) or any value below 100%	yes
Game's own	100%	no
AMD FSR 3.1	Auto	no
Off (no upscaling)	-	no

Anisotropic filtering ("Game's" vs 16x) makes no difference.

So it follows the game's own network upscaling from a smaller 3D. On this card the log says vk: native matrix multiplies on (cooperative matrices, the console's fragment layout checked), so the networks run on the native matrix path. It may be the NVIDIA/Turing counterpart of the AMD grid lines in #1006 (where the networks run in software). Possibly related: #2444 (white lines on an RX 6750 XT with the game's own upscaler, at 100% with frame generation on); here frame generation is off and 100% has no lines.

Where in the game

Kokiri Forest (start of the game).

How often

Every time: constantly, as long as the settings above are active.

Graphics card and driver version

NVIDIA GeForce RTX 2060 SUPER 8 GB, driver 610.62

CPU, RAM and operating system

16 GB RAM, Windows 11. Monitor 2560x1440 @ 144 Hz, game windowed, Output resolution 2048x1152 (the game's).

Changes from the defaults

Render resolution, Upscaler and Anisotropic filtering, as in the table above.

Note: the log also shows VRAM slightly over the driver's allowance (over the driver's video-memory allowance (6.8 of 6.7 GB)). The lines go away at 100% in the same scene, so that does not look like the cause.

Other software hooked into the game

No, nothing hooked in.

hookshot_log.txt

Attached in a comment below.

Screenshots or video

Attached in a comment below.

Before you send it

I'm on the newest release, or the problem is still there on it. (built from current main)
I searched the open issues for this problem.
I'm not attaching game files, keys, hookshot.exe, the .bin caches or saves.

### Hookshot version Source build of main at b744b1ec (`hookshot v2.1.0-rc.3-70-gb744b1ec`, first line of the log), newer than v2.1.0. ### What kind of problem Graphics (missing, black or wrong-coloured things, lighting, flicker) ### What happened Short white horizontal lines flash on and off all over the picture, constantly. Isolated by changing one setting at a time: | Upscaler | Render resolution | Lines | |---|---|---| | Game's own | Auto (dynamic) or any value below 100% | **yes** | | Game's own | 100% | no | | AMD FSR 3.1 | Auto | no | | Off (no upscaling) | - | no | Anisotropic filtering ("Game's" vs 16x) makes no difference. So it follows the game's own network upscaling from a smaller 3D. On this card the log says `vk: native matrix multiplies on (cooperative matrices, the console's fragment layout checked)`, so the networks run on the native matrix path. It may be the NVIDIA/Turing counterpart of the AMD grid lines in #1006 (where the networks run in software). Possibly related: #2444 (white lines on an RX 6750 XT with the game's own upscaler, at 100% with frame generation on); here frame generation is off and 100% has no lines. ### Where in the game Kokiri Forest (start of the game). ### How often Every time: constantly, as long as the settings above are active. ### Graphics card and driver version NVIDIA GeForce RTX 2060 SUPER 8 GB, driver 610.62 ### CPU, RAM and operating system 16 GB RAM, Windows 11. Monitor 2560x1440 @ 144 Hz, game windowed, Output resolution 2048x1152 (the game's). ### Changes from the defaults Render resolution, Upscaler and Anisotropic filtering, as in the table above. Note: the log also shows VRAM slightly over the driver's allowance (`over the driver's video-memory allowance (6.8 of 6.7 GB)`). The lines go away at 100% in the same scene, so that does not look like the cause. ### Other software hooked into the game No, nothing hooked in. ### hookshot_log.txt Attached in a comment below. ### Screenshots or video Attached in a comment below. ### Before you send it - [x] I'm on the newest release, or the problem is still there on it. (built from current main) - [x] I searched the open issues for this problem. - [x] I'm not attaching game files, keys, hookshot.exe, the .bin caches or saves.

MoonCloud02 commented

2026-11-11 19:52:11 +00:00

(Migrated from github.com)

hookshot_log.txt

[hookshot_log.txt](https://github.com/user-attachments/files/34703171/hookshot_log.txt) <img width="48" height="46" alt="image" src="https://github.com/user-attachments/assets/b13f9aab-352f-44f1-afd0-62c8d9719932" />

MoonCloud02 commented

2026-11-11 21:17:29 +00:00

(Migrated from github.com)

More data, measured instead of by eye. Build: main b744b1ec, RTX 2060 SUPER, driver 610.62, Windows 11. Kokiri Forest, from a save.

Method: the game was driven through the control bridge (scripts/hookshot_ctl.py launch --headless, option_set, 10 shots at 2048x1152 per setting). A detector counted the bars. A bar is 16 px wide and 2 rows tall, brighter than the rows above and below it, and drops off sharply at both ends. Only flickering places were counted: places seen in at most half of the shots, since static scene edges show up in every shot. Every run used a separate copy of the game folder with its own caches.

What the bars look like: 16 px wide at x % 16 == 0, 2 rows at y % 8 in {0, 1} of the 2048x1152 output, with a dark 1 px outline. They land in different places every frame.

Run (Upscaler "Game's own")	75% (1536x864)	100%
default (log: `native matrix multiplies on (cooperative matrices ...)`)	40	4
`RX_VK_TAAU_KEYS=fd029a317a9a4b94` (the stand-in in place of the 4/3 network)	0	4
`RX_VK_MMA_SOFTWARE=1 RX_VK_TAAU_KEYS=-` (the same network, HMMA on subgroup shuffles)	3	4
`RX_VK_MMA_NO_LDSM_BARRIER=1`	54	2
Upscaler AMD FSR 3.1 (control)	1	-

(In the software run, only shots taken after the log's compute pipeline of fd029a317a9a4b94: SLOW compile line count; before that line the dispatch was left out.)

So: the bars come from the 4/3 gameplay network fd029a317a9a4b94, and only when it runs on the native cooperative-matrix path (HMMA_nx2 -> OpCooperativeMatrixMulAddKHR, emit_spirv_warp.cpp). The same network on the software HMMA path is clean. Removing the LDSM subgroup barriers makes it somewhat worse (40 -> 54, a single run each, so possibly noise). The 16-wide, 2-row tile alignment points at the matrix fragments.

Not yet known which part of the cooperative-matrix path is at fault. Candidates I'm checking next: whether an OpCooperativeMatrixMulAddKHR runs in subgroup-non-uniform control flow in this program, and shared-memory ordering around it beyond LDSM. seedds/nxnative saw a similar symptom with the same NDSR networks on Metal ("dotted horizontal rows" / "LDSM reads rows other lanes stored" / "An HMMA outside a chain overwrote the chain's accumulator" in their docs/reference/shaders.md). Their causes were specific to their translator, but the symptom matches.

Workaround for players meanwhile: Upscaler AMD FSR 3.1, or Render resolution 100%.

[Posted with the help of an AI agent (Hermes) on my machine; I reviewed the numbers.]

More data, measured instead of by eye. Build: main b744b1ec, RTX 2060 SUPER, driver 610.62, Windows 11. Kokiri Forest, from a save. **Method:** the game was driven through the control bridge (`scripts/hookshot_ctl.py launch --headless`, `option_set`, 10 `shot`s at 2048x1152 per setting). A detector counted the bars. A bar is 16 px wide and 2 rows tall, brighter than the rows above and below it, and drops off sharply at both ends. Only *flickering* places were counted: places seen in at most half of the shots, since static scene edges show up in every shot. Every run used a separate copy of the game folder with its own caches. **What the bars look like:** 16 px wide at `x % 16 == 0`, 2 rows at `y % 8 in {0, 1}` of the 2048x1152 output, with a dark 1 px outline. They land in different places every frame. | Run (Upscaler "Game's own") | 75% (1536x864) | 100% | |---|---|---| | default (log: `native matrix multiplies on (cooperative matrices ...)`) | **40** | 4 | | `RX_VK_TAAU_KEYS=fd029a317a9a4b94` (the stand-in in place of the 4/3 network) | **0** | 4 | | `RX_VK_MMA_SOFTWARE=1 RX_VK_TAAU_KEYS=-` (the same network, HMMA on subgroup shuffles) | **3** | 4 | | `RX_VK_MMA_NO_LDSM_BARRIER=1` | **54** | 2 | | Upscaler AMD FSR 3.1 (control) | 1 | - | (In the software run, only shots taken after the log's `compute pipeline of fd029a317a9a4b94: SLOW compile` line count; before that line the dispatch was left out.) **So:** the bars come from the 4/3 gameplay network `fd029a317a9a4b94`, and only when it runs on the native cooperative-matrix path (`HMMA_nx2` -> `OpCooperativeMatrixMulAddKHR`, `emit_spirv_warp.cpp`). The same network on the software HMMA path is clean. Removing the LDSM subgroup barriers makes it somewhat worse (40 -> 54, a single run each, so possibly noise). The 16-wide, 2-row tile alignment points at the matrix fragments. Not yet known which part of the cooperative-matrix path is at fault. Candidates I'm checking next: whether an `OpCooperativeMatrixMulAddKHR` runs in subgroup-non-uniform control flow in this program, and shared-memory ordering around it beyond LDSM. seedds/nxnative saw a similar symptom with the same NDSR networks on Metal ("dotted horizontal rows" / "LDSM reads rows other lanes stored" / "An HMMA outside a chain overwrote the chain's accumulator" in their `docs/reference/shaders.md`). Their causes were specific to their translator, but the symptom matches. Workaround for players meanwhile: Upscaler AMD FSR 3.1, or Render resolution 100%. [Posted with the help of an AI agent (Hermes) on my machine; I reviewed the numbers.]

NotRexed commented

2026-11-11 21:30:43 +00:00

(Migrated from github.com)

Thanks for the report. Reports of the same problem are now collected in #2511, which lists this one with your details and links back here, so one fix closes them together and the open list stays readable. Follow #2511 for the fix, and add new details there (or here). If this turns out to be a separate problem it will be reopened.

Commenting is not possible because the repository is archived.