WIP: perf(vk): the images' pool in 32 MB blocks, not 128 (RX_VK_IMAGES_BLOCK_MB) #421

Draft

kingo wants to merge 5 commits from kingo/Longshot:perf/image-block-sizes into main

pull from: kingo/Longshot:perf/image-block-sizes

merge into: MagicBeanDev:main

MagicBeanDev:main

Conversation 4 Commits 5 Files changed 17 +155 -6

kingo commented 2026-11-14 12:56:33 +00:00

First-time contributor

• Copy link
• Copy Markdown

Why

On an 8 GB card about 900 MB of VRAM sits empty inside the renderer's memory blocks while the texture budget is cut below the textures loaded. One easy part of it: the images' pool keeps a whole 128 MB block for 11-17 MB of images. Giving it 32 MB blocks returns about 96 MB to the textures. fps: no difference these runs can separate from this PC's run-to-run noise (Measurements).

What changed

• vk: gpu/vk/vk_vma.cpp: the images' pool (DLSS's, the frame interpolation's and the scratch images, since the textures and the render targets have pools of their own) gets its own block size, kImagesBlock, 32 MB by default (RX_VK_IMAGES_BLOCK_MB). images_pool() keeps kImageBlock (128 MB) where the pool also holds the textures (RX_VK_COMPACT=0) or the render targets (RX_VK_TARGET_BLOCKS=0). The switch is read by block_mb(), the same parse as RX_VK_IMAGE_BLOCK_MB (16 MB floor). An image larger than a block is allocated outside the pool, as before.
• tests: tests/test_image_block_sizes.py (new) compiles block_mb() and runs it with the switch unset, set, below the floor, 0 and negative, and checks each pool's size and the two exceptions. tests/test_blocks_at_start.py's check of images_pool() follows the reworded line.
• docs: a row for RX_VK_IMAGES_BLOCK_MB in docs/development.md; kingo in docs/worklist.md's 5.6 row as the owner of this piece; one file per measured run in docs/tested/ (twelve).

Flags and settings

Flag	What it does	Default now	Recommendation	Helps on	Doesn't help on	Untested on
RX_VK_IMAGES_BLOCK_MB=<MB>	Block size of the images' pool, 16 and up; 128 is main's	32	On by default: 96 MB back on an 8 GB card, fps level	8 GB NVIDIA at 1080p (measured)	Cards with room to spare see no difference	DLSS and frame generation on (this build has no DLSS), 4K, AMD, Intel, Linux
RX_VK_TARGET_BLOCKS=0 (existing, unchanged)	Render targets in the images' pool, as before them; now also keeps that pool at RX_VK_IMAGE_BLOCK_MB's size	on (own pool)	Unchanged	-	-	-

Measurements

