MagicBeanDev/Longshot

Watch

Fork 71

Game: on 16 GB of RAM the game's memory outgrows RAM within a minute of loading a save, then swap fills on area changes until RAM is at 0 #388

New issue

Open

opened 2026-11-14 07:37:37 +00:00 by tonesi · 2 comments

tonesi commented

2026-11-14 07:37:37 +00:00

Contributor

Longshot version

v3.0.0-rc.3 (source 51559a15)

Channel

Release candidate

What kind of problem

Performance / memory

What happened

On a 16 GB PC the game's memory is larger than the RAM from the first minute of play, and every area change pushes more
of it into swap. In an 11-minute session available RAM reached 0 and swap was 15 of the 15.4 GB zram device when I
quit, outside Kakariko. I expected a 9.8 GB guest window to fit on a 16 GB PC with room for the desktop. The game didn't
crash (I closed it), but it was close to running out of memory.

I sampled the game process (/proc/<pid>/status and smaps_rollup), /proc/meminfo, zram and nvidia-smi every 5 s
while playing normally. The game's memory = resident + swapped (MB):

Time	What I was doing	RAM available	Swap used	Game resident	Game swapped	Game total	VRAM used
0:00	game started	11,029	800	1,182	0	1,182	689
0:31	loading the save	3,886	899	8,921	102	9,024	1,284
0:47		644	2,739	12,148	1,943	14,092	3,678
1:02	entering Zora's Domain from the river	962	8,427	9,698	7,430	17,128	6,590
9:04	leaving Zora's Domain	721	9,412	9,131	8,385	17,516	6,913
10:10	in Hyrule Field	765	10,285	8,458	9,245	17,703	7,373
10:34		0	11,599	7,229	10,538	17,767	7,126
11:20	running toward Kakariko	0	14,881	4,303	13,582	17,885	6,998
11:27	quit outside Kakariko	25	15,097	5,613	13,774	19,387	6,646
11:37	5 s after the game exited	13,185	1,200	-	-	-	504

What it shows:

The footprint is too big from the start. The game total passes the PC's 15.7 GB of RAM about a minute in, while
the save loads. During the load the game's private memory reaches 8.3 GB (RssAnon) on top of the guest window,
then most of it goes to swap or is freed (0.8 GB by 9:00).
Most of what is resident or swapped is the shared guest window (memfd/shmem: 7.4 GB resident at 9:00, and most
of the swapped part). The log's vk: memory: working set ... (peak 12155) agrees.
Area changes add to it and nothing is given back. Hyrule Field added about 1.9 GB in a minute (17.5 → 19.4 GB)
and swap went from 9.9 to 15.1 GB. The log's vk: imports: line went from 87 live (1480 MB) to 106 live (1912 MB)
over the same stretch. In four longer sessions on 2026-11-13 (same build) imports only grew, from 36 MB up to
2.3–4.8 GB (360 live) by the end of each session.
Swap is given back at once when the game exits (15.1 → 1.2 GB), so it is the game's memory, not other programs.
The other programs used little: the largest was under 400 MB the whole time (desktop compositor, terminal).
My swap is mostly zram (compressed, held in RAM: 7.3 GB of RAM at the end), so I didn't see disk thrashing. On a PC
whose swap is on disk the same footprint would likely stutter much more.

Steps: load a save on a 16 GB PC, play for ten minutes with two or three area changes, and watch swap
(free -m, swapon --show).

Where in the game

Child Link: Zora's River → Zora's Domain → back out → Hyrule Field → outside Kakariko. Normal play.

How often

Every session: the four logs from 2026-11-13 show the same pattern (working set peaking at 10.5–13.5 GB, then the game's
own memory being swapped out while imports grow).

Graphics card and driver version

NVIDIA GeForce RTX 3070 Ti 8 GB, driver 595.104.02

CPU, RAM and operating system

Intel Core i7-12700K, 16 GB RAM (15,757 MB usable), swap 15.4 GB zram + 4 GB partition; Pop!_OS 24.04 (COSMIC),
kernel 7.2.15

Changes from the defaults

Quality preset Custom, from Auto (this PC), which picks tier 3 here; the memory budgets are still the Balanced (8GB) preset's
(memory_budget=3, VRAM budget row 4.8 GB). NVIDIA DLSS on, rendering 1920x1080 to a 2560x1440 output (the log:
NVIDIA DLSS: ... 1920x1080 ... -> 2560x1440, mode 2, preset K). Frame rate cap off, frame generation off, windowed.
No longshot_env.txt, no overlays or injectors.

