MagicBeanDev/Hookshot

Archived

Watch

Fork 0

FSR 3.1 Issue #1829

Closed

opened 2026-11-10 17:45:08 +00:00 by RivalQuits · 4 comments

RivalQuits commented

2026-11-10 17:45:08 +00:00

(Migrated from github.com)

Hookshot version

v2.0.14

What kind of problem

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

What happened

FSR 3.1 Looks noticeably worse. I don't think the upscaler is working. I've attatched some pictures which hopefully show the difference between FSR 3.1 on and off.

Where in the game

Hyrule Field

How often

Every time

Graphics card and driver version

RX 9060 XT Driver 26.10.1

CPU, RAM and operating system

Ryzen 5 7600X3D, 32GB RAM, Windows 11

Changes from the defaults

No response

Other software hooked into the game

No, nothing hooked in

hookshot_log.txt

Screenshots or video

FSR Off

FSR On

FSR On Menu Options

Before you send it

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

### Hookshot version v2.0.14 ### What kind of problem Graphics (missing, black or wrong-coloured things, lighting, flicker) ### What happened FSR 3.1 Looks noticeably worse. I don't think the upscaler is working. I've attatched some pictures which hopefully show the difference between FSR 3.1 on and off. ### Where in the game Hyrule Field ### How often Every time ### Graphics card and driver version RX 9060 XT Driver 26.10.1 ### CPU, RAM and operating system Ryzen 5 7600X3D, 32GB RAM, Windows 11 ### Changes from the defaults _No response_ ### Other software hooked into the game No, nothing hooked in ### hookshot_log.txt [hookshot_log.txt](https://github.com/user-attachments/files/34642644/hookshot_log.txt) ### Screenshots or video FSR Off <img width="1280" height="720" alt="Image" src="https://github.com/user-attachments/assets/51d1e605-6764-4861-9e58-c53542ff6957" /> FSR On <img width="1280" height="720" alt="Image" src="https://github.com/user-attachments/assets/bf3d2706-c67c-4759-a1de-9a41e6e27f75" /> FSR On Menu Options <img width="1280" height="720" alt="Image" src="https://github.com/user-attachments/assets/132f369b-c201-4564-bba3-7bdf9222e7e3" /> ### Before you send it - [x] I'm on the newest release, or the problem is still there on it. - [x] I searched the open issues for this problem. - [x] I'm not attaching game files, keys, hookshot.exe, the .bin caches or saves.

manefaces commented

2026-11-10 21:40:46 +00:00

(Migrated from github.com)

I know wahr you mean, happen for me also FSR isn't reall yusable. The Nativ Upscaler (games own ist way to sharp and crisp so it causes flickering and totally ugly images especialy if you stream the game to another device (steam link). because every thinmd is sharp i mean everything even far awy object ar directly in (your nose). is there a possibility to achive a look like the NX2navi port creates. it looks abolutley great but ther FG is totally bad not reall usabel either. the FG of hookshot is amazing 170 fps all the time!

I know wahr you mean, happen for me also FSR isn't reall yusable. The Nativ Upscaler (games own ist way to sharp and crisp so it causes flickering and totally ugly images especialy if you stream the game to another device (steam link). because every thinmd is sharp i mean everything even far awy object ar directly in (your nose). is there a possibility to achive a look like the [NX2navi](https://github.com/tangerineturtle1/NX2navi) port creates. it looks abolutley great but ther FG is totally bad not reall usabel either. the FG of hookshot is amazing 170 fps all the time!

rakefire-impala commented

2026-11-11 04:12:37 +00:00

(Migrated from github.com)

What happens

OoT draws its 3D at a lower size and scales it up with a network of its own, one per share of the output: fd029a317a9a4b94 at 3/4, 9dc98871eb7fc101 at full size, and others for the other shares (72ba090c70fe2614 at 1/2). FSR 3.1 takes the place of that network's dispatch.

Fixed steps (Quality 67%, Balanced 58%, Performance 50%, Ultra Performance 33%): on a non-NVIDIA card only fd029a31 and 9dc98871 are kept by default (vk_shader.cpp, RX_VK_NETWORK_KEEP). The other shares' networks are left out ("not translated: a network left out on this card"). A left-out network's dispatch goes to upscale_stub, a plain stretch (vk_draw.cpp, the cp->failed branch in dispatch), before the FSR 3.1 hook (fsr3_stand_in, further down in the same function) is reached. So the 3D is stretched without FSR 3.1, while the menu still says FSR 3.1.
- Seen at Performance on the RX 5500M: the 3D at 768x432, rejected compute 72ba090c70fe2614 ... 768x432 ... 1536x864, and not one fsr3 line after AMD FSR 3.1 can run on this GPU in two sessions. The picture is a blocky 2x stretch with no anti-aliasing.
- Your log has 72ba090c70fe2614 not translated: a network left out on this card and one rejected compute 72ba090c... too.
- 67%, 58% and 33% go the same way by the code. I only watched 50%.
Full size (9dc98871): FSR 3.1 runs with the same size in and out, fsr3 2560x1440 -> 2560x1440 in your log and 1536x864 -> 1536x864 here. There it only anti-aliases, and both logs show jitter -0.000 +0.000 px on its first frame.
3/4 (fd029a31): your log has fsr3: 1920x1080 -> 2560x1440, so FSR 3.1 does upscale there.

