MagicBeanDev/Longshot

Watch

Fork 99

Game: 13-25 real FPS in Castle Town Market on Nightly 189 with RTX 4050 6 GB #813

New issue

Open

opened 2026-11-15 14:13:29 +00:00 by Rogasse · 4 comments

Rogasse commented

2026-11-15 14:13:29 +00:00

Longshot version and channel

Nightly 189 (nightly-189-aa95d35f, source 719431ac as printed in longshot_log.txt).

Problem and steps

On a Windows laptop with an RTX 4050 6 GB, I entered Castle Town Market as child Link from Hyrule Field and walked around the plaza. The game stayed around 13–25 real game FPS in the measured segments. I expected smoother play, ideally near 60 FPS. This is one session, so I am reporting the low performance rather than claiming a regression from an earlier version.

Hardware

Windows 11 Home build 26200; NVIDIA GeForce RTX 4050 Laptop GPU (6 GB), NVIDIA driver 621.14 (32.0.16.2114); Intel Core i5-13420H; 32 GB RAM.

Settings and measurements

The output was 1536x864 in the startup log. The route and settings changed during play, so the segments below are observations, not matched A/B comparisons. Each FPS value is the mean of the game's vi: ... fps over the last 5 s log windows; those count real game frames, not generated display frames. Windows around setting changes were excluded. I did not capture frame-by-frame times or a 1% low.

Settings during each segment	Five-second windows	Mean real FPS	Range	Mean logged GPU time
Initial DLSS, Frame Generation off	12	18.3	13.0–23.9	27.3 ms
Lower internal resolution, DLSS, Frame Generation off	12	17.0	13.5–24.4	22.9 ms
Game's upscaler, dynamic internal resolution, Frame Generation off	20	21.7	14.2–25.3	20.5 ms
Same dynamic setup, Frame Generation x2	8	19.4 real game FPS	16.1–25.1	23.6 ms

The driver allowed roughly 4.8–5.0 GB of VRAM during the Market run. Some samples exceeded that allowance, while textures exceeded their reduced budget. For example, from the slow run:

vk: texture budget: 3453 MB (driver allows 5152 MB, the card has 5920 MB, RAM 32397 MB)
vi: 13263 frames presented (13.5 fps over the last 5.0 s, interval 1)
vi: present intervals: <15.5 ms 0, 15.5-17.8 0, 17.8-22 0, 22-30 0, 30-40 1, over 40 67
vk: VRAM: 5318 MB used of 4965 MB allowed (562 MB of it free in the blocks); textures 2669 MB (budget 1450 MB), 2471 textures

The VRAM pressure may be relevant, but this run does not identify the cause or prove an effect from #735 or the open #771. I have not compared a direct Market load with walking in from Hyrule Field, nor repeated a fixed route with unchanged settings. The full raw log remains local because it includes my Windows user path; the lines above contain no private paths or game data.

I searched the existing issues: #597 is a different RTX 5080 / 4K DLAA frame-time case, #441 is a different RTX 3050 / Kokiri case, and #89 concerns a persistent drop after area changes that this single run cannot establish.

