CPU high usage, GPU not fully utilized, and memory leaked on RAM #470

Closed

opened 2026-11-08 04:31:46 +00:00 by ibsyrfalhsn · 3 comments

ibsyrfalhsn commented

2026-11-08 04:31:46 +00:00

(Migrated from github.com)

The idea

Here's my log:

hookshot_log.txt

Anything else

this is the screenshot:

### The idea Here's my log: [hookshot_log.txt](https://github.com/user-attachments/files/34537448/hookshot_log.txt) ### Anything else this is the screenshot: <img width="1287" height="757" alt="Image" src="https://github.com/user-attachments/assets/7f6a575b-e17d-4b78-87ae-d7a368ec4919" />

MMajor87 commented

2026-11-09 00:44:09 +00:00

(Migrated from github.com)

Some data on all three parts from a desktop with more headroom: RTX 4080 16 GB, i9-14900KF (8 P-cores + 16 E-cores), 32 GB RAM, Windows 11, v2.0.3-v2.0.5.

RAM: no leak here, but a large footprint. From the renderer's memory: working set lines:

30 min idle at a menu: working set flat at ~5.2-5.5 GB, private (committed) ~12 GB.
In play: it steps up on area loads to ~10.5-13 GB working set / ~21-26 GB committed, then stays nearly flat (e.g. 12.5 -> 13.1 GB over ~3.5 min of play after the first step, with one more small step at an area change).

So on a 16 GB machine Windows would page, which looks like a leak or stutter, but it doesn't keep growing here.

GPU underused: on this card the frame was limited by two things run one after the other: the CPU replay (~15 ms at ~3,000-3,500 draws) and the write-back copies at the end of each submission (~7 ms of GPU time, 26-68 MB a frame). GPU-bound wait stays at 0 and resolution changes nothing. Full profile and a local patch in #384.

CPU threads on a hybrid Intel CPU:

HOS_PIN=MainThread=FFFF,Presentation=FFFF,ModuleSystemWorker=FFFF (those threads on the P-cores' logical processors 0-15) helped a little here: busy outdoor areas went from the low 40s to the high 40s, indoors into the 50s (tester's fps counter); log averages 48.0 -> 49.4 fps. The HOS_PIN comment in hos_thread.c notes pinning was slower on another machine, so this may be specific to P/E-core CPUs, where Windows can put a busy thread on an E-core.
hos_reserved_cpus reserves the last physical core for the replay thread. On these CPUs the last core is an E-core (logical 31 here). It only matters with RX_VK_ASYNC=1, but if the reserve stays, the last P-core (by EfficiencyClass) may be the better choice.

Small logging nit: with HOOKSHOT_OCCLUSION_OFF=1, occlusion_switch() logs its occlusion off: line before freopen opens hookshot_log.txt, so the line never reaches the log and a log can't confirm the switch was on.

Some data on all three parts from a desktop with more headroom: RTX 4080 16 GB, i9-14900KF (8 P-cores + 16 E-cores), 32 GB RAM, Windows 11, v2.0.3-v2.0.5. **RAM: no leak here, but a large footprint.** From the renderer's `memory: working set` lines: - 30 min idle at a menu: working set flat at ~5.2-5.5 GB, private (committed) ~12 GB. - In play: it steps up on area loads to ~10.5-13 GB working set / ~21-26 GB committed, then stays nearly flat (e.g. 12.5 -> 13.1 GB over ~3.5 min of play after the first step, with one more small step at an area change). So on a 16 GB machine Windows would page, which looks like a leak or stutter, but it doesn't keep growing here. **GPU underused:** on this card the frame was limited by two things run one after the other: the CPU replay (~15 ms at ~3,000-3,500 draws) and the write-back copies at the end of each submission (~7 ms of GPU time, 26-68 MB a frame). `GPU-bound wait` stays at 0 and resolution changes nothing. Full profile and a local patch in #384. **CPU threads on a hybrid Intel CPU:** - `HOS_PIN=MainThread=FFFF,Presentation=FFFF,ModuleSystemWorker=FFFF` (those threads on the P-cores' logical processors 0-15) helped a little here: busy outdoor areas went from the low 40s to the high 40s, indoors into the 50s (tester's fps counter); log averages 48.0 -> 49.4 fps. The `HOS_PIN` comment in `hos_thread.c` notes pinning was slower on another machine, so this may be specific to P/E-core CPUs, where Windows can put a busy thread on an E-core. - `hos_reserved_cpus` reserves the last physical core for the replay thread. On these CPUs the last core is an E-core (logical 31 here). It only matters with `RX_VK_ASYNC=1`, but if the reserve stays, the last P-core (by `EfficiencyClass`) may be the better choice. **Small logging nit:** with `HOOKSHOT_OCCLUSION_OFF=1`, `occlusion_switch()` logs its `occlusion off:` line before `freopen` opens `hookshot_log.txt`, so the line never reaches the log and a log can't confirm the switch was on.

NotRexed commented

2026-11-09 05:49:49 +00:00

(Migrated from github.com)

Tracked in #995, follow there. That issue collects every report of low FPS while the GPU is not fully used, and shader stutter, and this one is linked from it with its GPU, version and log details. If it still happens on v2.0.6 (https://github.com/NotRexed/Hookshot/releases/tag/v2.0.6; Update next to Play in the launcher), please add a comment there with your hookshot_log.txt.

ibsyrfalhsn commented

2026-11-09 07:08:31 +00:00

(Migrated from github.com)

Tracked in #995, follow there. That issue collects every report of low FPS while the GPU is not fully used, and shader stutter, and this one is linked from it with its GPU, version and log details. If it still happens on v2.0.6 (https://github.com/NotRexed/Hookshot/releases/tag/v2.0.6; Update next to Play in the launcher), please add a comment there with your hookshot_log.txt.

can't even build with the newest update...

> Tracked in [#995](https://git.magicbean.dev/MagicBeanDev/Hookshot/issues/995), follow there. That issue collects every report of low FPS while the GPU is not fully used, and shader stutter, and this one is linked from it with its GPU, version and log details. If it still happens on v2.0.6 (https://github.com/NotRexed/Hookshot/releases/tag/v2.0.6; Update next to Play in the launcher), please add a comment there with your `hookshot_log.txt`. can't even build with the newest update... <img width="1200" height="451" alt="Image" src="https://github.com/user-attachments/assets/d726d824-f64c-46ec-b084-3601ab2bfd58" />

Commenting is not possible because the repository is archived.