Neither log reaches FSR 3.1's frames drawn line, which it prints every 600 frames it draws, so in both sessions it drew fewer than 600 frames. I haven't found why yet. It may be the game's dynamic resolution moving to shares whose networks are left out.

Workaround for now: with FSR 3.1 selected, Render resolution "Auto" is the only setting where it gets used on these cards. Adding the share networks to RX_VK_NETWORK_KEEP isn't a good workaround: the network's pipeline starts compiling before the FSR hook runs, and those compiles took AMD's compiler a long time before (why they were left out).

Possible fix: let FSR 3.1 (and the other engines) take a left-out network of the upscale shape (one texture in, one image out, cooperative matrices) before upscale_stub, the way the TAAU stand-in's network is kept but never compiled (taau_key). Fall back to the stretch only when the engine declines. The menu could also say when the stretch is drawn instead of the chosen upscaler.

Related: #1006 (AMD: no anti-aliasing, networks in software).

I can confirm this on an RX 5500M (RDNA1, Windows) and found where it comes from. Your log (RX 9060 XT, v2.0.14) shows the same signature. On a card where the game's upscale networks are left out, which is any non-NVIDIA card, FSR 3.1 is only used for two of the game's networks. At FSR 3.1's own Render resolution steps it doesn't run at all. **What happens** OoT draws its 3D at a lower size and scales it up with a network of its own, one per share of the output: `fd029a317a9a4b94` at 3/4, `9dc98871eb7fc101` at full size, and others for the other shares (`72ba090c70fe2614` at 1/2). FSR 3.1 takes the place of that network's dispatch. - **Fixed steps (Quality 67%, Balanced 58%, Performance 50%, Ultra Performance 33%):** on a non-NVIDIA card only `fd029a31` and `9dc98871` are kept by default (`vk_shader.cpp`, `RX_VK_NETWORK_KEEP`). The other shares' networks are left out ("not translated: a network left out on this card"). A left-out network's dispatch goes to `upscale_stub`, a plain stretch (`vk_draw.cpp`, the `cp->failed` branch in `dispatch`), before the FSR 3.1 hook (`fsr3_stand_in`, further down in the same function) is reached. So the 3D is stretched without FSR 3.1, while the menu still says FSR 3.1. - Seen at Performance on the RX 5500M: the 3D at 768x432, `rejected compute 72ba090c70fe2614 ... 768x432 ... 1536x864`, and not one `fsr3` line after `AMD FSR 3.1 can run on this GPU` in two sessions. The picture is a blocky 2x stretch with no anti-aliasing. - Your log has `72ba090c70fe2614 not translated: a network left out on this card` and one `rejected compute 72ba090c...` too. - 67%, 58% and 33% go the same way by the code. I only watched 50%. - **Full size (`9dc98871`):** FSR 3.1 runs with the same size in and out, `fsr3 2560x1440 -> 2560x1440` in your log and `1536x864 -> 1536x864` here. There it only anti-aliases, and both logs show `jitter -0.000 +0.000 px` on its first frame. - **3/4 (`fd029a31`):** your log has `fsr3: 1920x1080 -> 2560x1440`, so FSR 3.1 does upscale there. Neither log reaches FSR 3.1's `frames drawn` line, which it prints every 600 frames it draws, so in both sessions it drew fewer than 600 frames. I haven't found why yet. It may be the game's dynamic resolution moving to shares whose networks are left out. **Workaround for now:** with FSR 3.1 selected, Render resolution "Auto" is the only setting where it gets used on these cards. Adding the share networks to `RX_VK_NETWORK_KEEP` isn't a good workaround: the network's pipeline starts compiling before the FSR hook runs, and those compiles took AMD's compiler a long time before (why they were left out). **Possible fix:** let FSR 3.1 (and the other engines) take a left-out network of the upscale shape (one texture in, one image out, cooperative matrices) before `upscale_stub`, the way the TAAU stand-in's network is kept but never compiled (`taau_key`). Fall back to the stretch only when the engine declines. The menu could also say when the stretch is drawn instead of the chosen upscaler. Related: #1006 (AMD: no anti-aliasing, networks in software).

👍 1

bunbeans2-arch commented

2026-11-11 10:28:42 +00:00

(Migrated from github.com)