Possibly related to the v2.1.0 "RAM and VRAM fill up over play time" report,
https://github.com/NotRexed/Hookshot/issues/993, but this build doesn't crash and the growth is mostly the shared guest
window and imports.

Before you send it

Seen on v3.0.0-rc.3; not yet tried on the newest nightly.
I searched the open issues: none covers this.
No game files, keys, executable, caches or saves attached. longshot_log.txt for this session follows in a comment.

### Longshot version v3.0.0-rc.3 (source 51559a15) ### Channel Release candidate ### What kind of problem Performance / memory ### What happened On a 16 GB PC the game's memory is larger than the RAM from the first minute of play, and every area change pushes more of it into swap. In an 11-minute session available RAM reached 0 and swap was 15 of the 15.4 GB zram device when I quit, outside Kakariko. I expected a 9.8 GB guest window to fit on a 16 GB PC with room for the desktop. The game didn't crash (I closed it), but it was close to running out of memory. I sampled the game process (`/proc/<pid>/status` and `smaps_rollup`), `/proc/meminfo`, zram and `nvidia-smi` every 5 s while playing normally. The game's memory = resident + swapped (MB): | Time | What I was doing | RAM available | Swap used | Game resident | Game swapped | Game total | VRAM used | |---|---|---:|---:|---:|---:|---:|---:| | 0:00 | game started | 11,029 | 800 | 1,182 | 0 | 1,182 | 689 | | 0:31 | loading the save | 3,886 | 899 | 8,921 | 102 | 9,024 | 1,284 | | 0:47 | | 644 | 2,739 | 12,148 | 1,943 | 14,092 | 3,678 | | 1:02 | entering Zora's Domain from the river | 962 | 8,427 | 9,698 | 7,430 | 17,128 | 6,590 | | 9:04 | leaving Zora's Domain | 721 | 9,412 | 9,131 | 8,385 | 17,516 | 6,913 | | 10:10 | in Hyrule Field | 765 | 10,285 | 8,458 | 9,245 | 17,703 | 7,373 | | 10:34 | | **0** | 11,599 | 7,229 | 10,538 | 17,767 | 7,126 | | 11:20 | running toward Kakariko | **0** | 14,881 | 4,303 | 13,582 | 17,885 | 6,998 | | 11:27 | quit outside Kakariko | 25 | 15,097 | 5,613 | 13,774 | **19,387** | 6,646 | | 11:37 | 5 s after the game exited | 13,185 | 1,200 | - | - | - | 504 | What it shows: - **The footprint is too big from the start.** The game total passes the PC's 15.7 GB of RAM about a minute in, while the save loads. During the load the game's private memory reaches 8.3 GB (`RssAnon`) on top of the guest window, then most of it goes to swap or is freed (0.8 GB by 9:00). - **Most of what is resident or swapped is the shared guest window** (memfd/shmem: 7.4 GB resident at 9:00, and most of the swapped part). The log's `vk: memory: working set ... (peak 12155)` agrees. - **Area changes add to it and nothing is given back.** Hyrule Field added about 1.9 GB in a minute (17.5 → 19.4 GB) and swap went from 9.9 to 15.1 GB. The log's `vk: imports:` line went from 87 live (1480 MB) to 106 live (1912 MB) over the same stretch. In four longer sessions on 2026-11-13 (same build) imports only grew, from 36 MB up to 2.3–4.8 GB (360 live) by the end of each session. - **Swap is given back at once when the game exits** (15.1 → 1.2 GB), so it is the game's memory, not other programs. The other programs used little: the largest was under 400 MB the whole time (desktop compositor, terminal). - My swap is mostly zram (compressed, held in RAM: 7.3 GB of RAM at the end), so I didn't see disk thrashing. On a PC whose swap is on disk the same footprint would likely stutter much more. Steps: load a save on a 16 GB PC, play for ten minutes with two or three area changes, and watch swap (`free -m`, `swapon --show`). ### Where in the game Child Link: Zora's River → Zora's Domain → back out → Hyrule Field → outside Kakariko. Normal play. ### How often Every session: the four logs from 2026-11-13 show the same pattern (working set peaking at 10.5–13.5 GB, then the game's own memory being swapped out while imports grow). ### Graphics card and driver version NVIDIA GeForce RTX 3070 Ti 8 GB, driver 595.104.02 ### CPU, RAM and operating system Intel Core i7-12700K, 16 GB RAM (15,757 MB usable), swap 15.4 GB zram + 4 GB partition; Pop!_OS 24.04 (COSMIC), kernel 7.2.15 ### Changes from the defaults Quality preset Custom, from Auto (this PC), which picks tier 3 here; the memory budgets are still the Balanced (8GB) preset's (`memory_budget=3`, VRAM budget row 4.8 GB). NVIDIA DLSS on, rendering 1920x1080 to a 2560x1440 output (the log: `NVIDIA DLSS: ... 1920x1080 ... -> 2560x1440, mode 2, preset K`). Frame rate cap off, frame generation off, windowed. No `longshot_env.txt`, no overlays or injectors. ### Related Possibly related to the v2.1.0 "RAM and VRAM fill up over play time" report, https://github.com/NotRexed/Hookshot/issues/993, but this build doesn't crash and the growth is mostly the shared guest window and imports. ### Before you send it - Seen on v3.0.0-rc.3; not yet tried on the newest nightly. - I searched the open issues: none covers this. - No game files, keys, executable, caches or saves attached. `longshot_log.txt` for this session follows in a comment.

