MagicBeanDev/Longshot

Watch

Fork 98

Game: rough frame times in the Castle Town market by day as child Link on nightly 153 at 4K with DLAA #597

New issue

Open

opened 2026-11-14 22:11:53 +00:00 by mooki · 2 comments

mooki commented

2026-11-14 22:11:53 +00:00

Member

Not a regression (updated 14 November): the first report compared nightly 147 with v3.0.0-rc.3, but at 4K with DLAA, which did not work correctly on rc.3, so the two builds did different work. The player says so himself (https://discord.com/channels/1569849200047427645/1571190899256463442/1571288337719758919). What stays open: on nightly 153 the market by day as child Link has rough frame times on his PC (Ryzen 7 9800X3D, RTX 5080, 4K, DLAA). The change list and things to try below are kept for that.

Longshot version

Nightly 153 (7494ce4e), earlier seen on nightly 147 (7ff5256e0). The rc.3 comparison does not hold (see the note at the top). The player's logs are not attached yet.

Channel

Nightly. The good build is the release candidate v3.0.0-rc.3.

What kind of problem

Low fps or stutter.

What happened

A player reports that nightly 147 has much worse 1% lows than v3.0.0-rc.3 in Hyrule Field by day and in the Castle Town market. Nightly 147 otherwise looks more stable than the builds before it. The report is in the team's Discord: https://discord.com/channels/1569849200047427645/1571190899256463442/1571277112349040811

Not known yet, and the most useful things to add: how much worse (the 1% low and the frame time of each build, as the game's FPS counter shows them, or from a capture tool), whether it happens on a second pass through the same spot, whether both builds were on the same install and settings, and which nightly between 70 and 147 is the first one that shows it.

Measured here: nothing yet. Paired runs of v3.0.0-rc.3 against nightly 147 in Hyrule Field by day and in the market, on an RTX 4090 with Linux, follow as a comment.

Where in the game

Hyrule Field in daylight, and the Castle Town market.

How often

Not stated.

Graphics card and driver version

RTX 5080, driver not stated.

CPU, RAM and operating system

Ryzen 7 9800X3D; RAM and operating system not stated.

Changes from the defaults

Not stated: upscaler, frame generation, frame rate cap, V-Sync, output resolution, render scale and anything in longshot_env.txt.

What changed between the two builds

79 changes went in between v3.0.0-rc.3 and nightly 147 (85 up to nightly 153). Most are docs, tools, menus and fixes for other graphics cards. These are the ones that could change frame time in those two places, with the switch that turns each one off where there is one. Nobody has measured any of them in Hyrule Field by day or in the market on a card like this one.

Change	First in nightly	What it does	Switch to turn it off
#107	80	the clustered lights' shadow maps are read through 64 descriptors per draw of the programs that use them	`RX_VK_HANDLE_TABLES=0` (the dark blocks on ice and snow come back; the game prepares its shaders again at the next start)
#197 and #260	71 and 127	the game gets the graphics card's real occlusion counts and leaves hidden objects out	`RX_VK_OCC_QUERIES=0`
#324	127	the game is told more memory is in use; on Windows the heap is committed as it is first touched, and on Windows with NVIDIA idle memory imports are given back under pressure	`HOS_MEMINFO_OLD=1`, `HOS_HEAP_COMMIT=1` (Windows), `RX_VK_IMPORT_HIGH=0` (Windows with NVIDIA)
#248	127	late pages are fixed on the graphics card instead of waiting for them	`RX_VK_LATE_FIX=0`
#250	127	the video memory mirrors are sparse	`RX_VK_MIRROR_SPARSE=0`
#329	127	a barrier before each uniform update written on the graphics card	none
#385	144	the largest lifted functions are compiled in pieces	`LONGSHOT_SPLIT_GIANTS=0`, set before the build
#524	147	the game is built for the player's own CPU (`-march=native`)	`RX_MARCH=x86-64-v3`, set before the build
#522	147	the core kept for the replay must be one the game may run on; with every processor allowed nothing changes	`HOS_RESERVE_CORE_MASK`, `HOS_RESERVE_CORE=0`

Smaller or narrower: #60 (a little CPU time per frame in a measured pair, about 1.4%), #445 (Linux only, made the market faster in its measurement), #292 (a new install draws 2560x1440 instead of 2048x1152), #59 (with DLSS or FSR 4).

What does not explain it: the game's 1% low is computed the same way in both builds.

Things to try

One change at a time, in longshot_env.txt in the game folder, then a second pass through the same spot, noting the FPS counter's frame time and 1% low each time:

RX_VK_OCC_QUERIES=0
RX_VK_HANDLE_TABLES=0 (the next start takes longer: the shaders are prepared again)
RX_VK_MIRROR_SPARSE=0
RX_VK_LATE_FIX=0
On Windows: HOS_MEMINFO_OLD=1, HOS_HEAP_COMMIT=1 and RX_VK_IMPORT_HIGH=0 together first, then one by one if that helps.
If an older nightly is still at hand, nightly 143 (before the three build changes) and nightly 80 (before most of the runtime changes) tell us which side of the range the cause is on.

The last two rows of the table need a rebuild, so they come after these.

longshot_log.txt

Not attached yet. From each build's log, the lines vk: a frame's replay time, late pages' fix, reserved core, replays run on logical processors and whether it says prepared ... shader programs or the shaders' preparation was skipped are the ones that will be read first.

Screenshots or video

None yet.

Not tested

Nothing in the table above has been timed in Hyrule Field by day or in the market on this class of PC.
Windows: the heap and import changes of #324, and every change's cost on the Windows driver, can only be judged on Windows.
Frame generation, V-Sync and what the screen shows: untested without the player's settings.

New on this forge; not opened on GitHub.

**Not a regression (updated 14 November):** the first report compared nightly 147 with v3.0.0-rc.3, but at 4K with DLAA, which did not work correctly on rc.3, so the two builds did different work. The player says so himself (https://discord.com/channels/1569849200047427645/1571190899256463442/1571288337719758919). What stays open: on nightly 153 the market by day as child Link has rough frame times on his PC (Ryzen 7 9800X3D, RTX 5080, 4K, DLAA). The change list and things to try below are kept for that. ### Longshot version Nightly 153 (`7494ce4e`), earlier seen on nightly 147 (`7ff5256e0`). The rc.3 comparison does not hold (see the note at the top). The player's logs are not attached yet. ### Channel Nightly. The good build is the release candidate v3.0.0-rc.3. ### What kind of problem Low fps or stutter. ### What happened A player reports that nightly 147 has much worse 1% lows than v3.0.0-rc.3 in Hyrule Field by day and in the Castle Town market. Nightly 147 otherwise looks more stable than the builds before it. The report is in the team's Discord: https://discord.com/channels/1569849200047427645/1571190899256463442/1571277112349040811 Not known yet, and the most useful things to add: how much worse (the 1% low and the frame time of each build, as the game's FPS counter shows them, or from a capture tool), whether it happens on a second pass through the same spot, whether both builds were on the same install and settings, and which nightly between 70 and 147 is the first one that shows it. Measured here: nothing yet. Paired runs of v3.0.0-rc.3 against nightly 147 in Hyrule Field by day and in the market, on an RTX 4090 with Linux, follow as a comment. ### Where in the game Hyrule Field in daylight, and the Castle Town market. ### How often Not stated. ### Graphics card and driver version RTX 5080, driver not stated. ### CPU, RAM and operating system Ryzen 7 9800X3D; RAM and operating system not stated. ### Changes from the defaults Not stated: upscaler, frame generation, frame rate cap, V-Sync, output resolution, render scale and anything in `longshot_env.txt`. ### What changed between the two builds 79 changes went in between v3.0.0-rc.3 and nightly 147 (85 up to nightly 153). Most are docs, tools, menus and fixes for other graphics cards. These are the ones that could change frame time in those two places, with the switch that turns each one off where there is one. Nobody has measured any of them in Hyrule Field by day or in the market on a card like this one. | Change | First in nightly | What it does | Switch to turn it off | |---|---|---|---| | https://git.magicbean.dev/MagicBeanDev/Longshot/pulls/107 | 80 | the clustered lights' shadow maps are read through 64 descriptors per draw of the programs that use them | `RX_VK_HANDLE_TABLES=0` (the dark blocks on ice and snow come back; the game prepares its shaders again at the next start) | | https://git.magicbean.dev/MagicBeanDev/Longshot/pulls/197 and https://git.magicbean.dev/MagicBeanDev/Longshot/pulls/260 | 71 and 127 | the game gets the graphics card's real occlusion counts and leaves hidden objects out | `RX_VK_OCC_QUERIES=0` | | https://git.magicbean.dev/MagicBeanDev/Longshot/pulls/324 | 127 | the game is told more memory is in use; on Windows the heap is committed as it is first touched, and on Windows with NVIDIA idle memory imports are given back under pressure | `HOS_MEMINFO_OLD=1`, `HOS_HEAP_COMMIT=1` (Windows), `RX_VK_IMPORT_HIGH=0` (Windows with NVIDIA) | | https://git.magicbean.dev/MagicBeanDev/Longshot/pulls/248 | 127 | late pages are fixed on the graphics card instead of waiting for them | `RX_VK_LATE_FIX=0` | | https://git.magicbean.dev/MagicBeanDev/Longshot/pulls/250 | 127 | the video memory mirrors are sparse | `RX_VK_MIRROR_SPARSE=0` | | https://git.magicbean.dev/MagicBeanDev/Longshot/pulls/329 | 127 | a barrier before each uniform update written on the graphics card | none | | https://git.magicbean.dev/MagicBeanDev/Longshot/pulls/385 | 144 | the largest lifted functions are compiled in pieces | `LONGSHOT_SPLIT_GIANTS=0`, set before the build | | https://git.magicbean.dev/MagicBeanDev/Longshot/pulls/524 | 147 | the game is built for the player's own CPU (`-march=native`) | `RX_MARCH=x86-64-v3`, set before the build | | https://git.magicbean.dev/MagicBeanDev/Longshot/pulls/522 | 147 | the core kept for the replay must be one the game may run on; with every processor allowed nothing changes | `HOS_RESERVE_CORE_MASK`, `HOS_RESERVE_CORE=0` | Smaller or narrower: https://git.magicbean.dev/MagicBeanDev/Longshot/pulls/60 (a little CPU time per frame in a measured pair, about 1.4%), https://git.magicbean.dev/MagicBeanDev/Longshot/pulls/445 (Linux only, made the market faster in its measurement), https://git.magicbean.dev/MagicBeanDev/Longshot/pulls/292 (a new install draws 2560x1440 instead of 2048x1152), https://git.magicbean.dev/MagicBeanDev/Longshot/pulls/59 (with DLSS or FSR 4). What does not explain it: the game's 1% low is computed the same way in both builds. ### Things to try One change at a time, in `longshot_env.txt` in the game folder, then a second pass through the same spot, noting the FPS counter's frame time and 1% low each time: 1. `RX_VK_OCC_QUERIES=0` 2. `RX_VK_HANDLE_TABLES=0` (the next start takes longer: the shaders are prepared again) 3. `RX_VK_MIRROR_SPARSE=0` 4. `RX_VK_LATE_FIX=0` 5. On Windows: `HOS_MEMINFO_OLD=1`, `HOS_HEAP_COMMIT=1` and `RX_VK_IMPORT_HIGH=0` together first, then one by one if that helps. 6. If an older nightly is still at hand, nightly 143 (before the three build changes) and nightly 80 (before most of the runtime changes) tell us which side of the range the cause is on. The last two rows of the table need a rebuild, so they come after these. ### longshot_log.txt Not attached yet. From each build's log, the lines `vk: a frame's replay time`, `late pages' fix`, `reserved core`, `replays run on logical processors` and whether it says `prepared ... shader programs` or `the shaders' preparation was skipped` are the ones that will be read first. ### Screenshots or video None yet. ### Not tested - Nothing in the table above has been timed in Hyrule Field by day or in the market on this class of PC. - Windows: the heap and import changes of #324, and every change's cost on the Windows driver, can only be judged on Windows. - Frame generation, V-Sync and what the screen shows: untested without the player's settings. New on this forge; not opened on GitHub.

mooki added the

labels

2026-11-14 22:11:55 +00:00

mooki changed title from ~~Game: much worse 1% lows in Hyrule Field by day and the Castle Town market in nightly 147 (v3.0.0-rc.3 was fine)~~ to Game: rough frame times in the Castle Town market by day as child Link on nightly 153 at 4K with DLAA

2026-11-14 22:25:17 +00:00

mooki added

and removed

labels

2026-11-14 22:25:18 +00:00

mooki commented

2026-11-14 22:25:18 +00:00

Author

Member

Updated: this is not a regression. The rc.3 comparison was made at 4K with DLAA, which did not work correctly on rc.3, so the two builds did different work (the player's own note, linked at the top). The regression and critical labels are removed. What stays open is the rough frame time in the market by day as child Link on nightly 153. Most useful next: longshot_log.txt from one pass through the market by day, and the FPS counter's Frame time level in a picture, with the settings named.

Updated: this is not a regression. The rc.3 comparison was made at 4K with DLAA, which did not work correctly on rc.3, so the two builds did different work (the player's own note, linked at the top). The regression and critical labels are removed. What stays open is the rough frame time in the market by day as child Link on nightly 153. Most useful next: `longshot_log.txt` from one pass through the market by day, and the FPS counter's Frame time level in a picture, with the settings named.

GrimVisage referenced this issue

2026-11-15 06:05:56 +00:00

docs(tested): Threaded rendering (#588) in the Market on a 6-core Linux desktop, interleaved Off and Auto #688

GrimVisage referenced this issue

2026-11-15 06:05:56 +00:00

docs(tested): Threaded rendering (#588) in the Market on a 6-core Linux desktop, interleaved Off and Auto #688

omgitsgela commented

2026-11-15 09:46:22 +00:00

Contributor

Same spot, different hardware, much harder failure mode with clean log evidence: #750 — on a Steam Deck LCD a Castle Town save idles at 25-27 fps but a camera spin collapses it to 2-6 fps, with a GPU-written 691x432 texture re-uploaded every frame and a 714,844-page capture in one submission. The market-by-day 1% lows here and the Deck stall there may share the re-upload/capture path.

Same spot, different hardware, much harder failure mode with clean log evidence: https://git.magicbean.dev/MagicBeanDev/Longshot/issues/750 — on a Steam Deck LCD a Castle Town save idles at 25-27 fps but a camera spin collapses it to 2-6 fps, with a GPU-written 691x432 texture re-uploaded every frame and a 714,844-page capture in one submission. The market-by-day 1% lows here and the Deck stall there may share the re-upload/capture path.