67% (Quality) goes the same way. With the Upscaler row on FSR 3.1 and Render resolution at 67%:

vk: program 6676619641320ba7 not translated: a network left out on this card
vk: rejected compute 6676619641320ba7 ... 2560x1440x1 ...
vk: typed upscale helper generic RGB9E5 fallback

No fsr3: N frames drawn line in about 5,400 presents after that, in two runs. The 3D is drawn at 2560x1440 and stretched.

The menu leads there by itself. Moving the Upscaler row from "Game's own" to FSR 3.1 while Render resolution is 100% moves Render resolution to 67% (the snap to the new upscaler's nearest step in vk_menu.cpp; the saved options had resolution=3 afterwards). So the plain way into FSR 3.1 lands on a step where it is not used on these cards. Auto stays Auto.

At Auto it does keep drawing, so the frames drawn line works. Setting Render resolution to Auto first and then the row to FSR 3.1:

vk: network fd029a317a9a4b94: dispatch 60x68x1, 1 textures 1 images: 2880x1620x1/122 3840x2160x1/122
vk: fsr3: 2880x1620 -> 3840x2160

and 16 frames drawn lines (600 to 9600) in one run, 17 in a second one, standing in the Market. So where the game's dynamic size stays on a kept network, FSR 3.1 draws every frame; a log without that line was most likely on a fixed step, or on a share that is left out.

Memory side (ties in with #2180). FSR 3.1's internal images are made on the first frame it draws and are then kept:

In the 67% case above it drew its first frame at 3840x2160 before the 67% size arrived, and the textures' image blocks went from 3,072 to 3,712 MB and stayed there while the stretch was drawing.
After the row goes back to "Game's own" they are not given back either: 3,486 MB of images before the switch, 3,498 MB after.

A small local change that drops them when FSR 3.1 is not wanted (a call from fsr3_stand_in before its early return, through the existing drop_image / free_dead path) took the images from 3,655 to 3,292 MB at the switch in the same test, and FSR 3.1 drew normally when the row was moved back to it (a new fsr3: 2880x1620 -> 3840x2160 line, frames drawn going on). The freed space stays inside the allocator's blocks, so the "used" figure does not fall by itself. I can post the diff if it is useful.

Confirming @rakefire-impala's diagnosis on an RX 9070 XT (Windows 11, v2.1.0, 3840x2160 output), with the 67% step watched and two things that may help. (Built from the v2.1.0 source with a few local diagnostic changes; none of them is in the network or upscale-stub path.) **67% (Quality) goes the same way.** With the Upscaler row on FSR 3.1 and Render resolution at 67%: ``` vk: program 6676619641320ba7 not translated: a network left out on this card vk: rejected compute 6676619641320ba7 ... 2560x1440x1 ... vk: typed upscale helper generic RGB9E5 fallback ``` No `fsr3: N frames drawn` line in about 5,400 presents after that, in two runs. The 3D is drawn at 2560x1440 and stretched. **The menu leads there by itself.** Moving the Upscaler row from "Game's own" to FSR 3.1 while Render resolution is 100% moves Render resolution to 67% (the snap to the new upscaler's nearest step in `vk_menu.cpp`; the saved options had `resolution=3` afterwards). So the plain way into FSR 3.1 lands on a step where it is not used on these cards. Auto stays Auto. **At Auto it does keep drawing, so the `frames drawn` line works.** Setting Render resolution to Auto first and then the row to FSR 3.1: ``` vk: network fd029a317a9a4b94: dispatch 60x68x1, 1 textures 1 images: 2880x1620x1/122 3840x2160x1/122 vk: fsr3: 2880x1620 -> 3840x2160 ``` and 16 `frames drawn` lines (600 to 9600) in one run, 17 in a second one, standing in the Market. So where the game's dynamic size stays on a kept network, FSR 3.1 draws every frame; a log without that line was most likely on a fixed step, or on a share that is left out. **Memory side (ties in with #2180).** FSR 3.1's internal images are made on the first frame it draws and are then kept: - In the 67% case above it drew its first frame at 3840x2160 before the 67% size arrived, and the textures' image blocks went from 3,072 to 3,712 MB and stayed there while the stretch was drawing. - After the row goes back to "Game's own" they are not given back either: 3,486 MB of images before the switch, 3,498 MB after. A small local change that drops them when FSR 3.1 is not wanted (a call from `fsr3_stand_in` before its early return, through the existing `drop_image` / `free_dead` path) took the images from 3,655 to 3,292 MB at the switch in the same test, and FSR 3.1 drew normally when the row was moved back to it (a new `fsr3: 2880x1620 -> 3840x2160` line, `frames drawn` going on). The freed space stays inside the allocator's blocks, so the "used" figure does not fall by itself. I can post the diff if it is useful.

NotRexed commented

2026-11-11 21:24:02 +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.