MagicBeanDev/Hookshot

Archived

Watch

Fork 0

Frame generation at a render resolution below 100% (4K output, 67% render): generated frames only cover the top-left 2560x1440 #1797

Closed

opened 2026-11-10 16:58:15 +00:00 by ldallacqua · 6 comments

ldallacqua commented

2026-11-10 16:58:15 +00:00

(Migrated from github.com)

Hookshot version

v2.0.13 (v2.0.14 came out today as a hotfix for HDR, the menu and bracketed build paths; not retested on it yet)

What kind of problem

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

What happened

With the output at 4K (3840x2160) and the render resolution at 67% (2560x1440), turning on frame generation breaks the picture: the generated frames only seem to cover the top-left 2560x1440 of the screen, the area the game actually renders at, instead of the whole 4K frame.

Expected: generated frames cover the full 3840x2160 output, as they would at a 100% render resolution.

The log suggests why: FSR 3.1 frame interpolation is set up at the 4K output size, but its depth and motion inputs are given at the 2560x1440 render size, with no scaling between them:

vk: fsr3fi: AMD FSR 3.1 makes the frame between each two of the game's (3840x2160, its depth and motion 2560x1440)
vk: fsr3fi: 3840x2160 from 2560x1440 inputs, flow 480x270, pyramid 1920x1080 with 11 levels, 1 made frame(s) (format 37)
vk: fsr3 inputs: 2560x1440, from the scene's projection: near 0.1000 far 25040.7 fov 50.00 deg, depth 0 at the near plane: reversed for FSR (p22 -1.00001 p23 -0.200001); camera motion from the depth, jitter -0.000 +0.000 px

1440p inputs read as if they were 4K would land in exactly the top-left 2560x1440 of the frame. In other runs with the same settings the log also shows FSR 3.1 not getting its inputs at all and the renderer's own interpolation taking over:

vk: fsr3fi: 0 of the last 600 made frames by FSR 3.1, 600 without its inputs (the renderer's own made them)

Seen with frame generation at 2x (frame interpolation ready: 2x the game's frames) and at Auto (frame interpolation ready: Auto, a frame for each of the display's refreshes (120 Hz; up to 4 a game frame)).

Where in the game

Everywhere in gameplay as soon as frame generation is on with a render resolution below 100%

How often

Every time

Graphics card and driver version

RTX 4090, NVIDIA 621.01 (the system also has the Ryzen's integrated AMD Radeon Graphics; the game picks the RTX 4090)

CPU, RAM and operating system

Ryzen 7 9800X3D, 32 GB, Windows 11 Pro 25H2

Changes from the defaults

Output resolution: 3840x2160 (4K), fullscreen
Render resolution: 67%
Frame generation: 2x (also seen at Auto)
NVIDIA Reflex: on
No hookshot_env.txt

Other software hooked into the game

No, nothing hooked in

hookshot_log.txt

I can't attach files from where I'm filing this, so the relevant lines are quoted above. I can attach the full logs from the runs with frame generation on if they help.

Screenshots or video

None yet.

Before you send it

I searched the open issues for this problem. (Closest ones are #1635 and #1588, about ghosting and the HUD in generated frames at 2x; neither covers the frame only filling the render-resolution corner.)
I'm not attaching game files, keys, hookshot.exe, the .bin caches or saves.

### Hookshot version v2.0.13 (v2.0.14 came out today as a hotfix for HDR, the menu and bracketed build paths; not retested on it yet) ### What kind of problem Graphics (missing, black or wrong-coloured things, lighting, flicker) ### What happened With the output at 4K (3840x2160) and the render resolution at 67% (2560x1440), turning on frame generation breaks the picture: the generated frames only seem to cover the top-left 2560x1440 of the screen, the area the game actually renders at, instead of the whole 4K frame. Expected: generated frames cover the full 3840x2160 output, as they would at a 100% render resolution. The log suggests why: FSR 3.1 frame interpolation is set up at the 4K output size, but its depth and motion inputs are given at the 2560x1440 render size, with no scaling between them: ``` vk: fsr3fi: AMD FSR 3.1 makes the frame between each two of the game's (3840x2160, its depth and motion 2560x1440) vk: fsr3fi: 3840x2160 from 2560x1440 inputs, flow 480x270, pyramid 1920x1080 with 11 levels, 1 made frame(s) (format 37) vk: fsr3 inputs: 2560x1440, from the scene's projection: near 0.1000 far 25040.7 fov 50.00 deg, depth 0 at the near plane: reversed for FSR (p22 -1.00001 p23 -0.200001); camera motion from the depth, jitter -0.000 +0.000 px ``` 1440p inputs read as if they were 4K would land in exactly the top-left 2560x1440 of the frame. In other runs with the same settings the log also shows FSR 3.1 not getting its inputs at all and the renderer's own interpolation taking over: ``` vk: fsr3fi: 0 of the last 600 made frames by FSR 3.1, 600 without its inputs (the renderer's own made them) ``` Seen with frame generation at 2x (`frame interpolation ready: 2x the game's frames`) and at Auto (`frame interpolation ready: Auto, a frame for each of the display's refreshes (120 Hz; up to 4 a game frame)`). ### Where in the game Everywhere in gameplay as soon as frame generation is on with a render resolution below 100% ### How often Every time ### Graphics card and driver version RTX 4090, NVIDIA 621.01 (the system also has the Ryzen's integrated AMD Radeon Graphics; the game picks the RTX 4090) ### CPU, RAM and operating system Ryzen 7 9800X3D, 32 GB, Windows 11 Pro 25H2 ### Changes from the defaults - Output resolution: 3840x2160 (4K), fullscreen - Render resolution: 67% - Frame generation: 2x (also seen at Auto) - NVIDIA Reflex: on - No hookshot_env.txt ### Other software hooked into the game No, nothing hooked in ### hookshot_log.txt I can't attach files from where I'm filing this, so the relevant lines are quoted above. I can attach the full logs from the runs with frame generation on if they help. ### Screenshots or video None yet. ### Before you send it - [x] I searched the open issues for this problem. (Closest ones are #1635 and #1588, about ghosting and the HUD in generated frames at 2x; neither covers the frame only filling the render-resolution corner.) - [x] I'm not attaching game files, keys, hookshot.exe, the .bin caches or saves.

BakedTator commented

2026-11-10 17:47:07 +00:00

(Migrated from github.com)

i have the rx 9070 xt, r7 7800 x3d, 32gb ddr5 5600

running at full res (2560x1440) and if i have 2x framegen on the hud and link smear and stutter...turning off framegen or setting it higher seem to be fine but 2x is really bad. just thought id back this up and let you know the issue is there

i have the rx 9070 xt, r7 7800 x3d, 32gb ddr5 5600 running at full res (2560x1440) and if i have 2x framegen on the hud and link smear and stutter...turning off framegen or setting it higher seem to be fine but 2x is really bad. just thought id back this up and let you know the issue is there

oscarlosu-lab commented

2026-11-10 20:36:55 +00:00

(Migrated from github.com)

I tried to reproduce this on current main (117eae7) and could not.

Setup: NVIDIA GeForce RTX 3060, Vulkan 1.4. Output 3840x2160, render resolution 67% (2560x1440), frame generation 2x, upscaler FSR 3, with RX_VK_FSR_FG=1 so that AMD FSR 3.1 frame interpolation is used (since eb5b9a0 it is opt-in; by default the 2x frames are made by the renderer's own blend).

What the log shows: fsr3fi: AMD FSR 3.1 makes the frame between each two of the game's (3840x2160, its depth and motion 2560x1440) and fsr3fi: 3840x2160 from 2560x1440 inputs, flow 480x270, pyramid 1920x1080 with 11 levels, then 600 of the last 600 made frames by FSR 3.1.

What the screen shows: I took 709 screenshots, one every 7th present, so about half are generated frames. None has only the top-left area drawn: the right and bottom thirds have picture in every one.

I also read the dispatch sizes and the constants in vk_fsr3fi.cpp against the FSR 3.1 SDK. The render and display sizes are passed as the SDK expects, so I found nothing there that would explain the report.

So this may depend on the GPU or driver. @ldallacqua, if you can still reproduce it on a current build, could you say which GPU and driver you have, and attach the fsr3fi: lines of hookshot_log.txt and a screenshot of a bad frame? Without those I would not change the code.

(@BakedTator's report is a different case: full 2560x1440, no render scaling.)

I tried to reproduce this on current `main` (117eae7) and could not. **Setup:** NVIDIA GeForce RTX 3060, Vulkan 1.4. Output 3840x2160, render resolution 67% (2560x1440), frame generation 2x, upscaler FSR 3, with `RX_VK_FSR_FG=1` so that AMD FSR 3.1 frame interpolation is used (since eb5b9a0 it is opt-in; by default the 2x frames are made by the renderer's own blend). **What the log shows:** `fsr3fi: AMD FSR 3.1 makes the frame between each two of the game's (3840x2160, its depth and motion 2560x1440)` and `fsr3fi: 3840x2160 from 2560x1440 inputs, flow 480x270, pyramid 1920x1080 with 11 levels`, then `600 of the last 600 made frames by FSR 3.1`. **What the screen shows:** I took 709 screenshots, one every 7th present, so about half are generated frames. None has only the top-left area drawn: the right and bottom thirds have picture in every one. I also read the dispatch sizes and the constants in `vk_fsr3fi.cpp` against the FSR 3.1 SDK. The render and display sizes are passed as the SDK expects, so I found nothing there that would explain the report. So this may depend on the GPU or driver. @ldallacqua, if you can still reproduce it on a current build, could you say which GPU and driver you have, and attach the `fsr3fi:` lines of `hookshot_log.txt` and a screenshot of a bad frame? Without those I would not change the code. (@BakedTator's report is a different case: full 2560x1440, no render scaling.)

RageGreeny commented

2026-11-10 21:55:21 +00:00

(Migrated from github.com)

I have the same issue, 2x framegen only covers that area of the screen too.
5090, GPU driver 621.01
fsr3fi: 17 pass pipelines ready
[hos Presentation Thread] vk: fsr3fi: 3840x2160 from 2560x1440 inputs, flow 480x270, pyramid 1920x1080 with 11 levels, 1 made frame(s) (format 37)

I have the same issue, 2x framegen only covers that area of the screen too. 5090, GPU driver 621.01 fsr3fi: 17 pass pipelines ready [hos Presentation Thread] vk: fsr3fi: 3840x2160 from 2560x1440 inputs, flow 480x270, pyramid 1920x1080 with 11 levels, 1 made frame(s) (format 37)

ldallacqua commented

2026-11-10 22:44:16 +00:00

(Migrated from github.com)

@oscarlosu-lab Thanks for testing this. The issue is still happening here. I've attached the bad frame, an annotated copy of the same image, and all the fsr3fi: lines from my current log.

GPU / driver: NVIDIA GeForce RTX 4090, NVIDIA 621.01, confirmed with nvidia-smi. Hookshot reports Vulkan 1.4 and driver 0x9b404000. The renderer selects the RTX 4090.

Build: v2.0.14, source 3a9998c3. I have not tested your main commit 117eae7.

Settings in this session: 3840x2160 output, 2880x1620 inputs (75% per axis), DLSS upscaling, and Auto frame generation. This differs from the original 67% / 2560x1440 report and your FSR 3 upscaling / 2x test.

The screenshot shows a rectangular discontinuity whose right and bottom boundaries are at roughly 75% of the image width and height. This is consistent with the input/output size ratio in the log, although it does not establish the cause. The red line is my annotation to highlight the boundary; it is not part of the rendering defect. Both images are the same captured frame. The on-screen counter shows 120 FPS with game 59.

Relevant lines from the current hookshot_log.txt:

[hos host] hookshot v2.0.14 (source 3a9998c3)
[hos host] vk: NVIDIA GeForce RTX 4090, Vulkan 1.4, driver 0x9b404000; mesh shaders yes, host memory import yes, pipeline libraries yes
[hos Presentation Thread] vk: NVIDIA DLSS draws OoT's upscale: 2880x1620 -> 3840x2160
[hos Presentation Thread] vk: frame interpolation ready: Auto, a frame for each of the display's refreshes (120 Hz; up to 4 a game frame)
[hos host] vk: fsr3fi: AMD FSR 3.1 frame interpolation can run on this GPU
[hos Presentation Thread] vk: fsr3fi: 17 pass pipelines ready
[hos Presentation Thread] vk: fsr3fi: 3840x2160 from 2880x1620 inputs, flow 480x270, pyramid 1920x1080 with 11 levels, 1 made frame(s) (format 37)
[hos Presentation Thread] vk: fsr3fi: AMD FSR 3.1 makes the frame between each two of the game's (3840x2160, its depth and motion 2880x1620)
[hos Presentation Thread] vk: fsr3fi: 600 of the last 600 made frames by FSR 3.1, 0 without its inputs (the renderer's own made them)

Later in the same session the log also records mixed counts and periods with 0 of the last 600 made frames by FSR 3.1, 600 without its inputs (the renderer's own made them). I cannot correlate those individual intervals with the exact instant of this screenshot. The attached text file includes all the fsr3fi: entries captured from this session, plus build, GPU, resolution and input context.

My hookshot_env.txt contains only:

RX_VK_WAIT_GPU=0

It does not set RX_VK_FSR_FG; this release explicitly logs AMD FSR 3.1 interpolation being used.

Attachments: original bad frame, annotated copy, and log excerpt

Original:

Same frame with the boundary marked in red:

All fsr3fi lines and diagnostic context

@oscarlosu-lab Thanks for testing this. The issue is still happening here. I've attached the bad frame, an annotated copy of the same image, and all the `fsr3fi:` lines from my current log. **GPU / driver:** NVIDIA GeForce RTX 4090, NVIDIA **621.01**, confirmed with `nvidia-smi`. Hookshot reports Vulkan 1.4 and driver `0x9b404000`. The renderer selects the RTX 4090. **Build:** **v2.0.14**, source `3a9998c3`. I have not tested your `main` commit `117eae7`. **Settings in this session:** 3840x2160 output, 2880x1620 inputs (75% per axis), DLSS upscaling, and **Auto** frame generation. This differs from the original 67% / 2560x1440 report and your FSR 3 upscaling / 2x test. The screenshot shows a rectangular discontinuity whose right and bottom boundaries are at roughly 75% of the image width and height. This is consistent with the input/output size ratio in the log, although it does not establish the cause. **The red line is my annotation to highlight the boundary; it is not part of the rendering defect.** Both images are the same captured frame. The on-screen counter shows 120 FPS with `game 59`. Relevant lines from the current `hookshot_log.txt`: ```text [hos host] hookshot v2.0.14 (source 3a9998c3) [hos host] vk: NVIDIA GeForce RTX 4090, Vulkan 1.4, driver 0x9b404000; mesh shaders yes, host memory import yes, pipeline libraries yes [hos Presentation Thread] vk: NVIDIA DLSS draws OoT's upscale: 2880x1620 -> 3840x2160 [hos Presentation Thread] vk: frame interpolation ready: Auto, a frame for each of the display's refreshes (120 Hz; up to 4 a game frame) [hos host] vk: fsr3fi: AMD FSR 3.1 frame interpolation can run on this GPU [hos Presentation Thread] vk: fsr3fi: 17 pass pipelines ready [hos Presentation Thread] vk: fsr3fi: 3840x2160 from 2880x1620 inputs, flow 480x270, pyramid 1920x1080 with 11 levels, 1 made frame(s) (format 37) [hos Presentation Thread] vk: fsr3fi: AMD FSR 3.1 makes the frame between each two of the game's (3840x2160, its depth and motion 2880x1620) [hos Presentation Thread] vk: fsr3fi: 600 of the last 600 made frames by FSR 3.1, 0 without its inputs (the renderer's own made them) ``` Later in the same session the log also records mixed counts and periods with `0 of the last 600 made frames by FSR 3.1, 600 without its inputs (the renderer's own made them)`. I cannot correlate those individual intervals with the exact instant of this screenshot. The attached text file includes all the `fsr3fi:` entries captured from this session, plus build, GPU, resolution and input context. My `hookshot_env.txt` contains only: ```text RX_VK_WAIT_GPU=0 ``` It does not set `RX_VK_FSR_FG`; this release explicitly logs AMD FSR 3.1 interpolation being used. **Attachments: original bad frame, annotated copy, and log excerpt** Original: ![Bad frame — original](https://github.com/user-attachments/assets/d5b4122e-dbf5-4afb-8782-f7c54b9933b2) Same frame with the boundary marked in red: ![Bad frame — red annotation](https://github.com/user-attachments/assets/8dcb5017-79bc-4ef7-839f-23b8ae769747) [All fsr3fi lines and diagnostic context](https://github.com/user-attachments/files/34654737/hookshot-fsr3fi.txt)

mooki000 commented

2026-11-11 16:45:31 +00:00

(Migrated from github.com)

I can reproduce this on Linux, but only while the picture moves, and pull request #1943 removes it here.

Setup: RTX 4090, NVIDIA 615.78.08, Arch Linux, Hyprland (Wayland), a 1920x1080 window at 60 Hz, main bdfe09c. Output 3840x2160, render resolution 67 % (2560x1440), FSR 3 as the upscaler, frame generation 2x, RX_VK_FSR_FG=1: @oscarlosu-lab's setup, on another card. The log has the report's line fsr3fi: 3840x2160 from 2560x1440 inputs, flow 480x270, pyramid 1920x1080 with 11 levels, and FSR 3.1 made the frames: 595 of the last 600 made frames by FSR 3.1, 0 without its inputs. Kokiri Forest from a save; made frames captured with RX_VK_SHOT_MADE=1 at 1920x1080, one every 120 game frames.

Link and the camera still: nothing to see. None of the 8 made frames differs from the game's frame after it by more than 2 of 255 luma levels on average.
Link running and the camera turning: the made frames have an edge at two thirds of the width and of the height (x=1280 and y=720 of 1920x1080), which the game's frames do not have. Inside that top-left corner the picture is moved and smeared, and outside it the picture does not follow (pictures 1 and 3 below show the right third). That corner is the 2560x1440 of the report; the red line in the screenshot above sits at 75 % for 2880x1620 inputs.
The same run with #1943 (it builds the interpolation with the SDK's name for low-resolution motion vectors): no edge on either line.

Run	Build	What	Start	Load before -> after	Pairs from present 1680 (in motion)	Edge on x=1280, made / game frame (median)	Edge on y=720, made / game frame (median)
wr-fi-base	`bdfe09c`	main, Link and camera still	07:46	106.15 -> 127.07	8 (0)	- (none in motion)	- (none in motion)
wr-fim-base	`bdfe09c`	main, camera turning	09:32	11.01 -> 7.72	26 (17)	1.42 / 1.04	1.47 / 1.00
wr-fim-1943	3625f7fc	#1943, camera turning	08:01	73.28 -> 107.78	10 (10)	1.03 / 1.00	0.98 / 1.02

"Edge" is how much the picture changes across the line x=1280 (top 720 rows) or y=720 (left 1280 columns), divided by the change across the lines next to it: 1.00 means the line looks like its neighbours. A pair is in motion when the made frame differs from the game frame after it by more than 2 of 255 luma levels on average.

Main: a made frame while the camera turns, with an edge at the red marks (two thirds of the width).
Main: the game's frame after it, with no edge there.
Main: a made frame while Link runs. The left two thirds are smeared, the right third is not.
#1943: a made frame while Link runs. The whole picture moves together, with no edge.

Not tested: DLSS as the upscaler and frame generation Auto (the report's later setup; this build has no DLSS), 120 Hz, Windows, driver 621.01. The runs were not taken at the same load, so I give no frame rates.

I can reproduce this on Linux, but only while the picture moves, and pull request #1943 removes it here. **Setup:** RTX 4090, NVIDIA 615.78.08, Arch Linux, Hyprland (Wayland), a 1920x1080 window at 60 Hz, main bdfe09c. Output 3840x2160, render resolution 67 % (2560x1440), FSR 3 as the upscaler, frame generation 2x, `RX_VK_FSR_FG=1`: @oscarlosu-lab's setup, on another card. The log has the report's line `fsr3fi: 3840x2160 from 2560x1440 inputs, flow 480x270, pyramid 1920x1080 with 11 levels`, and FSR 3.1 made the frames: `595 of the last 600 made frames by FSR 3.1, 0 without its inputs`. Kokiri Forest from a save; made frames captured with `RX_VK_SHOT_MADE=1` at 1920x1080, one every 120 game frames. - **Link and the camera still:** nothing to see. None of the 8 made frames differs from the game's frame after it by more than 2 of 255 luma levels on average. - **Link running and the camera turning:** the made frames have an edge at two thirds of the width and of the height (x=1280 and y=720 of 1920x1080), which the game's frames do not have. Inside that top-left corner the picture is moved and smeared, and outside it the picture does not follow (pictures 1 and 3 below show the right third). That corner is the 2560x1440 of the report; the red line in the screenshot above sits at 75 % for 2880x1620 inputs. - **The same run with #1943** (it builds the interpolation with the SDK's name for low-resolution motion vectors): no edge on either line. | Run | Build | What | Start | Load before -> after | Pairs from present 1680 (in motion) | Edge on x=1280, made / game frame (median) | Edge on y=720, made / game frame (median) | |---|---|---|---|---|---|---|---| | wr-fi-base | bdfe09c | main, Link and camera still | 07:46 | 106.15 -> 127.07 | 8 (0) | - (none in motion) | - (none in motion) | | wr-fim-base | bdfe09c | main, camera turning | 09:32 | 11.01 -> 7.72 | 26 (17) | 1.42 / 1.04 | 1.47 / 1.00 | | wr-fim-1943 | 3625f7fc | #1943, camera turning | 08:01 | 73.28 -> 107.78 | 10 (10) | 1.03 / 1.00 | 0.98 / 1.02 | "Edge" is how much the picture changes across the line x=1280 (top 720 rows) or y=720 (left 1280 columns), divided by the change across the lines next to it: 1.00 means the line looks like its neighbours. A pair is in motion when the made frame differs from the game frame after it by more than 2 of 255 luma levels on average. ![Made frames on main and with #1943, the two-thirds lines marked](https://gist.githubusercontent.com/mooki000/b86bd3f35969803fb032f71f035844f8/raw/ee9a2d54d35f405b52a2f6304418290995f71fa7/hookshot-fsr3fi-made-frames.jpg) 1. Main: a made frame while the camera turns, with an edge at the red marks (two thirds of the width). 2. Main: the game's frame after it, with no edge there. 3. Main: a made frame while Link runs. The left two thirds are smeared, the right third is not. 4. #1943: a made frame while Link runs. The whole picture moves together, with no edge. **Not tested:** DLSS as the upscaler and frame generation Auto (the report's later setup; this build has no DLSS), 120 Hz, Windows, driver 621.01. The runs were not taken at the same load, so I give no frame rates.

NotRexed commented

2026-11-11 21:23:52 +00:00

(Migrated from github.com)

Thanks for the report. Reports of the same problem are now collected in #2510, which lists this one with your details and links back here, so one fix closes them together and the open list stays readable. Follow #2510 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.