MagicBeanDev/Longshot
MagicBeanDev/Longshot
Watch
55
68
Fork
You've already forked Longshot
 71
Code Issues 125 Pull requests 195 Projects Releases 8 Packages Wiki Activity Actions 445

feat(log): the recording streams' line counts the descriptor pools made when a recording's own ran out #387

Open
p0lux wants to merge 3 commits from p0lux/Longshot:feat/desc-pool-count into main
pull from: p0lux/Longshot:feat/desc-pool-count
merge into: MagicBeanDev:main
Conversation 1 Commits 3 Files changed 8 +22 -7
p0lux commented 2026-11-14 07:28:52 +00:00
Contributor

Why

A recording's descriptor pool is 8192 sets of up to 32768 descriptors a type, 24 or 48 of them at once, and the driver keeps memory for all of it: on a Steam Deck a quarter of that (RX_VK_DESC_POOL_DIV=4, an existing switch) gives back about 130 MB of GPU memory. Whether a smaller default is safe depends on how often a recording then runs out of its pool, and nothing said. This adds that count to a log line. Its first values: a half never runs out in three scenes, a quarter does once or twice in Kokiri Forest, an eighth and a sixteenth hundreds of times.

What changed

  • draw: pools_extra in gpu/vk/vk_draw.cpp, counted in bind_descriptors() where a pool made because the recording's own ran out is kept (cur->extra), and written at the end of the "recording streams" line that draw_begin_recording() logs every 3,000 recordings. make_pool()'s comment says where to read it.
  • docs: RX_VK_DESC_POOL_DIV in docs/development.md's switch reference (it was not there), with the line that counts; two run files in docs/tested/.
  • checks: tests/recording_admission_test.cpp checks a kept extra pool is counted and one that could not be kept is not; it, tests/sampler_admission_test.cpp, tests/draw_stream_visibility_test.cpp and tests/fsr_uniform_ownership_test.cpp declare the counter, since they cut this code out of the source.

Flags and settings

None new or changed. RX_VK_DESC_POOL_DIV=<1..32> (existing, unset by default: the full size) is what the count is for; it is now in the switch reference.

Measurements