### Longshot version and channel Nightly 189 (`nightly-189-aa95d35f`, source `719431ac` as printed in `longshot_log.txt`). ### Problem and steps On a Windows laptop with an RTX 4050 6 GB, I entered Castle Town Market as child Link from Hyrule Field and walked around the plaza. The game stayed around 13–25 real game FPS in the measured segments. I expected smoother play, ideally near 60 FPS. This is one session, so I am reporting the low performance rather than claiming a regression from an earlier version. ### Hardware Windows 11 Home build 26200; NVIDIA GeForce RTX 4050 Laptop GPU (6 GB), NVIDIA driver 621.14 (`32.0.16.2114`); Intel Core i5-13420H; 32 GB RAM. ### Settings and measurements The output was 1536x864 in the startup log. The route and settings changed during play, so the segments below are observations, **not matched A/B comparisons**. Each FPS value is the mean of the game's `vi: ... fps over the last 5 s` log windows; those count real game frames, not generated display frames. Windows around setting changes were excluded. I did not capture frame-by-frame times or a 1% low. | Settings during each segment | Five-second windows | Mean real FPS | Range | Mean logged GPU time | | --- | ---: | ---: | ---: | ---: | | Initial DLSS, Frame Generation off | 12 | 18.3 | 13.0–23.9 | 27.3 ms | | Lower internal resolution, DLSS, Frame Generation off | 12 | 17.0 | 13.5–24.4 | 22.9 ms | | Game's upscaler, dynamic internal resolution, Frame Generation off | 20 | 21.7 | 14.2–25.3 | 20.5 ms | | Same dynamic setup, Frame Generation x2 | 8 | 19.4 real game FPS | 16.1–25.1 | 23.6 ms | The driver allowed roughly 4.8–5.0 GB of VRAM during the Market run. Some samples exceeded that allowance, while textures exceeded their reduced budget. For example, from the slow run: ```text vk: texture budget: 3453 MB (driver allows 5152 MB, the card has 5920 MB, RAM 32397 MB) vi: 13263 frames presented (13.5 fps over the last 5.0 s, interval 1) vi: present intervals: <15.5 ms 0, 15.5-17.8 0, 17.8-22 0, 22-30 0, 30-40 1, over 40 67 vk: VRAM: 5318 MB used of 4965 MB allowed (562 MB of it free in the blocks); textures 2669 MB (budget 1450 MB), 2471 textures ``` The VRAM pressure may be relevant, but this run does not identify the cause or prove an effect from [#735](https://git.magicbean.dev/MagicBeanDev/Longshot/pulls/735) or the open [#771](https://git.magicbean.dev/MagicBeanDev/Longshot/pulls/771). I have not compared a direct Market load with walking in from Hyrule Field, nor repeated a fixed route with unchanged settings. The full raw log remains local because it includes my Windows user path; the lines above contain no private paths or game data. I searched the existing issues: [#597](https://git.magicbean.dev/MagicBeanDev/Longshot/issues/597) is a different RTX 5080 / 4K DLAA frame-time case, [#441](https://git.magicbean.dev/MagicBeanDev/Longshot/issues/441) is a different RTX 3050 / Kokiri case, and [#89](https://git.magicbean.dev/MagicBeanDev/Longshot/issues/89) concerns a persistent drop after area changes that this single run cannot establish.

👀 1

BeanIssues added the

labels

2026-11-15 14:13:43 +00:00

BeanIssues commented

2026-11-15 14:13:43 +00:00

Collaborator

Possibly related, for context:

#597 Game: rough frame times in the Castle Town market by day as child Link on nightly 153 at 4K with DLAA — Low frame performance in the Castle Town market, but different hardware, resolution and reported symptom profile.
#750 Game: Hyrule Town spin costs ~30% fps (Deck LCD) - GPU-written 691x432 texture re-uploaded per present + page-capture storm — Castle Town performance issue; specifically camera-spin stalls on Steam Deck with a distinct measured cause.

Possibly related, for context: - #597 Game: rough frame times in the Castle Town market by day as child Link on nightly 153 at 4K with DLAA — Low frame performance in the Castle Town market, but different hardware, resolution and reported symptom profile. - #750 Game: Hyrule Town spin costs ~30% fps (Deck LCD) - GPU-written 691x432 texture re-uploaded per present + page-capture storm — Castle Town performance issue; specifically camera-spin stalls on Steam Deck with a distinct measured cause.

lucasknutr commented

2026-11-15 16:18:22 +00:00

Hyprland (desktop on the iGPU): driver allows ~5,475 MB. 31.9 fps median (p10 25.4),
GPU 12.4 ms/frame at 67%, no PCIe-bound pools, readback waits 0.56 ms.
Steam gaming mode (gamescope + Steam UI on the same NVIDIA GPU): driver allows
4,580-4,755 MB. 16.6-24.6 fps median (p10 11.9-16.3), GPU 19-36 ms/frame even at 50%,
VRAM at 100%, PCIe-bound pools in 40-76 log windows, readback waits 4.6-7.6 ms,
textures 2.5-2.6 GB against a 1.6-1.7 GB budget.

~800 MB less allowance is the difference between 32 and 17-25 fps. #771 looks directly
relevant (at 20 fps the eviction waits are 3x longer). Happy to test #521/#771 builds.

