Lower FPS when moving to a new area. #2780
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
1 participant
No due date set.
Dependencies
No dependencies set
Reference
MagicBeanDev/Hookshot#2780
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?
Hookshot version
2.1.0 rc.3-256
What kind of problem
Low fps or stutter
What happened
So i found out why i was getting low FPS , like if i move from one area to another eg:- Hyrule Fields getting 60 fps to Castle town i only get 35 to 40 fps , but if i relauch the game while being in town i get 55 ro 60 fps and no mater how long i play if i stay in same area the fps will be good but if i go into other area the fps will be less. This also happens when moving between town and castle and also between deku tree and forest , so it happens everytime you move between areas,
Where in the game
Any area if you move between them
How often
Every time
Graphics card and driver version
RTX 4080 laptop 12gb vram 175w on latest driver
CPU, RAM and operating system
i9 14900hx, 32 gb ram , windows 11
Changes from the defaults
my vram budget is 7.5gb , res 1440p , ultra wide on 16:9 , aniso filtering 16x. frame gen 2x, DLSS preset M on balanced.
Other software hooked into the game
No, nothing hooked in
hookshot_log.txt
Screenshots or video
No response
Before you send it
getting the exact same issue, 80 fps at first, then dips in a new area
exact same issue, if they could just fix this, the port would be almost perfectly playable
When I move between certain areas that have a loading screen between them, the framerate drops to about half of normal and stays there for the rest of the session. I can reproduce this by travelling from Hyrule Field to Kakariko Village. Once the loading screen finishes, performance stays at the lower framerate until I restart the game, and restarting fixes it.
It doesn’t happen on every transition. Moving from Goron City to the outer area, for example, doesn’t cause the drop. On the affected routes fps stays at roughly 50% of normal until I restart.
this is exactly what happends to me too
A controlled repro on an 8 GB card, smaller than the reports here but every time.
Setup: Windows 11, RTX 3070 8 GB, i7-14700KF.
mainat0ec31ff6, built from source. Output 2048x1152,RX_VK_WB_MAX_KB=1024,RX_VK_IMAGE_PREALLOC=0(because of #2690). A copy of a Kokiri Forest save. The debug teleport, then 20 s standing with a slow camera turn, fps from the log.Test: Lake Hylia alone (load the save, teleport straight there), against Lake Hylia at the end of a tour (Kokiri, Hyrule Field, Kakariko, the Market, the castle, the Lost Woods, Sacred Forest Meadow, then the lake). A fresh start for each run, alternated.
What the log shows at the lake, alone against after the tour:
imports: 42-50 live (about 2.1 GB)alone,112-115 live (about 4.2 GB)after the tour. It is the one counter that differs in every pair.readbacks of GPU results) were longer after the tour in 2 of 3 pairs (0.48-0.55 ms each against 0.10-0.15), not in the third.An earlier run of 3 full tours (26 areas) gave the lake 49.0 / 49.1 / 54.2 as the 8th area. So on this card the drop is about 4-9 fps, not half. I have not found what the extra imports cost yet. I can share the logs.
I found something new if i turn dlss off it fixes it and it remains fixed even if i turn it on back again in same session, until i go in new area then i have to repeat it again.
Follow-up, same setup: the drop stays when the lake is measured 120 s after the teleport instead of 22 s (alone 59.3 / 59.0, after the 7 areas 54.2 / 56.2). So it is not a short settling period.
A diagnostic build (log only, not a fix) counted the pages the CPU wrote that the submit-time capture takes, on the thread that takes most of them, at the lake:
So after other areas, more of the game's pools stay mirrored, and the game's writes into them each frame are captured and copied, which the scene alone does not need. I have not yet found why those pools stay mirrored after their area.
Just to confirm I got the same problem using v2.1.0
I was playing normally at Koriki forest, then I moved to Deku Tree and finished the dungeon normally, when I got back to Kokiri Forest the FPS was really bad, then I saved and closed the game, then reopened and everything was normal.
Short version for players: main now contains two fixes from today (#2825 and #2826) that release memory the game was holding on to after an area change, which is the most likely cause of this drop. In my runs the pressure after the change is clearly lower with them, but not gone, and I cannot yet say the drop is fixed. If you can, try the next nightly and tell us whether it still happens. One more thing I found on the way: switching DLSS off and on again silently changes Balanced from 58% to 50% render resolution, so the "toggle fixes it" trick also lowers the resolution.
The details, for the developers here:
Linux, RTX 4090 24 GB, NVIDIA 615.78.08, i9-13900K; one windowless run each on
e2057b2band262f5614, with logging-only instrumentation.Thanks @Ekamnoor for the toggle clue, @blushOFF for showing that the extra capture work persists, and @klikso for #2825/#2826.
I used Hyrule Field → Market through a loading screen, DLSS M/Balanced at 1440p, the 7.5-GB menu setting and a 7000-MiB renderer allowance. This caps renderer policy, not the card's physical memory; frame generation is inactive windowless.
The toggle is not doing #2825's trimming by another route:
gpu/vk/vk_menu.cpp:1965–1969,vk_temporal.cpp:753–761at the older pin).vk_temporal.cpp:634–658,764–785). Neither path directly resets mirrors, the texture budget or pipeline/program caches.upscaler_rows.h:36,48–51,87–98).This is not an isolated PR or FPS comparison: newer main also changes preallocation placement and mirror chunk size, its cold first arrival had incomplete geometry, and the last phase reached 48.29 one-minute system load. Recurring Market interval peaks remained. There was no fresh-Market restart control, real 8-GB heap or active frame-generation test, so I cannot say the reported persistent FPS drop is fixed.
On a build containing #2825/#2826, the useful follow-up is whether the persistent drop still occurs, how long DLSS was off, and what the Render resolution row shows after it returns.