Idea: on the compute fallback, loading every program before the title costs 5 GB and puts a 24 GB PC at its commit limit; `RX_VK_LOAD=create` measured on a second such card (RX 5600 XT): same fps or better, loads of 50 ms at worst #805

New issue

Open

opened 2026-11-15 13:13:24 +00:00 by waryxxful · 1 comment

waryxxful commented

2026-11-15 13:13:24 +00:00

The idea

A GPU without mesh shaders loads every kept program before the title (gpu/vk/load_default.h: start, "this GPU draws mesh programs through the compute fallback"), because on the one such card measured, an RX 580 with 16 GB, first uses waited 0.7-1.3 s when they were loaded at their create calls. On an RX 5600 XT with 24 GB of RAM that default now leaves the PC without commit: the game holds 23-26 GB of private memory, the log says commit limit near 13-18 times in a five-minute run, the textures' budget is cut to nothing, and one run never came out of a load. With RX_VK_LOAD=create on the same build the game holds 18-20 GB, the line never appears, the frame rate is the same or better, and the loads at create took 1.85 ms at the median and 50 ms at worst.

So the rule may be keeping the costly mode on a class of cards from one PC's result. Could Auto be create on the fallback as well, behind the safety net that already takes an install back to start?

Setup. Main 6c9edffe with ea6dc5f5 (the mirror retry of #288) cherry-picked. RX 5600 XT 6 GB (RDNA1, the compute fallback), Adrenalin 26.10.1, Ryzen 5 5600X, 24.5 GB of RAM, a 15.6 GB page file (Windows-managed), the game on an NVMe disk, Windows 11. Render resolution 50% of 1920x1080; RX_VK_MIRROR_SPARSE=0, RX_VK_WB_MAX_KB=1024, RX_VK_NO_PREDICT=1, RX_VK_NO_WARM=1; Threaded rendering Auto (on). Five areas by teleport, standing, 25 s each after 10 s; three rounds interleaved with other sides. fps, then the GPU's frame in ms; one cell a run:

Area (draws)	Loaded at start (the default here)	`RX_VK_LOAD=create`
Kokiri Forest (800)	58.4 / 60.9 / 60.1; 12.8 / 12.3 / 12.5	60.8 / 60.7 / 61.2; 12.2 / 12.0 / 12.0
Hyrule Field (1,230)	62.6 / 56.7 / 63.0; 12.5 / 12.8 / 12.3	56.0 / 57.5 / 59.2; 12.8 / 12.4 / 12.2
Market (2,710)	36.7 / 36.6 / 31.2; 17.4 / 18.4 / 19.3	24.4 / 35.8 / 38.8; 22.2 / 17.7 / 17.2
Hyrule Castle (2,020)	34.5 / 33.2 / 38.1; 22.5 / 23.4 / 21.0	38.7 / 38.5 / 41.5; 18.7 / 18.3 / 18.1
Desert Colossus (1,215)	29.0 / 29.2 / 30.8; 29.5 / 29.4 / 26.9	32.4 / 31.7 / 34.1; 25.8 / 25.9 / 25.8
The game's private memory	23.4-24.9 GB	18.2-19.9 GB
`commit limit near` lines a run	13-16	0

vk: programs are loaded before the title (start): this GPU draws mesh programs through the compute fallback (RX_VK_LOAD=create or start says which)
vk: commit limit near: 2507 MB of commit left (reserve 2560 MB); the textures' budget down to 0 MB of their 304 MB (RX_VK_COMMIT_RESERVE_MB)
vk: program loads at create (play): 6294 queued, 6294 loaded (median 1.85 ms, 99th percentile 13.88 ms, worst 50.28 ms, 18768 ms and 1385.6 MB read in all); 8419 programs (978 of them compute variants without their code, ...
vk: a frame: 0.1 draws left out (not ready), 0.00 waits for shaders or pipelines (0.0 ms)

Hyrule Castle and the Desert Colossus, where the GPU is the limit, gain 3-5 fps and lose 3-4 ms of GPU a frame. Hyrule Field may lose a few fps (one round of three is level); the Market swings by run on both sides.
The run that did not finish: with the default load and sparse mirrors, a 12-area run stayed at the load into Hyrule Field for 18 minutes (5 draws a frame, the control bridge's teleports timing out) until I closed it. The game's private memory was 26.2 GB and the commit limit near line above was the last of its kind before it.
The start mode has grown since main 9c9d69ed (I take it to be the 22,987 pipelines of #563, but did not bisect): in six interleaved runs of one six-area walk, 9c9d69ed held 22.0-23.4 GB and logged no commit limit near, and 6c9edffe held 24.3-25.9 GB and logged it 19-20 times a run.

The questions:

Was the RX 580's result the fallback, or that PC (16 GB, its disk)? Its tours waited 2.5-4.7 s in all at create; this card's loads summed 18.8 s of work but the longest single one was 50 ms, so I may be reading a different number than the one the rule was made from. Which log line is the one to compare?
If it is the PC and not the fallback: could Auto pick create on the fallback too, and leave the marker (longshot_load_start.txt) to take a slow PC back?
Short of that: on a PC where the commit left is under the reserve at the title, should start give way by itself?

Who can help without writing code: anyone with a card without mesh shaders (RX 5500 XT / 5600 / 5700, RX 500 series, GTX 10 series, Intel before Arc). Add RX_VK_LOAD=create to longshot_env.txt in the game's folder, play ten minutes through a few areas, and comment with the card, the RAM, the log's program loads at create (play) line and whether you saw hitches or things missing on entering an area.

Anything else

Not tested: a session longer than these five-minute runs with create, a first visit to areas the preparation did not cover, a slow disk, 16 GB of RAM, Linux.
These are scripted runs through the control bridge, standing still after a teleport. A person entering areas on foot loads them differently.
The same runs with sparse mirrors are in #585: there the default load is what makes sparse mirrors slow on this card.
Related, for what happens once the commit limit is reached: #333.

### The idea A GPU without mesh shaders loads every kept program before the title (`gpu/vk/load_default.h`: `start`, "this GPU draws mesh programs through the compute fallback"), because on the one such card measured, an RX 580 with 16 GB, first uses waited 0.7-1.3 s when they were loaded at their create calls. On an RX 5600 XT with 24 GB of RAM that default now leaves the PC without commit: the game holds 23-26 GB of private memory, the log says `commit limit near` 13-18 times in a five-minute run, the textures' budget is cut to nothing, and one run never came out of a load. With `RX_VK_LOAD=create` on the same build the game holds 18-20 GB, the line never appears, the frame rate is the same or better, and the loads at create took 1.85 ms at the median and 50 ms at worst. So the rule may be keeping the costly mode on a class of cards from one PC's result. Could Auto be `create` on the fallback as well, behind the safety net that already takes an install back to `start`? **Setup.** Main 6c9edffe with ea6dc5f5 (the mirror retry of https://git.magicbean.dev/MagicBeanDev/Longshot/pulls/288) cherry-picked. RX 5600 XT 6 GB (RDNA1, the compute fallback), Adrenalin 26.10.1, Ryzen 5 5600X, 24.5 GB of RAM, a 15.6 GB page file (Windows-managed), the game on an NVMe disk, Windows 11. Render resolution 50% of 1920x1080; `RX_VK_MIRROR_SPARSE=0`, `RX_VK_WB_MAX_KB=1024`, `RX_VK_NO_PREDICT=1`, `RX_VK_NO_WARM=1`; Threaded rendering Auto (on). Five areas by teleport, standing, 25 s each after 10 s; three rounds interleaved with other sides. fps, then the GPU's frame in ms; one cell a run: | Area (draws) | Loaded at start (the default here) | `RX_VK_LOAD=create` | |---|---|---| | Kokiri Forest (800) | 58.4 / 60.9 / 60.1; 12.8 / 12.3 / 12.5 | 60.8 / 60.7 / 61.2; 12.2 / 12.0 / 12.0 | | Hyrule Field (1,230) | 62.6 / 56.7 / 63.0; 12.5 / 12.8 / 12.3 | 56.0 / 57.5 / 59.2; 12.8 / 12.4 / 12.2 | | Market (2,710) | 36.7 / 36.6 / 31.2; 17.4 / 18.4 / 19.3 | 24.4 / 35.8 / 38.8; 22.2 / 17.7 / 17.2 | | Hyrule Castle (2,020) | 34.5 / 33.2 / 38.1; 22.5 / 23.4 / 21.0 | 38.7 / 38.5 / 41.5; 18.7 / 18.3 / 18.1 | | Desert Colossus (1,215) | 29.0 / 29.2 / 30.8; 29.5 / 29.4 / 26.9 | 32.4 / 31.7 / 34.1; 25.8 / 25.9 / 25.8 | | The game's private memory | 23.4-24.9 GB | 18.2-19.9 GB | | `commit limit near` lines a run | 13-16 | 0 | ``` vk: programs are loaded before the title (start): this GPU draws mesh programs through the compute fallback (RX_VK_LOAD=create or start says which) vk: commit limit near: 2507 MB of commit left (reserve 2560 MB); the textures' budget down to 0 MB of their 304 MB (RX_VK_COMMIT_RESERVE_MB) vk: program loads at create (play): 6294 queued, 6294 loaded (median 1.85 ms, 99th percentile 13.88 ms, worst 50.28 ms, 18768 ms and 1385.6 MB read in all); 8419 programs (978 of them compute variants without their code, ... vk: a frame: 0.1 draws left out (not ready), 0.00 waits for shaders or pipelines (0.0 ms) ``` - Hyrule Castle and the Desert Colossus, where the GPU is the limit, gain 3-5 fps and lose 3-4 ms of GPU a frame. Hyrule Field may lose a few fps (one round of three is level); the Market swings by run on both sides. - The run that did not finish: with the default load and sparse mirrors, a 12-area run stayed at the load into Hyrule Field for 18 minutes (5 draws a frame, the control bridge's teleports timing out) until I closed it. The game's private memory was 26.2 GB and the `commit limit near` line above was the last of its kind before it. - The start mode has grown since main 9c9d69ed (I take it to be the 22,987 pipelines of https://git.magicbean.dev/MagicBeanDev/Longshot/pulls/563, but did not bisect): in six interleaved runs of one six-area walk, 9c9d69ed held 22.0-23.4 GB and logged no `commit limit near`, and 6c9edffe held 24.3-25.9 GB and logged it 19-20 times a run. **The questions:** 1. Was the RX 580's result the fallback, or that PC (16 GB, its disk)? Its tours waited 2.5-4.7 s in all at create; this card's loads summed 18.8 s of work but the longest single one was 50 ms, so I may be reading a different number than the one the rule was made from. Which log line is the one to compare? 2. If it is the PC and not the fallback: could Auto pick `create` on the fallback too, and leave the marker (`longshot_load_start.txt`) to take a slow PC back? 3. Short of that: on a PC where the commit left is under the reserve at the title, should `start` give way by itself? **Who can help without writing code:** anyone with a card without mesh shaders (RX 5500 XT / 5600 / 5700, RX 500 series, GTX 10 series, Intel before Arc). Add `RX_VK_LOAD=create` to `longshot_env.txt` in the game's folder, play ten minutes through a few areas, and comment with the card, the RAM, the log's `program loads at create (play)` line and whether you saw hitches or things missing on entering an area. ### Anything else - Not tested: a session longer than these five-minute runs with `create`, a first visit to areas the preparation did not cover, a slow disk, 16 GB of RAM, Linux. - These are scripted runs through the control bridge, standing still after a teleport. A person entering areas on foot loads them differently. - The same runs with sparse mirrors are in https://git.magicbean.dev/MagicBeanDev/Longshot/issues/585: there the default load is what makes sparse mirrors slow on this card. - Related, for what happens once the commit limit is reached: https://git.magicbean.dev/MagicBeanDev/Longshot/issues/333.

👀 1

waryxxful referenced this issue

2026-11-15 13:13:35 +00:00

Idea: sparse mirrors cost 1-4 ms of GPU a frame on an RX 5600 XT; whole mirrors are faster until their budget fills (runs wanted on other 6 GB cards) #585

BeanIssues added the

labels

2026-11-15 13:13:45 +00:00

BeanIssues commented

2026-11-15 13:13:45 +00:00

Collaborator

Possibly related, for context:

#585 Idea: sparse mirrors cost 1-4 ms of GPU a frame on an RX 5600 XT; whole mirrors are faster until their budget fills (runs wanted on other 6 GB cards) — Same RX 5600 XT and related compute-fallback performance behavior; this issue examines sparse mirrors, not shader-loading policy.
#770 Game: Hyrule Field on RX 9070 XT — first-use pipeline stalls and Windows commit pressure (AI Assisted) - Worth looking into — Related Windows commit-pressure and pipeline-loading measurements on a different GPU.

Possibly related, for context: - #585 Idea: sparse mirrors cost 1-4 ms of GPU a frame on an RX 5600 XT; whole mirrors are faster until their budget fills (runs wanted on other 6 GB cards) — Same RX 5600 XT and related compute-fallback performance behavior; this issue examines sparse mirrors, not shader-loading policy. - #770 Game: Hyrule Field on RX 9070 XT — first-use pipeline stalls and Windows commit pressure (AI Assisted) - Worth looking into — Related Windows commit-pressure and pipeline-loading measurements on a different GPU.

BeanIssues referenced this issue

2026-11-15 15:33:18 +00:00

Game: Longshot closed unexpectedly while you were playing #820

BeanIssues referenced this issue

2026-11-15 15:49:36 +00:00

Game: #825