Same pattern here, with a clean A/B on one machine. Dell G15 5515, RTX 3060 Laptop 6 GB, Ryzen 7 5800H, 32 GB, Arch Linux, NVIDIA 615.78.08, v3.0.0-rc.4, Threaded rendering On. Market (child), 2048x1152 output, DLSS: - Hyprland (desktop on the iGPU): driver allows ~5,475 MB. 31.9 fps median (p10 25.4), GPU 12.4 ms/frame at 67%, no PCIe-bound pools, readback waits 0.56 ms. - Steam gaming mode (gamescope + Steam UI on the same NVIDIA GPU): driver allows 4,580-4,755 MB. 16.6-24.6 fps median (p10 11.9-16.3), GPU 19-36 ms/frame even at 50%, VRAM at 100%, PCIe-bound pools in 40-76 log windows, readback waits 4.6-7.6 ms, textures 2.5-2.6 GB against a 1.6-1.7 GB budget. ~800 MB less allowance is the difference between 32 and 17-25 fps. #771 looks directly relevant (at 20 fps the eviction waits are 3x longer). Happy to test #521/#771 builds.

Rogasse referenced this issue

2026-11-15 16:39:42 +00:00

perf(vk): below 60 fps the eviction's waits are seconds, not presents: the compaction's hold and the GPU-drawn textures' keep #771

Rogasse commented

2026-11-15 17:28:44 +00:00

Author

Follow-up from the same Windows RTX 4050 Laptop 6 GB machine: the low-FPS symptom and camera-turn hitches remain reproducible. No fix is established yet. These are the measurements collected since the initial report, with help from a local agent; I controlled the moving runs.

Windows 11 Home build 26200, i5-13420H, 32 GB RAM, NVIDIA 621.14. Original Nightly 189-aa95d35f (host reports source 719431ac), original renderer SHA-256 F593242076A424CAC308119653D06E2DB6B4DC3EF4A68CA1F3486CBE80C5A3CC. The follow-up runs below used 1920x1080 output, Handheld profile, dynamic internal resolution and the game's upscaler, rather than the initial report's 1536x864 startup output. Normal saves were preserved using isolated copies.

Player-controlled routes and displays

One minute each in direct-loaded Market, Hyrule Field, then Market after a debug teleport back from Field. This is not a normal doorway traversal. Same copied save, original renderer and byte-identical options on both displays; Auto frame generation was enabled, but the per-game-present trace below counts real game frames, excluding generated ones.

60-second phase	Laptop 1080p/60 Hz mean FPS	Acer 1080p/120 Hz mean FPS
Direct Market	30.51	28.05
Hyrule Field	32.46	32.04
Return Market	23.76	25.23

Only one player-driven run per display; paths/camera differed, and the Acer Field run paused briefly. Auto FG could use different multipliers at 60/120 Hz. These numbers do not prove a monitor penalty or an area-transition regression. Both displays still have low real FPS in moving Market play.

I also tested renderer-only #771 at a8a41ddf on the Nightly 189 base. Two scripted pairs did not show a repeatable FPS gain; the player-controlled pair also differed in camera/path. Full qualified results are on #771. The requested 10-minute texture-aging test remains untested, so this does not rule out a longer-session memory benefit.

Camera-turn profile on original Nightly 189

On the Acer, FG off, normal thread placement: I walked in the Market and turned the camera for a marked ~60 seconds. HOS_PRESENT_TRACE: 25.61 mean game FPS, median 36.47 ms, p99 80.02 ms, 155 intervals over 50 ms, 1,536 game frames.

RX_VK_FRAME_TRACE=1 recorded a separately bounded window of 1,540 complete renderer rows. Its flush boundaries differ slightly from the game-present window, so its counts should not be combined with the above. Mean counters in that renderer window:

Counter (ms)	All rows	Rows over 50 ms	Rows under 30 ms
`tex_frame_ms`	2.30	4.36	1.35
`tex_lookup_ms`	5.23	13.51	2.00
`uploads_ms`	1.84	6.65	0.35
`desc_ms`	5.34	11.01	3.17
`memsync_ms`	2.90	4.71	1.80