tonesi commented

2026-11-14 07:53:02 +00:00

Author

Contributor

Claimed: I'm working on this on the PC it was reported from (RTX 3070 Ti 8 GB, 16 GB RAM, zram, Pop!_OS 24.04).

Score (docs/workflow.md): severity S0 (8), since past 0 MB available the next step is the out-of-memory killer or a
frozen desktop; reach about 0.4 (16 GB is the most common RAM size; Windows meets the same footprint at its commit
limit, #333); confidence 0.4 for now (one report with a log),
1.0 once reproduced on main. About 1.3.

Plan: reproduce on current main with a scripted route across area changes and the same 5 s sampler, then work out
what holds each part (the load's anonymous peak, the guest window's resident pages, the imports that are never given
back) and change one thing at a time, measured.

Overlapping work I'll build on rather than redo:

#223 (Linux memory pressure; shader modules let go after the
precompile, which is most of the anonymous peak on the Deck)
#334 and #335 (pool imports)
#346 (the page files' room to grow under the commit rule)
#91 (Water Temple load freezing on a low-RAM Linux laptop)
the growth-over-play tour on Windows (https://github.com/NotRexed/Hookshot/issues/993)

Claimed: I'm working on this on the PC it was reported from (RTX 3070 Ti 8 GB, 16 GB RAM, zram, Pop!_OS 24.04). Score (docs/workflow.md): severity S0 (8), since past 0 MB available the next step is the out-of-memory killer or a frozen desktop; reach about 0.4 (16 GB is the most common RAM size; Windows meets the same footprint at its commit limit, https://git.magicbean.dev/MagicBeanDev/Longshot/issues/333); confidence 0.4 for now (one report with a log), 1.0 once reproduced on `main`. About 1.3. Plan: reproduce on current `main` with a scripted route across area changes and the same 5 s sampler, then work out what holds each part (the load's anonymous peak, the guest window's resident pages, the imports that are never given back) and change one thing at a time, measured. Overlapping work I'll build on rather than redo: - https://git.magicbean.dev/MagicBeanDev/Longshot/pulls/223 (Linux memory pressure; shader modules let go after the precompile, which is most of the anonymous peak on the Deck) - https://git.magicbean.dev/MagicBeanDev/Longshot/pulls/334 and https://git.magicbean.dev/MagicBeanDev/Longshot/pulls/335 (pool imports) - https://git.magicbean.dev/MagicBeanDev/Longshot/pulls/346 (the page files' room to grow under the commit rule) - https://git.magicbean.dev/MagicBeanDev/Longshot/issues/91 (Water Temple load freezing on a low-RAM Linux laptop) - the growth-over-play tour on Windows (https://github.com/NotRexed/Hookshot/issues/993)

tonesi referenced this issue

2026-11-14 11:49:47 +00:00

perf(vk): skip the pipeline cache file on Linux NVIDIA PCs with 20 GB of RAM or less (0.7-0.8 GB less) #416

tonesi commented

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

Author

Contributor

Reproduced on current main (0caf0618) on the reporting PC (RTX 3070 Ti 8 GB, driver 595.104.02, i7-12700K, 16 GB RAM, zram,
Pop!_OS 24.04), and taken apart. Confidence is now 1.0 (reproduced with logs), so the score is about 3.2.

How it was measured. A scripted tour through the control bridge: the save at Zora's River loaded, then the debug teleport
through Zora's Domain, Hyrule Field, Kakariko, the Market, Kokiri Forest, Lake Hylia, Death Mountain Trail and Goron City, 40 s
in each with a walk and camera turns (about 7 minutes). The game's memory was sampled every 2 s from /proc/<pid>/status and
smaps_rollup (resident + swapped, as in the report), with /proc/meminfo beside it. The runs were windowless, at the
reporter's settings (memory_budget=3, 2560x1440 output). These are memory observations, and fps is reported as an
observation only.

What main already fixed. a4c77174 (#324, after rc.3) tells the game
how many pages it has mapped. On main its mapped pages stop at about 2.8 GB, against the 7.9-8.4 GB of the rc.3 sessions. The
guest window (the game's own memory, resident + swapped) peaked at 7.0-8.1 GB in every run here (7.4-7.6 GB in most), against 9+ GB in the report.

What is left, by part (one tour each, game total = private + guest window, resident + swapped):

	programs loaded at create (the default with mesh shaders)	programs loaded before the title (the reporter's install)
game total at the save load	8.2 GB	13.4 GB
game total at the end	12.1 GB	15.4 GB
peak	12.3-12.6 GB	16.2 GB
private (anonymous) memory at the end, resident + swapped	5.1 GB	8.6 GB
guest window peak	7.4-7.5 GB	7.5 GB
live imports at the end	2.2-2.3 GB	2.2 GB
lowest MemAvailable	0.4-1.0 GB	0

Programs loaded before the title is where 16 GB runs out. The install had longshot_load_start.txt: "In one session
508 listed pipelines were in no cache when their programs were loaded" (500 is the limit). From then on every start keeps
the shader modules of about 19,400 programs: 8.5 GB of private memory, which the kernel pushes to swap at once. That is
the 8.3 GB RssAnon of the report. #223 lets those modules go on
Linux PCs of 20 GB or less. A cold NVIDIA cache gave 1,903 such misses in one run here and set the marker as well.
With programs loaded at create, private memory grows with each area: 2.9 GB at the save load, then 5.1-5.2 GB after
eight areas. The close's census says what it is: 7,391 programs loaded (1.39 GB of their code read into the driver's
modules, which are never let go) and 10,686 graphics pipelines built for them, of which draws took 3,859. Another 1.2 GB
is the pipeline cache's file, read whole at the start and kept by the driver.
The guest window is the game's own memory. Its pages under a GPU import are zeroed instead of given back when the game
frees them: 11.6 GB was zeroed over one tour. I wrote and measured a change that gives back the parts no import holds. It
moved nothing, because the game mapped 11.9 of those 12.7 GB again at once (it recycles the same pools). That is a measured
dead end, not a leak.
Live imports (2.2 GB) only grow on 16 GB, because the give-back valve's budget there is NVIDIA's 11.8 GB system heap.
RX_VK_IMPORT_CAP_MB=2000 halved them (1.0 GB), but the game's total didn't move: the pages are the game's and only become
swappable.

Hill-climbing (one change at a time from main's behaviour, accepted only if the game's total went down beyond run-to-run
noise without an fps or hitch cost; rounds 1-2 on one build with switches, where HOS_FREED_* turned the host change on and off):

round	change	game's private memory + its swap at the end	peak total	verdict
start	main	5,148 / 5,099 MB	12,291 / 12,647 MB
1	freed pages split around imports (code)	5,155	12,415	no change: rejected
1	`RX_VK_PCACHE_LOAD=0`	4,294 / 4,393	11,864 / 11,823	kept (fps 54.2 / 55.0 against 51.9 / 54.4)
1	`RX_VK_IMPORT_CAP_MB=2000`	5,183	12,427	imports halved, total the same: rejected
1	`MALLOC_ARENA_MAX=2`	5,085	12,489	no change: rejected
1	`RX_VK_MALLOC_TRIM_MB=16`	5,089	12,967	no change: rejected
2	`RX_VK_PCACHE_LOAD=0`, programs loaded before the title	8,409 (8,643 without)	16,067 (16,244)	no saving, precompile 29 s against 15 s: not there
4	on top of 1's kept step: 4 load workers while loading, or 4 throughout	4,338-4,486	11,817-12,109	the draws' waits not won back (209-251 ms): rejected

The kept step is #416. On a Linux PC with NVIDIA's driver and 20 GB of RAM or
less, with programs loaded at create, it leaves the pipeline cache file unread, and NVIDIA's own disk cache answers instead.
Against main, three interleaved runs each: the game's peak was 831 MB lower (11.9 against 12.7 GB, medians) and the lowest
MemAvailable 329 MB higher, with 1.3 GB less swap in use and the same fps. What it costs: a load at create takes 5.0 against
1.8 ms on the load workers, and draws waited for a load 10 times against 2 per tour (206 against 52 ms). More load workers
didn't win that back. It also stops RX_VK_PCACHE_LOAD=0 from writing a small cache over the 1.2 GB file once 16 play files
have piled up. Test request T-XTVW asks for a longer session on another 16 GB Linux NVIDIA PC.

What it does not fix, and the follow-ups I'd suggest (not claimed):

Programs loaded before the title on 16 GB: #223 (modules let go after the
precompile). The marker's switch to start mode is a 5 GB step for good on a 16 GB PC. It could take that into account, or
ask for a new preparation instead (the marker's text already suggests one).
With programs loaded at create, modules are kept for the session (1.4 GB over this tour, more in longer ones). They could
go once a program's noted pipelines are built, as #223 does after the
precompile. Or graphics pipelines could be made from module identifiers, as compute ones already are
(module_ids.h), with the code read only for a variant that must be compiled.

Measured by an AI agent (Claude Code) on the reporter's PC.

Reproduced on current `main` (0caf0618) on the reporting PC (RTX 3070 Ti 8 GB, driver 595.104.02, i7-12700K, 16 GB RAM, zram, Pop!_OS 24.04), and taken apart. Confidence is now 1.0 (reproduced with logs), so the score is about 3.2. **How it was measured.** A scripted tour through the control bridge: the save at Zora's River loaded, then the debug teleport through Zora's Domain, Hyrule Field, Kakariko, the Market, Kokiri Forest, Lake Hylia, Death Mountain Trail and Goron City, 40 s in each with a walk and camera turns (about 7 minutes). The game's memory was sampled every 2 s from `/proc/<pid>/status` and `smaps_rollup` (resident + swapped, as in the report), with `/proc/meminfo` beside it. The runs were windowless, at the reporter's settings (`memory_budget=3`, 2560x1440 output). These are memory observations, and fps is reported as an observation only. **What main already fixed.** a4c77174 (https://git.magicbean.dev/MagicBeanDev/Longshot/pulls/324, after rc.3) tells the game how many pages it has mapped. On main its mapped pages stop at about 2.8 GB, against the 7.9-8.4 GB of the rc.3 sessions. The guest window (the game's own memory, resident + swapped) peaked at 7.0-8.1 GB in every run here (7.4-7.6 GB in most), against 9+ GB in the report. **What is left, by part** (one tour each, game total = private + guest window, resident + swapped): | | programs loaded at create (the default with mesh shaders) | programs loaded before the title (the reporter's install) | |---|---:|---:| | game total at the save load | 8.2 GB | 13.4 GB | | game total at the end | 12.1 GB | 15.4 GB | | peak | 12.3-12.6 GB | **16.2 GB** | | private (anonymous) memory at the end, resident + swapped | 5.1 GB | 8.6 GB | | guest window peak | 7.4-7.5 GB | 7.5 GB | | live imports at the end | 2.2-2.3 GB | 2.2 GB | | lowest MemAvailable | 0.4-1.0 GB | **0** | 1. **Programs loaded before the title is where 16 GB runs out.** The install had `longshot_load_start.txt`: "In one session 508 listed pipelines were in no cache when their programs were loaded" (500 is the limit). From then on every start keeps the shader modules of about 19,400 programs: 8.5 GB of private memory, which the kernel pushes to swap at once. That is the 8.3 GB `RssAnon` of the report. https://git.magicbean.dev/MagicBeanDev/Longshot/pulls/223 lets those modules go on Linux PCs of 20 GB or less. A cold NVIDIA cache gave 1,903 such misses in one run here and set the marker as well. 2. **With programs loaded at create, private memory grows with each area**: 2.9 GB at the save load, then 5.1-5.2 GB after eight areas. The close's census says what it is: 7,391 programs loaded (1.39 GB of their code read into the driver's modules, which are never let go) and 10,686 graphics pipelines built for them, of which draws took 3,859. Another 1.2 GB is the pipeline cache's file, read whole at the start and kept by the driver. 3. **The guest window is the game's own memory.** Its pages under a GPU import are zeroed instead of given back when the game frees them: 11.6 GB was zeroed over one tour. I wrote and measured a change that gives back the parts no import holds. It moved nothing, because the game mapped 11.9 of those 12.7 GB again at once (it recycles the same pools). That is a measured dead end, not a leak. 4. **Live imports (2.2 GB) only grow on 16 GB**, because the give-back valve's budget there is NVIDIA's 11.8 GB system heap. `RX_VK_IMPORT_CAP_MB=2000` halved them (1.0 GB), but the game's total didn't move: the pages are the game's and only become swappable. **Hill-climbing** (one change at a time from main's behaviour, accepted only if the game's total went down beyond run-to-run noise without an fps or hitch cost; rounds 1-2 on one build with switches, where `HOS_FREED_*` turned the host change on and off): | round | change | game's private memory + its swap at the end | peak total | verdict | |---|---|---:|---:|---| | start | main | 5,148 / 5,099 MB | 12,291 / 12,647 MB | | | 1 | freed pages split around imports (code) | 5,155 | 12,415 | no change: rejected | | 1 | `RX_VK_PCACHE_LOAD=0` | **4,294 / 4,393** | **11,864 / 11,823** | **kept** (fps 54.2 / 55.0 against 51.9 / 54.4) | | 1 | `RX_VK_IMPORT_CAP_MB=2000` | 5,183 | 12,427 | imports halved, total the same: rejected | | 1 | `MALLOC_ARENA_MAX=2` | 5,085 | 12,489 | no change: rejected | | 1 | `RX_VK_MALLOC_TRIM_MB=16` | 5,089 | 12,967 | no change: rejected | | 2 | `RX_VK_PCACHE_LOAD=0`, programs loaded before the title | 8,409 (8,643 without) | 16,067 (16,244) | no saving, precompile 29 s against 15 s: not there | | 4 | on top of 1's kept step: 4 load workers while loading, or 4 throughout | 4,338-4,486 | 11,817-12,109 | the draws' waits not won back (209-251 ms): rejected | The kept step is https://git.magicbean.dev/MagicBeanDev/Longshot/pulls/416. On a Linux PC with NVIDIA's driver and 20 GB of RAM or less, with programs loaded at create, it leaves the pipeline cache file unread, and NVIDIA's own disk cache answers instead. Against main, three interleaved runs each: the game's peak was 831 MB lower (11.9 against 12.7 GB, medians) and the lowest MemAvailable 329 MB higher, with 1.3 GB less swap in use and the same fps. What it costs: a load at create takes 5.0 against 1.8 ms on the load workers, and draws waited for a load 10 times against 2 per tour (206 against 52 ms). More load workers didn't win that back. It also stops `RX_VK_PCACHE_LOAD=0` from writing a small cache over the 1.2 GB file once 16 play files have piled up. Test request T-XTVW asks for a longer session on another 16 GB Linux NVIDIA PC. What it does not fix, and the follow-ups I'd suggest (not claimed): - Programs loaded before the title on 16 GB: https://git.magicbean.dev/MagicBeanDev/Longshot/pulls/223 (modules let go after the precompile). The marker's switch to start mode is a 5 GB step for good on a 16 GB PC. It could take that into account, or ask for a new preparation instead (the marker's text already suggests one). - With programs loaded at create, modules are kept for the session (1.4 GB over this tour, more in longer ones). They could go once a program's noted pipelines are built, as https://git.magicbean.dev/MagicBeanDev/Longshot/pulls/223 does after the precompile. Or graphics pipelines could be made from module identifiers, as compute ones already are (`module_ids.h`), with the code read only for a variant that must be compiled. *Measured by an AI agent (Claude Code) on the reporter's PC.*

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

MagicBeanDev/Longshot#388

No description provided.

Rows
Columns