main: 5e072fc8 (2026-11-14)
this PR: perf/image-block-sizes @ 266e0946 (the head adds only the docs/tested/ files for these runs)
Hardware: RTX 5060 Ti 8 GB, driver 32.0.16.1088; Intel Core Ultra 7 265F; 64 GB; Windows 11 Home 26200
Scene: an adult save, copied fresh each run; 1920x1080; the game's own upscaler (no DLSS in this build), frame generation off, vsync off, 60 fps cap
Method: renderer-only builds (RX_VK_ONLY) swapped into one game folder. Through the control bridge: Kokiri Forest, then teleports to Hyrule Field, Market, Hyrule Field, Kakariko, Graveyard, Hyrule Field, Kokiri Forest, about a minute each, Link running small loops and turning the camera both ways (Hyrule Field: camera only, the teleport lands on Kokiri's exit). Eight runs interleaved main, PR, PR, main, PR, main, main, PR. Numbers from longshot_log.txt (vk: VRAM: and vk: image blocks lines every 600 presents, the first 3 skipped) and the frame-time file; per run, then the median of the runs. The first main run (361) is left out of the medians: the new build's first start (1200 shader programs translated) and a walk-out of Kokiri Forest; its pool read 112 MB empty like the others.
How to reproduce: any save; RX_VK_IMAGES_BLOCK_MB=128 gives main's pool; compare the vk: image blocks: line (the one without a pool name), blocks MB minus images MB.

	main @ 5e072fc8 (runs 364, 366, 367)	this PR @ 266e0946 (runs 362, 363, 365, 368)
images' pool: empty in its blocks	112 MB (112 / 112 / 112)	16 MB (16 / 16 / 16 / 16)
all pools: "free in the blocks"	963.5 MB	856 MB
texture budget	2340 MB	2520.5 MB
VRAM used	6286 MB	6189 MB
fps	57.1 (57.1 / 54.0 / 57.1)	55.2 (56.3 / 54.1 / 58.1 / 53.5)
1% low	15.4 (15.4 / 11.0 / 15.7)	13.05 (14.9 / 11.2 / 18.0 / 10.9)
frame time p99	37.5 ms (33.4 / 63.9 / 37.5)	48.65 ms (36.4 / 60.9 / 29.8 / 62.2)

Runs on this PC fall in two groups, about 57 fps and about 54 fps with a p99 near 62 ms, in both arms (main 366, PR 363 and 368), with the GPU in the same state in every run (median 2782 MHz, 45-46 W, 39-44% busy; peak 62-63 °C), and the slow runs took longer (509-517 s against 475-489 s): our reading is that they are CPU-side, not the change's, but that is an inference, not a measurement. 2 of the 4 PR runs are slow against 1 of 3 main runs, which moves the medians. Over every run of this work at 128 MB and at 32 MB (17 runs, two builds before and after a rebase that left vk_vma.cpp alone, and the in-build switch), the fps medians are 57.1 (9 runs) and 56.8 (8 runs). Found after the runs: the session recorder on this PC writes each session's summary with a local model on the CPU (30-60 s, about half the CPU) once the game closes; with 10 s between runs it overlapped the next run's title and load, and in some runs its first seconds of play (run 368: 14 s), in both arms alike. It does not touch the images' pool numbers; it adds to the fps noise. The runner now waits for it. Earlier, main @ 0caf0618 against this change @ 00c69897 (2 runs each; its renderer built from the working tree that was committed as 00c69897, only the message amended after): fps 56.9 / 57.0 against 57.3 / 57.3, 1% low 14.4 / 15.3 against 14.7 / 15.6; and one build with the switch (unset, 32, 32, unset): fps 56.2 / 57.7 against 56.1 / 57.7. The pool read 112-116 MB empty with 128 MB blocks and 16-20 MB with 32 MB (and 16 MB) ones in every report of every run (44-47 a run, title and loads included). "Free in all pools" moves 300 MB between runs of one build (the render targets' pool, below), so the pool's own line is the measure.

main @ 0caf0618 (run 354):     vk: images from a pool of 128 MB blocks (memory type 1), 0 made at the start
                               vk: image blocks: 1 blocks 128 MB, 6 images 16 MB; 3 free ranges, the largest 107 MB
this change @ 00c69897 (353):  vk: images from a pool of 32 MB blocks (memory type 1), 0 made at the start
                               vk: image blocks: 1 blocks 32 MB, 6 images 16 MB; 3 free ranges, the largest 11 MB

(the 21st image blocks report of each run)

Testing

Tested: the runs above, with a screenshot in every area of every run through the bridge's shot (main and PR at the same spots: nothing missing, garbled or flashing), and the logs scanned for device lost, VK_ERROR, "not made" and "image over budget" (none). python -I -B tests/run_all.py on Windows: 523 passed, 5 failed, the same 5 as main at 5e072fc8 (test_framegen_resources, test_module_ids, test_pad_layout, test_oot_state_tap, test_tested_configurations); test_image_block_sizes.py fails on main and passes here.

Not tested: DLSS and frame generation on (this build has no DLSS, so the pool held only scratch images): their images go in this pool, and one larger than 32 MB (4K) is now allocated outside it, as an image over 128 MB was before. Other GPUs and Linux.

Needs other testers:

• NVIDIA with DLSS and frame generation, 1440p or 4K: the vk: image blocks: line (no pool name) shows the pool's blocks and images; expecting fewer empty MB than with RX_VK_IMAGES_BLOCK_MB=128 and no new hitch when DLSS or frame generation is turned on or the resolution changes (T-5VX7)
• Linux, any GPU: the PR builds and the log says vk: images from a pool of 32 MB blocks, nothing drawn wrong (T-JBZR)

Screenshots

Nothing on screen.

Risk and rollback

An image over 32 MB (DLSS's or frame generation's at 1440p and up) no longer fits the pool and goes to VMA's default pool, which gives anything over half its 64 MB block dedicated memory (vk_mem_alloc.h, "Allocate dedicated memory if requested size if greater than half of preferred block size"): freed whole, so no block kept empty, but one vkAllocateMemory each when DLSS or frame generation makes its images (not per frame). Untested with DLSS here (T-5VX7). The pool itself makes up to 4 blocks where it made one only if it holds over 32 MB; here it held 11-17 MB in one. RX_VK_IMAGES_BLOCK_MB=128 is main's behaviour; reverting the commit is enough.

Reviewer notes

Where the rest of the ~900 MB is, from VMA's detailed statistics on this card (one run, the medians match the log's total to the MB): the default pools 259 MB (mostly the sparse mirrors' 64 KB pages, #250), the render targets' pool 234 MB, the textures' pool 174 MB, this pool 111 MB. Smaller render-target blocks were tried in the same A/B: 64 MB left as much empty as 128 (376 / 420 against 461 / 345 MB), 32 MB left ~140 MB less but with worse 1% lows (13.8 / 11.7 against 16.6 / 15.6 fps), so they are not in this PR.

Issues

See https://github.com/NotRexed/Hookshot/issues/993 (worklist 5.6, the 8 GB side)

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; not a menu row, so not 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 game-free test added for the fix, failing on main and passing here.
• A check under tests/ that reads changed source updated in this PR, not weakened.
• Docs updated.
• Host code builds on both Windows (llvm-mingw) and Linux, with UTF-8 paths. (Windows built and run here; Linux not built here: T-JBZR. The change uses only getenv, atoi and std::max, as the line it replaces, and no paths.)

🤖 Generated with Claude Code

## Why On an 8 GB card about 900 MB of VRAM sits empty inside the renderer's memory blocks while the texture budget is cut below the textures loaded. One easy part of it: the images' pool keeps a whole 128 MB block for 11-17 MB of images. Giving it 32 MB blocks returns about 96 MB to the textures. fps: no difference these runs can separate from this PC's run-to-run noise (Measurements). ## What changed - vk: `gpu/vk/vk_vma.cpp`: the images' pool (DLSS's, the frame interpolation's and the scratch images, since the textures and the render targets have pools of their own) gets its own block size, `kImagesBlock`, 32 MB by default (`RX_VK_IMAGES_BLOCK_MB`). `images_pool()` keeps `kImageBlock` (128 MB) where the pool also holds the textures (`RX_VK_COMPACT=0`) or the render targets (`RX_VK_TARGET_BLOCKS=0`). The switch is read by `block_mb()`, the same parse as `RX_VK_IMAGE_BLOCK_MB` (16 MB floor). An image larger than a block is allocated outside the pool, as before. - tests: `tests/test_image_block_sizes.py` (new) compiles `block_mb()` and runs it with the switch unset, set, below the floor, 0 and negative, and checks each pool's size and the two exceptions. `tests/test_blocks_at_start.py`'s check of `images_pool()` follows the reworded line. - docs: a row for `RX_VK_IMAGES_BLOCK_MB` in `docs/development.md`; kingo in `docs/worklist.md`'s 5.6 row as the owner of this piece; one file per measured run in `docs/tested/` (twelve). ## Flags and settings | Flag | What it does | Default now | Recommendation | Helps on | Doesn't help on | Untested on | |---|---|---|---|---|---|---| | `RX_VK_IMAGES_BLOCK_MB=<MB>` | Block size of the images' pool, 16 and up; `128` is main's | 32 | On by default: 96 MB back on an 8 GB card, fps level | 8 GB NVIDIA at 1080p (measured) | Cards with room to spare see no difference | DLSS and frame generation on (this build has no DLSS), 4K, AMD, Intel, Linux | | `RX_VK_TARGET_BLOCKS=0` (existing, unchanged) | Render targets in the images' pool, as before them; now also keeps that pool at `RX_VK_IMAGE_BLOCK_MB`'s size | on (own pool) | Unchanged | - | - | - | ## Measurements main: 5e072fc8 (2026-11-14) this PR: perf/image-block-sizes @ 266e0946 (the head adds only the `docs/tested/` files for these runs) Hardware: RTX 5060 Ti 8 GB, driver 32.0.16.1088; Intel Core Ultra 7 265F; 64 GB; Windows 11 Home 26200 Scene: an adult save, copied fresh each run; 1920x1080; the game's own upscaler (no DLSS in this build), frame generation off, vsync off, 60 fps cap Method: renderer-only builds (`RX_VK_ONLY`) swapped into one game folder. Through the control bridge: Kokiri Forest, then teleports to Hyrule Field, Market, Hyrule Field, Kakariko, Graveyard, Hyrule Field, Kokiri Forest, about a minute each, Link running small loops and turning the camera both ways (Hyrule Field: camera only, the teleport lands on Kokiri's exit). Eight runs interleaved main, PR, PR, main, PR, main, main, PR. Numbers from `longshot_log.txt` (`vk: VRAM:` and `vk: image blocks` lines every 600 presents, the first 3 skipped) and the frame-time file; per run, then the median of the runs. The first main run (361) is left out of the medians: the new build's first start (1200 shader programs translated) and a walk-out of Kokiri Forest; its pool read 112 MB empty like the others. How to reproduce: any save; `RX_VK_IMAGES_BLOCK_MB=128` gives main's pool; compare the `vk: image blocks:` line (the one without a pool name), blocks MB minus images MB. | | main @ 5e072fc8 (runs 364, 366, 367) | this PR @ 266e0946 (runs 362, 363, 365, 368) | |---|---|---| | images' pool: empty in its blocks | 112 MB (112 / 112 / 112) | 16 MB (16 / 16 / 16 / 16) | | all pools: "free in the blocks" | 963.5 MB | 856 MB | | texture budget | 2340 MB | 2520.5 MB | | VRAM used | 6286 MB | 6189 MB | | fps | 57.1 (57.1 / 54.0 / 57.1) | 55.2 (56.3 / 54.1 / 58.1 / 53.5) | | 1% low | 15.4 (15.4 / 11.0 / 15.7) | 13.05 (14.9 / 11.2 / 18.0 / 10.9) | | frame time p99 | 37.5 ms (33.4 / 63.9 / 37.5) | 48.65 ms (36.4 / 60.9 / 29.8 / 62.2) | Runs on this PC fall in two groups, about 57 fps and about 54 fps with a p99 near 62 ms, in both arms (main 366, PR 363 and 368), with the GPU in the same state in every run (median 2782 MHz, 45-46 W, 39-44% busy; peak 62-63 °C), and the slow runs took longer (509-517 s against 475-489 s): our reading is that they are CPU-side, not the change's, but that is an inference, not a measurement. 2 of the 4 PR runs are slow against 1 of 3 main runs, which moves the medians. Over every run of this work at 128 MB and at 32 MB (17 runs, two builds before and after a rebase that left `vk_vma.cpp` alone, and the in-build switch), the fps medians are 57.1 (9 runs) and 56.8 (8 runs). Found after the runs: the session recorder on this PC writes each session's summary with a local model on the CPU (30-60 s, about half the CPU) once the game closes; with 10 s between runs it overlapped the next run's title and load, and in some runs its first seconds of play (run 368: 14 s), in both arms alike. It does not touch the images' pool numbers; it adds to the fps noise. The runner now waits for it. Earlier, main @ 0caf0618 against this change @ 00c69897 (2 runs each; its renderer built from the working tree that was committed as 00c69897, only the message amended after): fps 56.9 / 57.0 against 57.3 / 57.3, 1% low 14.4 / 15.3 against 14.7 / 15.6; and one build with the switch (unset, 32, 32, unset): fps 56.2 / 57.7 against 56.1 / 57.7. The pool read 112-116 MB empty with 128 MB blocks and 16-20 MB with 32 MB (and 16 MB) ones in every report of every run (44-47 a run, title and loads included). "Free in all pools" moves 300 MB between runs of one build (the render targets' pool, below), so the pool's own line is the measure. ``` main @ 0caf0618 (run 354): vk: images from a pool of 128 MB blocks (memory type 1), 0 made at the start vk: image blocks: 1 blocks 128 MB, 6 images 16 MB; 3 free ranges, the largest 107 MB this change @ 00c69897 (353): vk: images from a pool of 32 MB blocks (memory type 1), 0 made at the start vk: image blocks: 1 blocks 32 MB, 6 images 16 MB; 3 free ranges, the largest 11 MB ``` (the 21st `image blocks` report of each run) ## Testing **Tested:** the runs above, with a screenshot in every area of every run through the bridge's `shot` (main and PR at the same spots: nothing missing, garbled or flashing), and the logs scanned for device lost, `VK_ERROR`, "not made" and "image over budget" (none). `python -I -B tests/run_all.py` on Windows: 523 passed, 5 failed, the same 5 as main at 5e072fc8 (`test_framegen_resources`, `test_module_ids`, `test_pad_layout`, `test_oot_state_tap`, `test_tested_configurations`); `test_image_block_sizes.py` fails on main and passes here. **Not tested:** DLSS and frame generation on (this build has no DLSS, so the pool held only scratch images): their images go in this pool, and one larger than 32 MB (4K) is now allocated outside it, as an image over 128 MB was before. Other GPUs and Linux. **Needs other testers:** - NVIDIA with DLSS and frame generation, 1440p or 4K: the `vk: image blocks:` line (no pool name) shows the pool's blocks and images; expecting fewer empty MB than with `RX_VK_IMAGES_BLOCK_MB=128` and no new hitch when DLSS or frame generation is turned on or the resolution changes (T-5VX7) - Linux, any GPU: the PR builds and the log says `vk: images from a pool of 32 MB blocks`, nothing drawn wrong (T-JBZR) ## Screenshots Nothing on screen. ## Risk and rollback An image over 32 MB (DLSS's or frame generation's at 1440p and up) no longer fits the pool and goes to VMA's default pool, which gives anything over half its 64 MB block dedicated memory (`vk_mem_alloc.h`, "Allocate dedicated memory if requested size if greater than half of preferred block size"): freed whole, so no block kept empty, but one vkAllocateMemory each when DLSS or frame generation makes its images (not per frame). Untested with DLSS here (T-5VX7). The pool itself makes up to 4 blocks where it made one only if it holds over 32 MB; here it held 11-17 MB in one. `RX_VK_IMAGES_BLOCK_MB=128` is main's behaviour; reverting the commit is enough. ## Reviewer notes Where the rest of the ~900 MB is, from VMA's detailed statistics on this card (one run, the medians match the log's total to the MB): the default pools 259 MB (mostly the sparse mirrors' 64 KB pages, #250), the render targets' pool 234 MB, the textures' pool 174 MB, this pool 111 MB. Smaller render-target blocks were tried in the same A/B: 64 MB left as much empty as 128 (376 / 420 against 461 / 345 MB), 32 MB left ~140 MB less but with worse 1% lows (13.8 / 11.7 against 16.6 / 15.6 fps), so they are not in this PR. ## Issues See https://github.com/NotRexed/Hookshot/issues/993 (worklist 5.6, the 8 GB side) ## 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; not a menu row, so not 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 game-free test added for the fix, failing on `main` and passing here. - [x] A check under `tests/` that reads changed source updated in this PR, not weakened. - [x] Docs updated. - [ ] Host code builds on both Windows (llvm-mingw) and Linux, with UTF-8 paths. (Windows built and run here; Linux not built here: T-JBZR. The change uses only `getenv`, `atoi` and `std::max`, as the line it replaces, and no paths.) 🤖 Generated with [Claude Code](https://claude.com/claude-code)

kingo added 2 commits 2026-11-14 12:56:33 +00:00

perf(vk): the images' pool in 32 MB blocks, not 128 (RX_VK_IMAGES_BLOCK_MB) ... 893eb9fb3b

Since the textures and the render targets have pools of their own, the
images' pool holds DLSS's, the frame interpolation's and the scratch
images: 11-17 MB in its one 128 MB block in every VRAM report of eight
9-minute routes on an RTX 5060 Ti 8 GB at 1080p. VMA keeps a pool's last
block, so the rest stayed empty, counted against the texture budget.

With 32 MB blocks it holds 16-20 MB empty instead of 112-116 (every
report of four routes each way, one build, RX_VK_IMAGES_BLOCK_MB=32
against unset); fps 56.1/57.7 against 56.2/57.7. An image larger than a
block is allocated outside the pool, as before. Where the pool also
holds the textures (RX_VK_COMPACT=0) or the render targets
(RX_VK_TARGET_BLOCKS=0) it keeps RX_VK_IMAGE_BLOCK_MB's size.
RX_VK_IMAGES_BLOCK_MB=128: as before.

tests/test_image_block_sizes.py fails on main and passes with this;
test_blocks_at_start.py's check follows the reworded line.

Assisted-by: Claude Opus 5.5
Co-Authored-By: Claude Opus 5.5 <[email protected]>

docs(tested): the images' pool in 32 MB blocks, main and PR interleaved ... 266e09468a

Four runs on an RTX 5060 Ti 8 GB, Windows 11: main, PR, PR, main, the
same route through the control bridge from the same save. One file per
run, in docs/tested/README.md's format.

Assisted-by: Claude Opus 5.5
Co-Authored-By: Claude Opus 5.5 <[email protected]>

mooki added the

kind

performance

priority

high

labels 2026-11-14 13:34:09 +00:00

kingo commented 2026-11-14 14:11:00 +00:00

Author

First-time contributor

• Copy link
• Copy Markdown

Measured again at the commits the description names (main @ 5e072fc8 against 266e0946, 8 runs interleaved; the first main run left out: shader translation on the new build's first start and a walk-out). The images' pool: 112 MB empty on main in every run, 16 MB with this. fps medians 57.1 (3 runs) against 55.2 (4): runs here fall in two groups (~57 and ~54 fps) in both arms with the GPU in the same state, so the slow runs are CPU-side; over all 17 runs of this work at 128 and 32 MB the medians are 57.1 and 56.8. Eight docs/tested/ files added. Test requests opened: T-5VX7 (DLSS and frame generation), T-JBZR (a Linux build); both need the testing wanted label to be claimable.

Measured again at the commits the description names (main @ 5e072fc8 against 266e0946, 8 runs interleaved; the first main run left out: shader translation on the new build's first start and a walk-out). The images' pool: 112 MB empty on main in every run, 16 MB with this. fps medians 57.1 (3 runs) against 55.2 (4): runs here fall in two groups (~57 and ~54 fps) in both arms with the GPU in the same state, so the slow runs are CPU-side; over all 17 runs of this work at 128 and 32 MB the medians are 57.1 and 56.8. Eight `docs/tested/` files added. Test requests opened: T-5VX7 (DLSS and frame generation), T-JBZR (a Linux build); both need the `testing wanted` label to be claimable.

kingo added 1 commit 2026-11-14 14:11:01 +00:00

docs(tested): the images' pool in 32 MB blocks, at 5e072fc8 and 266e0946 ... d6c3e2d2a9

Eight more runs on an RTX 5060 Ti 8 GB, Windows 11, at the commits the
pull request names: main 5e072fc8 against 266e0946, interleaved main,
PR, PR, main, PR, main, main, PR. One file per run.

Assisted-by: Claude Opus 5.5
Co-Authored-By: Claude Opus 5.5 <[email protected]>

kingo added 1 commit 2026-11-14 14:21:02 +00:00

docs(tested): runs 353 and 355 give their start times from the run log ... c340bc3548

353 started at 07:21:59 and 355 at 07:39:24 (block_ab.log); the files
said 07:22 and 07:45, the other files give the start's hour and minute.

Assisted-by: Claude Opus 5.5
Co-Authored-By: Claude Opus 5.5 <[email protected]>

kingo commented 2026-11-14 14:21:03 +00:00

Author

First-time contributor

• Copy link
• Copy Markdown

Checked by two independent passes: every run's numbers recomputed from the raw logs with separate scripts (all 16 runs and both medians match to 0.01), and the setup audited (each run's renderer hash and start-up block size, no switch carried between runs, no error lines, the diff, the docs files). What that changed here:

• The suite comparison now names main's run at 5e072fc8 (it was at 0caf0618): the same 5 failures.
• Wording: fps is "no difference these runs can separate from the noise", not "level"; the slow runs being CPU-side is marked as an inference, with what supports it; the GPU temperature is the peak.
• Risk: what happens to an image over 32 MB (VMA's default pool gives it dedicated memory, freed whole), still untested with DLSS (T-5VX7).
• docs/tested: runs 353 and 355 now give their logged start times.

Checked by two independent passes: every run's numbers recomputed from the raw logs with separate scripts (all 16 runs and both medians match to 0.01), and the setup audited (each run's renderer hash and start-up block size, no switch carried between runs, no error lines, the diff, the docs files). What that changed here: - The suite comparison now names main's run at 5e072fc8 (it was at 0caf0618): the same 5 failures. - Wording: fps is "no difference these runs can separate from the noise", not "level"; the slow runs being CPU-side is marked as an inference, with what supports it; the GPU temperature is the peak. - Risk: what happens to an image over 32 MB (VMA's default pool gives it dedicated memory, freed whole), still untested with DLSS (T-5VX7). - docs/tested: runs 353 and 355 now give their logged start times.

kingo added 1 commit 2026-11-14 14:22:50 +00:00

docs(worklist): kingo owns the VRAM held empty in the image blocks (5.6) ... cc544241f0

docs/worklist.md asks for the owner's name in the row in the same pull
request that starts the work. Row 5.6 is broad, so the cell names the
piece: the VRAM held empty in the image blocks, this pull request.

Assisted-by: Claude Opus 5.5
Co-Authored-By: Claude Opus 5.5 <[email protected]>

kingo commented 2026-11-14 14:22:50 +00:00

Author

First-time contributor

• Copy link
• Copy Markdown

Added kingo to docs/worklist.md row 5.6 as the owner of this piece (the VRAM held empty in the image blocks), as the worklist asks in the PR that starts the work.

Added kingo to docs/worklist.md row 5.6 as the owner of this piece (the VRAM held empty in the image blocks), as the worklist asks in the PR that starts the work.

kingo commented 2026-11-14 14:44:30 +00:00

Author

First-time contributor

• Copy link
• Copy Markdown

Added a note to Measurements: this PC's session recorder summarised each session with a local model on the CPU for 30-60 s after the game closed, overlapping the start of the next run in both arms (found afterwards with a new CPU log). It does not change the pool numbers; it adds to the fps noise. Later runs wait for it.

Added a note to Measurements: this PC's session recorder summarised each session with a local model on the CPU for 30-60 s after the game closed, overlapping the start of the next run in both arms (found afterwards with a new CPU log). It does not change the pool numbers; it adds to the fps noise. Later runs wait for it.

mooki added the

area/renderer

label 2026-11-14 16:27:53 +00:00

Some checks are pending

Hide checks

CI / SPIR-V fixtures (global narrow load/store, direct surface atomics, F2I immediate) (pull_request) Blocked by required conditions

Details

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 / 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

Website / Website on Cloudflare (pull_request_target) Has been skipped

Details

This pull request is marked as a work in progress.

Some workflows are waiting to be reviewed.

This branch is out-of-date with the base branch

View command line instructions

Checkout

From your project repository, check out a new branch and test the changes.

git fetch -u 'perf/image-block-sizes:kingo-perf/image-block-sizes'

git switch 'kingo-perf/image-block-sizes'

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

Subscribe

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!421

No description provided.