One 87.84 ms renderer interval contained 45.67 ms in tex_frame_ms. Another 111.70 ms interval recorded 85.55 ms of texture lookup and 251 textures retired. Some other slow intervals had little texture-maintenance time. Pipeline-wait and translation counters were zero in this selected window.

These are overlapping diagnostic counters, not additive costs, and tracing adds overhead. Texture maintenance includes more than image destruction. This makes #792 worth an isolated moving-camera test, but does not establish that its reaper fixes the stalls or explain every slow frame. I have not built/tested #792 or #521 yet.

Small scheduling screen

I tried #838's thread-placement idea at runtime on the original binary, not a build of #838: normal replay affinity 0xc0, versus 0xff (this i5's performance-core logical processors), ideal processor 7. FG off, stationary Market, alternating 45-second windows after warm-up/settling. A-B-A-B mean FPS: 42.39 / 43.02 / 41.94 / 41.61. The first A changed camera angle and is excluded from matched-view inference; the later B-A-B kept the angle. No repeatable average-FPS or p99 gain; >40 ms counts were 2 / 6 / 0 for those B-A-B windows, too short for a gameplay conclusion. Original affinity was restored afterward.

@lucasknutr Thanks for the 6 GB allowance comparison. Our logs also show texture-budget pressure, but the newer camera profile suggests renderer texture work is worth examining alongside VRAM headroom. I am not assuming the Linux display-mode cause is identical on this Windows laptop. Raw traces, options and saves remain local; no game files are attached.

Follow-up from the same Windows RTX 4050 Laptop 6 GB machine: **the low-FPS symptom and camera-turn hitches remain reproducible. No fix is established yet.** These are the measurements collected since the initial report, with help from a local agent; I controlled the moving runs. Windows 11 Home build 26200, i5-13420H, 32 GB RAM, NVIDIA 621.14. Original Nightly `189-aa95d35f` (host reports source `719431ac`), original renderer SHA-256 `F593242076A424CAC308119653D06E2DB6B4DC3EF4A68CA1F3486CBE80C5A3CC`. The follow-up runs below used 1920x1080 output, Handheld profile, dynamic internal resolution and the game's upscaler, rather than the initial report's 1536x864 startup output. Normal saves were preserved using isolated copies. ### Player-controlled routes and displays One minute each in direct-loaded Market, Hyrule Field, then Market after a debug teleport back from Field. This is not a normal doorway traversal. Same copied save, original renderer and byte-identical options on both displays; Auto frame generation was enabled, but the per-game-present trace below counts real game frames, excluding generated ones. | 60-second phase | Laptop 1080p/60 Hz mean FPS | Acer 1080p/120 Hz mean FPS | |---|---:|---:| | Direct Market | 30.51 | 28.05 | | Hyrule Field | 32.46 | 32.04 | | Return Market | 23.76 | 25.23 | Only one player-driven run per display; paths/camera differed, and the Acer Field run paused briefly. Auto FG could use different multipliers at 60/120 Hz. These numbers do not prove a monitor penalty or an area-transition regression. Both displays still have low real FPS in moving Market play. I also tested renderer-only #771 at `a8a41ddf` on the Nightly 189 base. Two scripted pairs did not show a repeatable FPS gain; the player-controlled pair also differed in camera/path. [Full qualified results are on #771](https://git.magicbean.dev/MagicBeanDev/Longshot/pulls/771#issuecomment-26085). The requested 10-minute texture-aging test remains untested, so this does not rule out a longer-session memory benefit. ### Camera-turn profile on original Nightly 189 On the Acer, **FG off**, normal thread placement: I walked in the Market and turned the camera for a marked ~60 seconds. `HOS_PRESENT_TRACE`: **25.61 mean game FPS**, median **36.47 ms**, p99 **80.02 ms**, **155 intervals over 50 ms**, 1,536 game frames. `RX_VK_FRAME_TRACE=1` recorded a separately bounded window of 1,540 complete renderer rows. Its flush boundaries differ slightly from the game-present window, so its counts should not be combined with the above. Mean counters in that renderer window: | Counter (ms) | All rows | Rows over 50 ms | Rows under 30 ms | |---|---:|---:|---:| | `tex_frame_ms` | 2.30 | 4.36 | 1.35 | | `tex_lookup_ms` | 5.23 | 13.51 | 2.00 | | `uploads_ms` | 1.84 | 6.65 | 0.35 | | `desc_ms` | 5.34 | 11.01 | 3.17 | | `memsync_ms` | 2.90 | 4.71 | 1.80 | One 87.84 ms renderer interval contained **45.67 ms in `tex_frame_ms`**. Another 111.70 ms interval recorded 85.55 ms of texture lookup and 251 textures retired. Some other slow intervals had little texture-maintenance time. Pipeline-wait and translation counters were zero in this selected window. These are overlapping diagnostic counters, not additive costs, and tracing adds overhead. Texture maintenance includes more than image destruction. This makes #792 worth an isolated moving-camera test, but does not establish that its reaper fixes the stalls or explain every slow frame. I have not built/tested #792 or #521 yet. ### Small scheduling screen I tried #838's thread-placement idea at runtime on the original binary, **not a build of #838**: normal replay affinity `0xc0`, versus `0xff` (this i5's performance-core logical processors), ideal processor 7. FG off, stationary Market, alternating 45-second windows after warm-up/settling. A-B-A-B mean FPS: 42.39 / 43.02 / 41.94 / 41.61. The first A changed camera angle and is excluded from matched-view inference; the later B-A-B kept the angle. No repeatable average-FPS or p99 gain; >40 ms counts were 2 / 6 / 0 for those B-A-B windows, too short for a gameplay conclusion. Original affinity was restored afterward. @lucasknutr Thanks for the 6 GB allowance comparison. Our logs also show texture-budget pressure, but the newer camera profile suggests renderer texture work is worth examining alongside VRAM headroom. I am not assuming the Linux display-mode cause is identical on this Windows laptop. Raw traces, options and saves remain local; no game files are attached.