main: 514591a3 (2026-11-13)
this PR: feat/desc-pool-count @ d4b89309 (this PR's code commit, a593baaa, on that main; on the fork as measured/desc-pool-count-d4b89309). The branch itself is on main 0caf0618: its code is the same change (git range-diff shows only the neighbouring rows of docs/development.md differing). Between the two mains the pools' code changed in one place, which does not change how many a recording makes: their reset at a recording's start is now inside a recorder scope (rec::OwnSlot, for RX_VK_RECORDER_OWN). So these numbers still hold. It was measured on 514591a3 because the game folder on the Deck is a build of an earlier main, in which 514591a3's back end is known to run; main's vk_api.h has changed since (#136, #137).
Hardware: Steam Deck OLED (AMD Custom APU 0932, RADV VANGOGH, Mesa 26.2.0-devel), 16 GB shared with the GPU, SteamOS 3.9.5, kernel 7.2.7-valve2; the GPU's clock fixed at 1600 MHz
Scene: three saves, standing still: a heavy view (about 2,100 draws a frame), Kokiri Forest (about 2,550), Hyrule Field (about 1,600); no screen (headless), handheld profile, Minimum preset, the game's own upscaler, no frame generation, no cap
Method: the back end built alone from each commit (clang, same flags), swapped in one game folder. Each run starts the game, loads the save by script, waits 3 log windows (the first 360 presents in game), then measures 720 presents: fps by the clock, the log's replay time, and the render thread's user-space cycles and instructions a frame (perf stat -t). Main then this PR, alternated: 3 runs each on the heavy view, 2 in Kokiri Forest. Then this PR's renderer alone with RX_VK_DESC_POOL_DIV unset, 2, 4, 8 and 16: the count is the last "recording streams" line of the run's log (so since the start of the run), memory is read at the end of the measured span from /proc/<pid>/fdinfo (drm-memory-gtt) and /proc/meminfo, KiB divided by 1,024
How to reproduce: RX_VK_DESC_POOL_DIV=8 in longshot_env.txt, a save in Kokiri Forest, and after a minute grep "recording streams" longshot_log.txt

The count costs nothing (medians; each run in brackets, in the order run):

main @ 514591a3 this PR @ d4b89309 Δ
heavy view: fps 23.99 (23.99 / 23.99 / 23.89) 24.05 (24.22 / 24.02 / 24.05) +0.06
heavy view: replay 26.69 ms (26.92 / 26.69 / 26.56) 26.59 ms (26.59 / 26.85 / 26.39) -0.10 ms
heavy view: cycles a frame 78.26 M (78.68 / 78.23 / 78.26) 78.06 M (78.06 / 78.66 / 77.95) -0.3%
heavy view: instructions a frame 62.68 M (62.42 / 62.68 / 62.85) 62.56 M (62.56 / 63.00 / 62.54) -0.2%
Kokiri Forest: fps 22.40 (22.39 / 22.40) 22.58 (22.40 / 22.75) +0.18
Kokiri Forest: replay 32.02 ms (31.88 / 32.16) 33.00 ms (33.11 / 32.88) +0.98 ms
Kokiri Forest: cycles a frame 91.05 M (90.79 / 91.30) 92.98 M (92.69 / 93.27) +2.1%
Kokiri Forest: instructions a frame 83.81 M (83.64 / 83.98) 85.67 M (84.38 / 86.96) +2.2%

Kokiri Forest's work a frame varies from run to run by more than the two renderers differ: this PR's renderer alone ran 83.17 to 88.10 M instructions a frame over its eight runs there, and the lowest was the run that made 1,044 pools. At the full size the counted path is not taken (0 below), so the change is nine more words in a line logged every 3,000 recordings.

What the count says, this PR's renderer, one run a cell unless two or three values are given:

descriptor pools made when a recording's own ran out this PR @ d4b89309, unset (full size) this PR @ d4b89309, RX_VK_DESC_POOL_DIV=2 this PR @ d4b89309, RX_VK_DESC_POOL_DIV=4 this PR @ d4b89309, RX_VK_DESC_POOL_DIV=8 this PR @ d4b89309, RX_VK_DESC_POOL_DIV=16
heavy view 0 / 0 / 0 0 0 1 7
Kokiri Forest 0 / 0 0 1 / 2 716 / 681 1,044
Hyrule Field 0 0 0 0 0
fps, heavy view 24.22 / 24.02 / 24.05 23.86 24.24 24.32 23.95
fps, Kokiri Forest 22.40 / 22.75 22.27 22.50 / 22.55 22.84 / 22.49 22.73
fps, Hyrule Field 21.33 21.21 21.26 20.96 21.06
GPU memory (drm-memory-gtt, MiB), heavy view 3,948 / 3,694 / 3,890 3,655 3,708 3,730 3,698
GPU memory, Kokiri Forest 4,050 / 4,034 3,893 3,667 / 3,902 3,844 / 3,877 3,836
GPU memory, Hyrule Field 3,525 3,456 3,467 3,373 3,387
MemAvailable (MiB, the whole system's), heavy view 1,451 / 1,749 / 1,407 1,806 1,709 1,685 1,783
MemAvailable, Kokiri Forest 1,223 / 1,203 1,525 1,642 / 1,424 1,415 / 1,438 1,520
MemAvailable, Hyrule Field 2,092 2,476 2,444 2,510 2,472 
Kokiri      vk: the recording streams: 48 of 2 MB, the most one held 866 KB; 0 made on demand (0 MB kept now); 0 descriptor pools made when a recording's own ran out
Kokiri /2   ... 0 descriptor pools made when a recording's own ran out
Kokiri /4   ... 1 descriptor pools made when a recording's own ran out        (second run: 2)
Kokiri /8   ... 716 descriptor pools made when a recording's own ran out      (second run: 681)
Kokiri /16  ... 1044 descriptor pools made when a recording's own ran out
heavy /8    ... 1 descriptor pools made when a recording's own ran out
heavy /16   ... 7 descriptor pools made when a recording's own ran out

Read with care: the memory of single runs is not a ranking. The full size's own three runs on the heavy view differ by 254 MiB of GPU memory. Every smaller size is under the full size's median in every scene, and in Kokiri Forest an eighth and a sixteenth give back no more than a quarter, since the pools they make on demand take memory too. Making 700 to 1,000 pools in a run cost no fps on this driver; what it costs on others is not measured.

The memory a smaller pool gives back was measured with rounds the evening before, on a build without this change (main fbd42024 with other renderer-only changes, 22ed63d6), the switch alone, 4 rounds alternated on the heavy view, medians:

that build @ 22ed63d6, switch unset that build @ 22ed63d6, RX_VK_DESC_POOL_DIV=4 that build @ 22ed63d6, RX_VK_DESC_POOL_DIV=16
GPU memory (drm-memory-gtt) 3,517 MiB 3,387 MiB 3,308 MiB
RssAnon 659 MiB 581 MiB 562 MiB
MemAvailable 3,664 MiB 3,881 MiB 3,960 MiB
fps 31.35 31.45 31.74

Testing

Tested:

  • python -I -B tests/run_all.py on macOS with the Vulkan headers given: 486 passed, 36 failed, 39 skipped; the 36 fail the same way on main 0caf0618 on that machine (no /proc, no posix_fallocate, an older Python, the Linux launch scripts and the like). test_recording_admission.py, test_sampler_admission.py, test_draw_stream_visibility.py and test_fsr_uniform_ownership.py, whose fixtures changed, pass.
  • In the game, a Steam Deck OLED, without a screen: the 27 runs above (main and this commit on it), no error, no device lost, 0 GPU timeouts in the kernel's log; and 9 starts the night before of a build with this change among others.
  • Linux: the back end builds from this branch's head (e0eb2244) and from the commit on main 514591a3 (clang, on the Deck): 0 failed.
  • Windows: the back end builds from this branch (4e2cd9f7; the head adds a docs file to it), cross-built with llvm-mingw 20261104 on Linux: 0 failed, longshot_vk.dll made. Not run.

Not tested:

  • Other areas (a dungeon, the Market), a moving camera, a long session; other hardware (the count comes from the game's draws and should not depend on it; the memory given back and the cost of a pool made on demand do).
  • On Windows the count was not read in the game.

Needs other testers:
None: the count comes from the game's draws, not from the hardware.

Screenshots

Nothing on screen.

Risk and rollback

One relaxed atomic increment where an extra pool is kept, which the default size does not reach in these scenes, and nine more words in a line logged every 3,000 recordings. Reverting the commit removes both.

Reviewer notes

  • This is the first of two steps. The count says a fixed smaller default would be fragile: Kokiri Forest is already at the edge of a quarter, so a heavier scene would pass it. The second step I would propose instead is a small pool whose extra pools are kept from one recording to the next (as a slot's grown streams are), so each scene holds what it uses. Say if you would rather have a fixed half or quarter.
  • A program with a handle table binds 64 textures a set (HANDLE_TABLE_SIZE, #107), which is probably what fills an eighth's 4,096 samplers in Kokiri Forest.

Issues

None.

Checklist

For everyone

  • One topic.
  • The title is a Conventional Commit (type(scope): description).
  • Rebased on current main.
  • python -I -B tests/run_all.py run and passing (any failure that also fails on main is named above).
  • Tested in the game, or what wasn't is named under Testing.
  • Testing filled in: what was tested, what wasn't, and what needs other testers (with test requests).
  • Measured: main and this PR at named commits, on the same PC, scene and settings, at least 2 interleaved runs each, the median reported.
  • No game files, dumps, build output or generated files.
  • third_party/ untouched (a new folder with a PROVENANCE.md instead).
  • The license is OK: GPL-3.0-or-later, nothing incompatible and nothing decompiled.

If applicable

  • AI assistance recorded with Assisted-by: / Co-Authored-By: trailers.
  • Flags noted, and the switch reference updated (docs/development.md, the README).
  • A file in docs/tested/ for each new measured run (format in docs/tested-configurations.md; no appended row or assembled view).
  • A check under tests/ that reads changed source updated in this PR, not weakened.
  • Host code builds on both Windows (llvm-mingw) and Linux, with UTF-8 paths.
  • Docs updated.
## Why A recording's descriptor pool is 8192 sets of up to 32768 descriptors a type, 24 or 48 of them at once, and the driver keeps memory for all of it: on a Steam Deck a quarter of that (`RX_VK_DESC_POOL_DIV=4`, an existing switch) gives back about 130 MB of GPU memory. Whether a smaller default is safe depends on how often a recording then runs out of its pool, and nothing said. This adds that count to a log line. Its first values: a half never runs out in three scenes, a quarter does once or twice in Kokiri Forest, an eighth and a sixteenth hundreds of times. ## What changed - draw: `pools_extra` in `gpu/vk/vk_draw.cpp`, counted in `bind_descriptors()` where a pool made because the recording's own ran out is kept (`cur->extra`), and written at the end of the "recording streams" line that `draw_begin_recording()` logs every 3,000 recordings. `make_pool()`'s comment says where to read it. - docs: `RX_VK_DESC_POOL_DIV` in `docs/development.md`'s switch reference (it was not there), with the line that counts; two run files in `docs/tested/`. - checks: `tests/recording_admission_test.cpp` checks a kept extra pool is counted and one that could not be kept is not; it, `tests/sampler_admission_test.cpp`, `tests/draw_stream_visibility_test.cpp` and `tests/fsr_uniform_ownership_test.cpp` declare the counter, since they cut this code out of the source. ## Flags and settings None new or changed. `RX_VK_DESC_POOL_DIV=<1..32>` (existing, unset by default: the full size) is what the count is for; it is now in the switch reference. ## Measurements main: 514591a3 (2026-11-13) this PR: feat/desc-pool-count @ d4b89309 (this PR's code commit, a593baaa, on that main; on the fork as `measured/desc-pool-count-d4b89309`). The branch itself is on main 0caf0618: its code is the same change (`git range-diff` shows only the neighbouring rows of `docs/development.md` differing). Between the two mains the pools' code changed in one place, which does not change how many a recording makes: their reset at a recording's start is now inside a recorder scope (`rec::OwnSlot`, for `RX_VK_RECORDER_OWN`). So these numbers still hold. It was measured on 514591a3 because the game folder on the Deck is a build of an earlier main, in which 514591a3's back end is known to run; main's `vk_api.h` has changed since (https://git.magicbean.dev/MagicBeanDev/Longshot/pulls/136, https://git.magicbean.dev/MagicBeanDev/Longshot/pulls/137). Hardware: Steam Deck OLED (AMD Custom APU 0932, RADV VANGOGH, Mesa 26.2.0-devel), 16 GB shared with the GPU, SteamOS 3.9.5, kernel 7.2.7-valve2; the GPU's clock fixed at 1600 MHz Scene: three saves, standing still: a heavy view (about 2,100 draws a frame), Kokiri Forest (about 2,550), Hyrule Field (about 1,600); no screen (headless), handheld profile, Minimum preset, the game's own upscaler, no frame generation, no cap Method: the back end built alone from each commit (clang, same flags), swapped in one game folder. Each run starts the game, loads the save by script, waits 3 log windows (the first 360 presents in game), then measures 720 presents: fps by the clock, the log's replay time, and the render thread's user-space cycles and instructions a frame (`perf stat -t`). Main then this PR, alternated: 3 runs each on the heavy view, 2 in Kokiri Forest. Then this PR's renderer alone with `RX_VK_DESC_POOL_DIV` unset, 2, 4, 8 and 16: the count is the last "recording streams" line of the run's log (so since the start of the run), memory is read at the end of the measured span from `/proc/<pid>/fdinfo` (`drm-memory-gtt`) and `/proc/meminfo`, KiB divided by 1,024 How to reproduce: `RX_VK_DESC_POOL_DIV=8` in `longshot_env.txt`, a save in Kokiri Forest, and after a minute `grep "recording streams" longshot_log.txt` The count costs nothing (medians; each run in brackets, in the order run): | | main @ 514591a3 | this PR @ d4b89309 | Δ | |---|---|---|---| | heavy view: fps | 23.99 (23.99 / 23.99 / 23.89) | 24.05 (24.22 / 24.02 / 24.05) | +0.06 | | heavy view: replay | 26.69 ms (26.92 / 26.69 / 26.56) | 26.59 ms (26.59 / 26.85 / 26.39) | -0.10 ms | | heavy view: cycles a frame | 78.26 M (78.68 / 78.23 / 78.26) | 78.06 M (78.06 / 78.66 / 77.95) | -0.3% | | heavy view: instructions a frame | 62.68 M (62.42 / 62.68 / 62.85) | 62.56 M (62.56 / 63.00 / 62.54) | -0.2% | | Kokiri Forest: fps | 22.40 (22.39 / 22.40) | 22.58 (22.40 / 22.75) | +0.18 | | Kokiri Forest: replay | 32.02 ms (31.88 / 32.16) | 33.00 ms (33.11 / 32.88) | +0.98 ms | | Kokiri Forest: cycles a frame | 91.05 M (90.79 / 91.30) | 92.98 M (92.69 / 93.27) | +2.1% | | Kokiri Forest: instructions a frame | 83.81 M (83.64 / 83.98) | 85.67 M (84.38 / 86.96) | +2.2% | Kokiri Forest's work a frame varies from run to run by more than the two renderers differ: this PR's renderer alone ran 83.17 to 88.10 M instructions a frame over its eight runs there, and the lowest was the run that made 1,044 pools. At the full size the counted path is not taken (0 below), so the change is nine more words in a line logged every 3,000 recordings. What the count says, this PR's renderer, one run a cell unless two or three values are given: | descriptor pools made when a recording's own ran out | this PR @ d4b89309, unset (full size) | this PR @ d4b89309, `RX_VK_DESC_POOL_DIV=2` | this PR @ d4b89309, `RX_VK_DESC_POOL_DIV=4` | this PR @ d4b89309, `RX_VK_DESC_POOL_DIV=8` | this PR @ d4b89309, `RX_VK_DESC_POOL_DIV=16` | |---|---|---|---|---|---| | heavy view | 0 / 0 / 0 | 0 | 0 | 1 | 7 | | Kokiri Forest | 0 / 0 | 0 | 1 / 2 | 716 / 681 | 1,044 | | Hyrule Field | 0 | 0 | 0 | 0 | 0 | | fps, heavy view | 24.22 / 24.02 / 24.05 | 23.86 | 24.24 | 24.32 | 23.95 | | fps, Kokiri Forest | 22.40 / 22.75 | 22.27 | 22.50 / 22.55 | 22.84 / 22.49 | 22.73 | | fps, Hyrule Field | 21.33 | 21.21 | 21.26 | 20.96 | 21.06 | | GPU memory (`drm-memory-gtt`, MiB), heavy view | 3,948 / 3,694 / 3,890 | 3,655 | 3,708 | 3,730 | 3,698 | | GPU memory, Kokiri Forest | 4,050 / 4,034 | 3,893 | 3,667 / 3,902 | 3,844 / 3,877 | 3,836 | | GPU memory, Hyrule Field | 3,525 | 3,456 | 3,467 | 3,373 | 3,387 | | `MemAvailable` (MiB, the whole system's), heavy view | 1,451 / 1,749 / 1,407 | 1,806 | 1,709 | 1,685 | 1,783 | | `MemAvailable`, Kokiri Forest | 1,223 / 1,203 | 1,525 | 1,642 / 1,424 | 1,415 / 1,438 | 1,520 | | `MemAvailable`, Hyrule Field | 2,092 | 2,476 | 2,444 | 2,510 | 2,472 | ``` Kokiri vk: the recording streams: 48 of 2 MB, the most one held 866 KB; 0 made on demand (0 MB kept now); 0 descriptor pools made when a recording's own ran out Kokiri /2 ... 0 descriptor pools made when a recording's own ran out Kokiri /4 ... 1 descriptor pools made when a recording's own ran out (second run: 2) Kokiri /8 ... 716 descriptor pools made when a recording's own ran out (second run: 681) Kokiri /16 ... 1044 descriptor pools made when a recording's own ran out heavy /8 ... 1 descriptor pools made when a recording's own ran out heavy /16 ... 7 descriptor pools made when a recording's own ran out ``` Read with care: the memory of single runs is not a ranking. The full size's own three runs on the heavy view differ by 254 MiB of GPU memory. Every smaller size is under the full size's median in every scene, and in Kokiri Forest an eighth and a sixteenth give back no more than a quarter, since the pools they make on demand take memory too. Making 700 to 1,000 pools in a run cost no fps on this driver; what it costs on others is not measured. The memory a smaller pool gives back was measured with rounds the evening before, on a build without this change (main fbd42024 with other renderer-only changes, 22ed63d6), the switch alone, 4 rounds alternated on the heavy view, medians: | | that build @ 22ed63d6, switch unset | that build @ 22ed63d6, `RX_VK_DESC_POOL_DIV=4` | that build @ 22ed63d6, `RX_VK_DESC_POOL_DIV=16` | |---|---|---|---| | GPU memory (`drm-memory-gtt`) | 3,517 MiB | 3,387 MiB | 3,308 MiB | | `RssAnon` | 659 MiB | 581 MiB | 562 MiB | | `MemAvailable` | 3,664 MiB | 3,881 MiB | 3,960 MiB | | fps | 31.35 | 31.45 | 31.74 | ## Testing **Tested:** - `python -I -B tests/run_all.py` on macOS with the Vulkan headers given: 486 passed, 36 failed, 39 skipped; the 36 fail the same way on main 0caf0618 on that machine (no `/proc`, no `posix_fallocate`, an older Python, the Linux launch scripts and the like). `test_recording_admission.py`, `test_sampler_admission.py`, `test_draw_stream_visibility.py` and `test_fsr_uniform_ownership.py`, whose fixtures changed, pass. - In the game, a Steam Deck OLED, without a screen: the 27 runs above (main and this commit on it), no error, no device lost, 0 GPU timeouts in the kernel's log; and 9 starts the night before of a build with this change among others. - Linux: the back end builds from this branch's head (e0eb2244) and from the commit on main 514591a3 (clang, on the Deck): 0 failed. - Windows: the back end builds from this branch (4e2cd9f7; the head adds a docs file to it), cross-built with llvm-mingw 20261104 on Linux: 0 failed, `longshot_vk.dll` made. Not run. **Not tested:** - Other areas (a dungeon, the Market), a moving camera, a long session; other hardware (the count comes from the game's draws and should not depend on it; the memory given back and the cost of a pool made on demand do). - On Windows the count was not read in the game. **Needs other testers:** None: the count comes from the game's draws, not from the hardware. ## Screenshots Nothing on screen. ## Risk and rollback One relaxed atomic increment where an extra pool is kept, which the default size does not reach in these scenes, and nine more words in a line logged every 3,000 recordings. Reverting the commit removes both. ## Reviewer notes - This is the first of two steps. The count says a fixed smaller default would be fragile: Kokiri Forest is already at the edge of a quarter, so a heavier scene would pass it. The second step I would propose instead is a small pool whose extra pools are kept from one recording to the next (as a slot's grown streams are), so each scene holds what it uses. Say if you would rather have a fixed half or quarter. - A program with a handle table binds 64 textures a set (`HANDLE_TABLE_SIZE`, https://git.magicbean.dev/MagicBeanDev/Longshot/pulls/107), which is probably what fills an eighth's 4,096 samplers in Kokiri Forest. ## Issues None. ## Checklist ### For everyone - [x] One topic. - [x] The title is a Conventional Commit (`type(scope): description`). - [x] Rebased on current `main`. - [x] `python -I -B tests/run_all.py` run and passing (any failure that also fails on `main` is named above). - [x] Tested in the game, or what wasn't is named under Testing. - [x] Testing filled in: what was tested, what wasn't, and what needs other testers (with test requests). - [x] Measured: main and this PR at named commits, on the same PC, scene and settings, at least 2 interleaved runs each, the median reported. - [x] No game files, dumps, build output or generated files. - [x] `third_party/` untouched (a new folder with a `PROVENANCE.md` instead). - [x] The license is OK: GPL-3.0-or-later, nothing incompatible and nothing decompiled. ### If applicable - [x] AI assistance recorded with `Assisted-by:` / `Co-Authored-By:` trailers. - [x] Flags noted, and the switch reference updated (docs/development.md, the README). - [x] A file in `docs/tested/` for each new measured run (format in `docs/tested-configurations.md`; no appended row or assembled view). - [x] A check under `tests/` that reads changed source updated in this PR, not weakened. - [x] Host code builds on both Windows (llvm-mingw) and Linux, with UTF-8 paths. - [x] Docs updated. 
A recording's descriptor pool can be made smaller (RX_VK_DESC_POOL_DIV): one that runs out is followed by another of
the same size, made and destroyed with the recording. On a Steam Deck a sixteenth gives back about 210 MB of GPU
memory and 100 MB of the process's, but nothing said what a smaller pool costs in a scene that needs more (a program
with a handle table binds 64 textures a set). The line logged every 3,000 recordings now ends with how many such pools
were made: none at the full size; at a sixteenth none in Hyrule Field, 3 on a heavy view and 1,691 in Kokiri Forest
over one short run each. That is what says how small is too small.

tests/recording_admission_test.cpp checks a kept extra pool is counted and one that could not be kept is not; the
fixtures that cut this code declare the counter (recording and sampler admission, draw stream visibility, FSR uniform
ownership). RX_VK_DESC_POOL_DIV is in the switch reference.

Assisted-by: Claude Fable 5.2
Co-Authored-By: Claude Fable 5.2 <[email protected]>
docs(tested): the descriptor pools made at the full size and at a sixteenth, on a Steam Deck OLED
Some checks failed
PR description / Description follows the template (pull_request_target) Successful in 3s
Details
Website / Website on Cloudflare (pull_request_target) Has been skipped
Details
CI / Conventional Commit title (pull_request) Has been cancelled
Details
CI / Python source checks (ubuntu-24.04, part 1/2) (pull_request) Has been cancelled
Details
CI / Python source checks (ubuntu-24.04, part 2/2) (pull_request) Has been cancelled
Details
CI / SPIR-V fixtures (global narrow load/store, direct surface atomics, F2I immediate) (pull_request) Has been cancelled
Details
CI / Workflow lint (actionlint) (pull_request) Has been cancelled
Details
Third-party parts / As their notes say (pull_request) Has been cancelled
Details
Third-party parts / The same as upstream (pull_request) Has been cancelled
Details
Website / Website on Cloudflare (pull_request) Has been cancelled
Details
4e2cd9f70e
 
One build with the count, three scenes, RX_VK_DESC_POOL_DIV unset then 16: none at the full size; at a sixteenth
3 on a heavy view, 1,691 in Kokiri Forest, none in Hyrule Field.

Assisted-by: Claude Fable 5.2
Co-Authored-By: Claude Fable 5.2 <[email protected]>
docs(tested): main against the descriptor pool count, and the count at a half, a quarter, an eighth, a sixteenth
Some checks are pending
CI / Conventional Commit title (pull_request) Blocked by required conditions
Details
CI / Python source checks (ubuntu-24.04, part 1/2) (pull_request) Blocked by required conditions
Details
CI / Python source checks (ubuntu-24.04, part 2/2) (pull_request) Blocked by required conditions
Details
CI / SPIR-V fixtures (global narrow load/store, direct surface atomics, F2I immediate) (pull_request) Blocked by required conditions
Details
CI / Workflow lint (actionlint) (pull_request) Blocked by required conditions
Details
Third-party parts / As their notes say (pull_request) Blocked by required conditions
Details
Third-party parts / The same as upstream (pull_request) Blocked by required conditions
Details
Website / Website on Cloudflare (pull_request) Blocked by required conditions
Details
PR description / Description follows the template (pull_request_target) Successful in 4s
Details
e0eb224413
 
A Steam Deck OLED, main 514591a3 against the count's commit on it: the same fps and work a frame. The pools
made when a recording's own ran out: none at the full size and at a half in three scenes; at a quarter 1 and 2
in Kokiri Forest; at an eighth 716 and 681 there; at a sixteenth 1,044.

Assisted-by: Claude Fable 5.2
Co-Authored-By: Claude Fable 5.2 <[email protected]>
p0lux commented 2026-11-14 12:40:49 +00:00
Author
Contributor

Measured on the Deck (head e0eb2244; description updated):

  • Main against the count (514591a3 and the commit on it, alternated, 3 runs each on the heavy view, 2 in Kokiri Forest): the same. Heavy view 23.99 against 24.05 fps, 62.68 against 62.56 M instructions a frame on the render thread. Kokiri Forest's own run-to-run spread is larger than the two renderers' difference there (the description says how much).
  • What the count says: no pool made on demand at the full size or at a half, in three scenes. At a quarter, 1 and 2 in Kokiri Forest. At an eighth, 716 and 681 there. At a sixteenth, 1,044, and 7 on the heavy view.
  • So a fixed smaller default is fragile: Kokiri Forest sits at the edge of a quarter. The follow-up I would propose is a small pool whose extra pools are kept from one recording to the next, not a fixed fraction (Reviewer notes).
  • Builds: Linux from this head, Windows cross-built from the branch, 0 failed. A second run file is in docs/tested/. The measured commit is on the fork as measured/desc-pool-count-d4b89309.
Measured on the Deck (head e0eb2244; description updated): - **Main against the count** (514591a3 and the commit on it, alternated, 3 runs each on the heavy view, 2 in Kokiri Forest): the same. Heavy view 23.99 against 24.05 fps, 62.68 against 62.56 M instructions a frame on the render thread. Kokiri Forest's own run-to-run spread is larger than the two renderers' difference there (the description says how much). - **What the count says:** no pool made on demand at the full size or at a half, in three scenes. At a quarter, 1 and 2 in Kokiri Forest. At an eighth, 716 and 681 there. At a sixteenth, 1,044, and 7 on the heavy view. - **So a fixed smaller default is fragile:** Kokiri Forest sits at the edge of a quarter. The follow-up I would propose is a small pool whose extra pools are kept from one recording to the next, not a fixed fraction (Reviewer notes). - Builds: Linux from this head, Windows cross-built from the branch, 0 failed. A second run file is in `docs/tested/`. The measured commit is on the fork as `measured/desc-pool-count-d4b89309`.
p0lux changed title from WIP: feat(log): the recording streams' line counts the descriptor pools made when a recording's own ran out to feat(log): the recording streams' line counts the descriptor pools made when a recording's own ran out 2026-11-14 12:41:42 +00:00
Some checks are pending
CI / Conventional Commit title (pull_request) Blocked by required conditions
Details
CI / Python source checks (ubuntu-24.04, part 1/2) (pull_request) Blocked by required conditions
Details
CI / Python source checks (ubuntu-24.04, part 2/2) (pull_request) Blocked by required conditions
Details
CI / SPIR-V fixtures (global narrow load/store, direct surface atomics, F2I immediate) (pull_request) Blocked by required conditions
Details
CI / Workflow lint (actionlint) (pull_request) Blocked by required conditions
Details
Third-party parts / As their notes say (pull_request) Blocked by required conditions
Details
Third-party parts / The same as upstream (pull_request) Blocked by required conditions
Details
Website / Website on Cloudflare (pull_request) Blocked by required conditions
Details
PR description / Description follows the template (pull_request_target) Successful in 4s
Details
This pull request doesn't have enough approvals yet. 0 of 1 approvals granted.
Some workflows are waiting to be reviewed.
This branch is out-of-date with the base branch
You are not authorized to merge this pull request.
View command line instructions

Checkout

From your project repository, check out a new branch and test the changes.
git fetch -u 'feat/desc-pool-count:p0lux-feat/desc-pool-count'
git switch 'p0lux-feat/desc-pool-count'
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels   
area/accessibility
Barriers for people with disabilities

  
area/audio
Sound and music

  
area/input
Controllers, keyboard, mouse

  
area/install
Installing, updating, building from your game

  
area/menu
In-game menu and settings

  
area/renderer
Vulkan renderer, shaders, effects

  
area/saves
Save files

  
area/upscaling
DLSS, FSR, frame generation

  
good first issue
A good start for a new contributor

  
gpu/amd
AMD GPUs

  
gpu/igpu
Integrated GPUs

  
gpu/intel
Intel GPUs

  
gpu/nvidia
NVIDIA GPUs

  
help wanted
Extra hands or knowledge wanted

  
kind
bug
 Something doesn't work as it should

  
kind
chore
 Build, CI, dependencies, tidying

  
kind
docs
 Documentation

  
kind
feature
 A new feature or an improvement

  
kind
performance
 Frame rate, frame time, loading, memory

  
kind
question
 A question rather than a change

  
needs measurements
Waiting for before/after measurements

  
platform/linux
Linux only

  
platform/steam-deck
Steam Deck

  
platform/windows
Windows only

  
preview
Maintainers: deploy a preview of this PR's website (read its changes first). Removed after the run.

  
priority
critical
 Crashes, data loss, or blocks most players

  
priority
high
 Important: next in line

  
priority
low
 Nice to have

  
status
blocked
 Waits on something else first

  
status
confirmed
 Reproduced or agreed on

  
status
duplicate
 Already reported or proposed

  
status
invalid
 Not a problem in this project

  
status
needs-info
 Waiting for more information from the reporter

  
status
wontfix
 Will not be worked on

  
testing wanted
Wanted: a test on other hardware (posts a test request in #test-requests)

No labels
area/accessibility
area/audio
area/input
area/install
area/menu
area/renderer
area/saves
area/upscaling
good first issue
gpu/amd
gpu/igpu
gpu/intel
gpu/nvidia
help wanted
kind
bug
kind
chore
kind
docs
kind
feature
kind
performance
kind
question
needs measurements
platform/linux
platform/steam-deck
platform/windows
preview
priority
critical
priority
high
priority
low
status
blocked
status
confirmed
status
duplicate
status
invalid
status
needs-info
status
wontfix
testing wanted
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
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!387
No description provided.