MaikelJSQ referenced this issue

2026-11-15 18:05:02 +00:00

Game: Longshot closed unexpectedly while you were playing #859

BeanIssues referenced this issue

2026-11-15 18:34:50 +00:00

Game: Ocarina of time #874

Rogasse commented

2026-11-15 19:43:49 +00:00

Author

Further player-driven Market observations on the same Windows 11 / i5-13420H / RTX 4050 Laptop 6 GB / driver 621.14 / 32 GB PC, assisted by a local agent. The low FPS remains; this is an exploratory comparison, not a confirmed fix or a controlled fork benchmark.

I walked and turned the camera in Castle Town Market in three separate sessions, starting from the same hash-verified copied test save. The logs report the RTX 4050 and 2048x1152 output; FG and DLSS were off. For each arm, the table uses the last twenty approximately five-second vi: FPS windows (about 100 seconds), excluding initial Longshot title/loading samples:

Build	Mean of FPS windows	Range of FPS windows
HeyListen v0.3.2	36.0	17.4–48.6
Original Longshot Nightly 189 `aa95d35f`	28.8	24.3–36.8
Nightly 189 + #792 renderer `8d361dc6`	27.0	21.1–36.6

The PR arm logged its image-destruction thread as active. It predates the newly posted #792 head 5333dd63, which fixes waiting for the reaper's queue while holding reap_mu. These numbers do not test that newer fix. We are updating the local #792 build before reporting acceptance-test results on that PR.

Limitations: one run per arm, manually driven and not identical routes/cameras; no matched warm-up or A-B-A-B repeats; HeyListen had a different preset and a fullscreen change during its run. Equal output resolution and similarly named options do not guarantee equal internal resolution, rendering features or threading defaults across forks. Longshot's two arms used the same options, including threaded_rendering=0; the #792 renderer was built locally without a play profile, unlike an assured identical-flags baseline. The table cannot establish a causal percentage gain, a 1% low, or a hitch reduction. It is also a different setup from my earlier 1080p Handheld/dynamic measurements above, so those runs should not be pooled.

Working hypotheses and next investigation

The current logs strengthen the reason to investigate texture residency and renderer work. In the selected Nightly 189 window, one sample reports 5268 MB VRAM used / 5085 MB allowed, with 2613 MB textures / 1598 MB texture budget. HeyListen samples near the end report 4311/4843 MB and 4336/5011 MB VRAM, with textures 1642/2318 MB and 1894/2267 MB against their budgets. These are separate observations from different camera/routes, not proof of a more efficient allocator or a leak. Scene and preset differences could explain part of the memory gap.

Our earlier camera-turn trace in this issue also showed texture lookup/uploads, descriptor work and memory synchronization growing during slow frames; one interval had 45.67 ms in tex_frame_ms. That counter includes more than image destruction. This suggests several sources of stalls rather than enough evidence to blame one function. #792 alone has not demonstrated a solution in our old-head pass, and its latest lock correction deserves a proper retest.

We will investigate whether the apparent HeyListen advantage survives matched effective settings, threading, cache state and repeatable movement. Candidate source differences to examine include converted-texture RAM caching/batched ASTC work, texture-format policy, mirror copying and scheduling defaults; their effect on this PC is still unproven, and Longshot already has some related mechanisms. If we isolate a useful missing change, the aim is a small, license-compatible Longshot contribution with a focused test and measured before/after results, coordinated with existing PRs. No code fix is claimed yet. Logs and game files remain local.

Further player-driven Market observations on the same Windows 11 / i5-13420H / RTX 4050 Laptop 6 GB / driver 621.14 / 32 GB PC, assisted by a local agent. **The low FPS remains; this is an exploratory comparison, not a confirmed fix or a controlled fork benchmark.** I walked and turned the camera in Castle Town Market in three separate sessions, starting from the same hash-verified copied test save. The logs report the RTX 4050 and 2048x1152 output; FG and DLSS were off. For each arm, the table uses the last twenty approximately five-second `vi:` FPS windows (about 100 seconds), excluding initial Longshot title/loading samples: | Build | Mean of FPS windows | Range of FPS windows | |---|---:|---:| | HeyListen v0.3.2 | 36.0 | 17.4–48.6 | | Original Longshot Nightly 189 `aa95d35f` | 28.8 | 24.3–36.8 | | Nightly 189 + #792 renderer `8d361dc6` | 27.0 | 21.1–36.6 | The PR arm logged its image-destruction thread as active. It predates the newly posted #792 head `5333dd63`, which fixes waiting for the reaper's queue while holding `reap_mu`. These numbers do not test that newer fix. We are updating the local #792 build before reporting acceptance-test results on that PR. Limitations: one run per arm, manually driven and not identical routes/cameras; no matched warm-up or A-B-A-B repeats; HeyListen had a different preset and a fullscreen change during its run. Equal output resolution and similarly named options do not guarantee equal internal resolution, rendering features or threading defaults across forks. Longshot's two arms used the same options, including `threaded_rendering=0`; the #792 renderer was built locally without a play profile, unlike an assured identical-flags baseline. The table cannot establish a causal percentage gain, a 1% low, or a hitch reduction. It is also a different setup from my earlier 1080p Handheld/dynamic measurements above, so those runs should not be pooled. **Working hypotheses and next investigation** The current logs strengthen the reason to investigate texture residency and renderer work. In the selected Nightly 189 window, one sample reports **5268 MB VRAM used / 5085 MB allowed**, with **2613 MB textures / 1598 MB texture budget**. HeyListen samples near the end report **4311/4843 MB** and **4336/5011 MB** VRAM, with textures **1642/2318 MB** and **1894/2267 MB** against their budgets. These are separate observations from different camera/routes, not proof of a more efficient allocator or a leak. Scene and preset differences could explain part of the memory gap. Our earlier camera-turn trace in this issue also showed texture lookup/uploads, descriptor work and memory synchronization growing during slow frames; one interval had 45.67 ms in `tex_frame_ms`. That counter includes more than image destruction. This suggests several sources of stalls rather than enough evidence to blame one function. #792 alone has not demonstrated a solution in our old-head pass, and its latest lock correction deserves a proper retest. We will investigate whether the apparent HeyListen advantage survives matched effective settings, threading, cache state and repeatable movement. Candidate source differences to examine include converted-texture RAM caching/batched ASTC work, texture-format policy, mirror copying and scheduling defaults; their effect on this PC is still unproven, and Longshot already has some related mechanisms. If we isolate a useful missing change, the aim is a small, license-compatible Longshot contribution with a focused test and measured before/after results, coordinated with existing PRs. No code fix is claimed yet. Logs and game files remain local.