WIP: fix(vk): cap the render-target image pool and count it in the texture budget #518

Draft

Amateurwizrd wants to merge 2 commits from Amateurwizrd/Longshot:fix/target-pool-cap into main

pull from: Amateurwizrd/Longshot:fix/target-pool-cap

merge into: MagicBeanDev:main

MagicBeanDev:main

Conversation 9 Commits 2 Files changed 6 +447 -36

Amateurwizrd commented 2026-11-14 17:36:44 +00:00

Contributor

• Copy link
• Copy Markdown

Type: fix · Risk: medium · Tested on: Windows 11, RTX 5070 Ti 16 GB (game-free checks; an earlier version in the game) · Needs: an 8 GB card (NVIDIA or AMD), Windows; Linux build

Why

The render targets' image pool took every evicted render target's image whatever its size and gave them back only 16 a
present, outside the texture budget: a sweep of several hundred targets could leave gigabytes of images in VRAM that the
budget never saw, and an 8 GB card pays for that with evicted textures and uploads.

How to reproduce

Seen on: by reading the code (found beside Hookshot-old's 7bba12ad); the new game-free check shows it on main
Settings and switches: defaults (RX_VK_TARGET_POOL_MB 256)
Steps: on an 8 GB card, play through an area load that sweeps many render targets (Hyrule Field, Castle Town), with the log's target pool line in view; or run python -I -B tests/test_target_pool_cap.py with this PR's test on main
Expected: the pool never holds more than 256 MB, and what it holds counts against the texture budget
Actual: on main the pool takes every gone target whatever its size and is trimmed only 16 images a present, outside the budget

What changed

The render targets' image pool now has a hard cap at the moment an image is offered, and what it holds comes off the texture budget, so pooled targets can no longer push live textures out unseen. Whether VRAM is short is worked out every present, before the pool takes anything.

• vk: pool_offer in gpu/vk/vk_texture.cpp refuses an image that would take the pool past its cap
  (RX_VK_TARGET_POOL_MB, 256 MB by default), and any image while VRAM is short; a refused image is destroyed with its
  views as before the pool. The pool's log line counts the images it refused.
• vk: the pool's bytes come off the texture budget, and texture_frame works out whether VRAM is short each present,
  before the dead list's offers to the pool and its trim, not every tenth present.
• vk: on the tenth present the budget's rules look at VRAM again after the dead images are freed and the pool trimmed,
  so what that freed is not taken for an excess and no live texture is evicted for it.
• tests: tests/test_target_pool_cap.py and .cpp (new) run pool_offer, pool_trim and the frame's slice from the
  first look to the budget's rules with a stand-in driver count; tests/test_target_image_pool.py's source checks
  follow the new order (offer first, then destroy) and still pin the per-present trim.
• docs: docs/development.md documents RX_VK_TARGET_POOL_MB.

Measurements

Verdict: the new check fails on main and passes here (2 interleaved runs each, measured again on main @ 13e8b6da); no in-game numbers yet: the case it fixes needs a card short of VRAM, which this PC is not.

Hardware: RTX 5070 Ti 16 GB, driver 621.01, Ryzen 7 7800X3D, 32 GB, Windows 11 Pro 26200
Scene: none (game-free check)
Method: the new test, run 2 times on each side, interleaved (main, this PR, main, this PR); main gets this PR's test files only
How to reproduce: python -I -B tests/run_all.py target_pool_cap on this branch, and on main with tests/test_target_pool_cap.py and .cpp copied in

	Before: main @ 13e8b6da	After: this PR @ f827ee53
tests/test_target_pool_cap.py (run 1 / run 2)	FAIL / FAIL	pass / pass

main @ 13e8b6da:
texture_frame: whether VRAM is short is no longer worked out each present, before the dead list's offers to the pool and the pool's trim
FAIL         0.1s  tests/test_target_pool_cap.py
this PR @ f827ee53:
pass         1.0s  tests/test_target_pool_cap.py
1 passed, 0 failed, 0 skipped

On main the check stops at the frame's order (VRAM pressure is looked at every tenth present, after the offers), before
it reaches the cap: main has no cap at the offer, so a pool past 256 MB is only trimmed later, 16 images a present.

Flags and settings

No new switch; RX_VK_TARGET_POOL_MB becomes a hard cap and is documented.

Flag	What it is	Before this PR	After this PR	Effect	Helps / doesn't help / untested	Recommendation
RX_VK_TARGET_POOL_MB=<MB>	the render-target pool's cap (0: no pool)	256, a trim target only	256, a hard cap, counted in the texture budget	the pool never exceeds the cap	helps: cards short of VRAM, scenes sweeping many targets; doesn't: a 16 GB card in the measured scenes; untested: 8 GB cards, AMD, Intel	keep 256

Testing

Tested: on Windows 11, RTX 5070 Ti 16 GB, driver 621.01.

• Rebased onto main 9e6f231d (now 17376190); the conflicts in gpu/vk/vk_texture.cpp were with main's new texture-budget rule (texture_rule::), kept as main has it, with this PR's second VRAM look and budget_less_pool on top. clangd reports no error in the merged file.
• python -I -B tests/test_target_pool_cap.py and tests/test_target_image_pool.py pass.
• python -I -B tests/run_all.py with the pinned llvm-mingw 20261104 (tools.lock): 541 passed, 18 failed, 35 skipped; main @ 9e6f231d on the same PC: 540 passed and the same 18 failing (environment checks: portable builder, game font, a few that need tools this PC lacks). None new. The renderer (longshot_vk.dll) builds with llvm-mingw at 17376190.
• Before the rebase (159def68): run_all with llvm-mingw, 532 passed and the 5 failing on main @ 13e8b6da; the renderer built. In the game, an earlier version of this change (built with other changes not in this PR) ran 3 rounds at Kokiri Forest and on a Hyrule Field walk with no device loss; that is not a measurement of this PR.

Not tested: a card short of VRAM, where the cap and the refusals matter; a Linux build.

Must be tested:

• Windows, an 8 GB NVIDIA or AMD card: Hyrule Field and Castle Town for a few minutes, expecting the log's target pool line under 256 MB and no more texture evictions than main (Test Farm: @Beanstalk windows 8gb, Hyrule Field and Castle Town, compare texture evictions and the target pool line with main)
• Linux (x86_64, gcc or clang): the renderer builds with this PR, expecting no error in gpu/vk/vk_texture.cpp (Test Farm: @Beanstalk linux, build only)

Risks

What could break: more render-target images are destroyed and made again instead of pooled when the pool is full or VRAM is short, which could add a little CPU time in a scene that sweeps many targets; the budget's rules now look at VRAM after the dead list is freed, so eviction decisions on the tenth present can differ from main.

Turning it off: RX_VK_TARGET_POOL_MB=0 turns the pool off; reverting the commit restores the old pool.

Compatibility: Nothing changes (no save, options, cache or ABI change).

Checklist

Everyone

• One topic.
• The title is a Conventional Commit (type(scope): description) of the status line's type.
• Why gives the reason plainly and links the issues that fit (the tracker searched).
• Measurements has a verdict, or one line saying why there is nothing to measure.
• Testing names what was tested, what wasn't, and what must still be tested, where and how.
• Rebased on current main.
• python -I -B tests/run_all.py passes (any failure that also fails on main is named).
• 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.

When it applies

• AI assistance recorded with Assisted-by: / Co-Authored-By: trailers.
• Switches documented (docs/development.md; the README for a menu row) and shipped at their recommended value.
• 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.
• Host code builds on both Windows (llvm-mingw) and Linux, with UTF-8 paths. (Windows llvm-mingw at 17376190: builds; Linux is under Must be tested)
• Docs updated.

**Type:** fix · **Risk:** medium · **Tested on:** Windows 11, RTX 5070 Ti 16 GB (game-free checks; an earlier version in the game) · **Needs:** an 8 GB card (NVIDIA or AMD), Windows; Linux build ## Why The render targets' image pool took every evicted render target's image whatever its size and gave them back only 16 a present, outside the texture budget: a sweep of several hundred targets could leave gigabytes of images in VRAM that the budget never saw, and an 8 GB card pays for that with evicted textures and uploads. ## How to reproduce **Seen on:** by reading the code (found beside Hookshot-old's 7bba12ad); the new game-free check shows it on main **Settings and switches:** defaults (`RX_VK_TARGET_POOL_MB` 256) **Steps:** on an 8 GB card, play through an area load that sweeps many render targets (Hyrule Field, Castle Town), with the log's target pool line in view; or run `python -I -B tests/test_target_pool_cap.py` with this PR's test on main **Expected:** the pool never holds more than 256 MB, and what it holds counts against the texture budget **Actual:** on main the pool takes every gone target whatever its size and is trimmed only 16 images a present, outside the budget ## What changed The render targets' image pool now has a hard cap at the moment an image is offered, and what it holds comes off the texture budget, so pooled targets can no longer push live textures out unseen. Whether VRAM is short is worked out every present, before the pool takes anything. - vk: `pool_offer` in `gpu/vk/vk_texture.cpp` refuses an image that would take the pool past its cap (`RX_VK_TARGET_POOL_MB`, 256 MB by default), and any image while VRAM is short; a refused image is destroyed with its views as before the pool. The pool's log line counts the images it refused. - vk: the pool's bytes come off the texture budget, and `texture_frame` works out whether VRAM is short each present, before the dead list's offers to the pool and its trim, not every tenth present. - vk: on the tenth present the budget's rules look at VRAM again after the dead images are freed and the pool trimmed, so what that freed is not taken for an excess and no live texture is evicted for it. - tests: `tests/test_target_pool_cap.py` and `.cpp` (new) run `pool_offer`, `pool_trim` and the frame's slice from the first look to the budget's rules with a stand-in driver count; `tests/test_target_image_pool.py`'s source checks follow the new order (offer first, then destroy) and still pin the per-present trim. - docs: `docs/development.md` documents `RX_VK_TARGET_POOL_MB`. ## Measurements **Verdict:** the new check fails on main and passes here (2 interleaved runs each, measured again on main @ 13e8b6da); no in-game numbers yet: the case it fixes needs a card short of VRAM, which this PC is not. Hardware: RTX 5070 Ti 16 GB, driver 621.01, Ryzen 7 7800X3D, 32 GB, Windows 11 Pro 26200 Scene: none (game-free check) Method: the new test, run 2 times on each side, interleaved (main, this PR, main, this PR); main gets this PR's test files only How to reproduce: `python -I -B tests/run_all.py target_pool_cap` on this branch, and on main with `tests/test_target_pool_cap.py` and `.cpp` copied in | | Before: main @ 13e8b6da | After: this PR @ f827ee53 | |---|---|---| | tests/test_target_pool_cap.py (run 1 / run 2) | FAIL / FAIL | pass / pass | ``` main @ 13e8b6da: texture_frame: whether VRAM is short is no longer worked out each present, before the dead list's offers to the pool and the pool's trim FAIL 0.1s tests/test_target_pool_cap.py this PR @ f827ee53: pass 1.0s tests/test_target_pool_cap.py 1 passed, 0 failed, 0 skipped ``` On main the check stops at the frame's order (VRAM pressure is looked at every tenth present, after the offers), before it reaches the cap: main has no cap at the offer, so a pool past 256 MB is only trimmed later, 16 images a present. ### Flags and settings No new switch; `RX_VK_TARGET_POOL_MB` becomes a hard cap and is documented. | Flag | What it is | Before this PR | After this PR | Effect | Helps / doesn't help / untested | Recommendation | |---|---|---|---|---|---|---| | `RX_VK_TARGET_POOL_MB=<MB>` | the render-target pool's cap (`0`: no pool) | 256, a trim target only | 256, a hard cap, counted in the texture budget | the pool never exceeds the cap | helps: cards short of VRAM, scenes sweeping many targets; doesn't: a 16 GB card in the measured scenes; untested: 8 GB cards, AMD, Intel | keep 256 | ## Testing **Tested:** on Windows 11, RTX 5070 Ti 16 GB, driver 621.01. - Rebased onto main 9e6f231d (now 17376190); the conflicts in `gpu/vk/vk_texture.cpp` were with main's new texture-budget rule (`texture_rule::`), kept as main has it, with this PR's second VRAM look and `budget_less_pool` on top. clangd reports no error in the merged file. - `python -I -B tests/test_target_pool_cap.py` and `tests/test_target_image_pool.py` pass. - `python -I -B tests/run_all.py` with the pinned llvm-mingw 20261104 (`tools.lock`): 541 passed, 18 failed, 35 skipped; main @ 9e6f231d on the same PC: 540 passed and the same 18 failing (environment checks: portable builder, game font, a few that need tools this PC lacks). None new. The renderer (`longshot_vk.dll`) builds with llvm-mingw at 17376190. - Before the rebase (159def68): `run_all` with llvm-mingw, 532 passed and the 5 failing on main @ 13e8b6da; the renderer built. In the game, an earlier version of this change (built with other changes not in this PR) ran 3 rounds at Kokiri Forest and on a Hyrule Field walk with no device loss; that is not a measurement of this PR. **Not tested:** a card short of VRAM, where the cap and the refusals matter; a Linux build. **Must be tested:** - Windows, an 8 GB NVIDIA or AMD card: Hyrule Field and Castle Town for a few minutes, expecting the log's target pool line under 256 MB and no more texture evictions than main (Test Farm: @Beanstalk windows 8gb, Hyrule Field and Castle Town, compare texture evictions and the target pool line with main) - Linux (x86_64, gcc or clang): the renderer builds with this PR, expecting no error in `gpu/vk/vk_texture.cpp` (Test Farm: @Beanstalk linux, build only) ## Risks **What could break:** more render-target images are destroyed and made again instead of pooled when the pool is full or VRAM is short, which could add a little CPU time in a scene that sweeps many targets; the budget's rules now look at VRAM after the dead list is freed, so eviction decisions on the tenth present can differ from main. **Turning it off:** `RX_VK_TARGET_POOL_MB=0` turns the pool off; reverting the commit restores the old pool. **Compatibility:** Nothing changes (no save, options, cache or ABI change). ## Checklist ### Everyone - [x] One topic. - [x] The title is a Conventional Commit (`type(scope): description`) of the status line's type. - [x] Why gives the reason plainly and links the issues that fit (the tracker searched). - [x] Measurements has a verdict, or one line saying why there is nothing to measure. - [x] Testing names what was tested, what wasn't, and what must still be tested, where and how. - [x] Rebased on current `main`. - [x] `python -I -B tests/run_all.py` passes (any failure that also fails on `main` is named). - [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. ### When it applies - [x] AI assistance recorded with `Assisted-by:` / `Co-Authored-By:` trailers. - [x] Switches documented (docs/development.md; the README for a menu row) and shipped at their recommended value. - [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. - [ ] Host code builds on both Windows (llvm-mingw) and Linux, with UTF-8 paths. (Windows llvm-mingw at 17376190: builds; Linux is under Must be tested) - [x] Docs updated.

Amateurwizrd added 1 commit 2026-11-14 17:36:45 +00:00

fix(vk): the render targets' image pool never holds more than its cap, and what it holds comes off the texture budget ... 159def68e2

The pool took every evicted render target's image whatever its size, and was
only drained 16 images a present (64 while VRAM was short, which was looked at
every tenth present). A sweep of several hundred targets left gigabytes of
images in VRAM that the texture budget did not count. Now an image that would
take the pool past its cap, or any image while VRAM is short, is not pooled and
is destroyed as before the pool; the pool's bytes come off the texture budget;
and VRAM pressure is looked at every present for the pool. The budget's rules,
every tenth present, look again after the dead images are freed and the pool
trimmed, so what that freed is not taken for excess. The pool's log line counts
the images it refused.

Found while reading Hookshot-old's 7bba12ad (PR 2766), which pooled evicted
targets at once with no cap and outside the budget; the cap and the accounting
are new here. Written anew for Longshot.

Tested: tests/test_target_pool_cap.py (new), tests/test_target_image_pool.py,
the renderer builds.

Assisted-by: Claude

mooki added the

area/renderer

kind

bug

priority

high

gpu/nvidia

platform/linux

platform/windows

labels 2026-11-14 18:15:15 +00:00

waryxxful referenced this pull request 2026-11-14 21:07:50 +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

Amateurwizrd force-pushed fix/target-pool-cap from 159def68e2 to 1737619000 2026-11-15 09:50:24 +00:00 Compare

Amateurwizrd commented 2026-11-15 09:50:51 +00:00

Author

Contributor

• Copy link
• Copy Markdown

Rebased onto main 9e6f231d (now 17376190). The vk_texture.cpp conflicts were main's new texture-budget rule (texture_rule::); kept main's rule, with this PR's second VRAM look and budget_less_pool on top. Description moved to the new template. Pool tests pass; run_all (g++) shows no failure main doesn't also have on this PC. Still WIP: needs a run on an 8 GB card and a Linux build.

Rebased onto main 9e6f231d (now 17376190). The vk_texture.cpp conflicts were main's new texture-budget rule (texture_rule::); kept main's rule, with this PR's second VRAM look and budget_less_pool on top. Description moved to the new template. Pool tests pass; run_all (g++) shows no failure main doesn't also have on this PC. Still WIP: needs a run on an 8 GB card and a Linux build.

Amateurwizrd commented 2026-11-15 14:26:35 +00:00

Author

Contributor

• Copy link
• Copy Markdown

Re-ran with the pinned llvm-mingw (the earlier run_all was g++): 541 passed, the same 18 failing as main 9e6f231d on this PC, none new; the renderer builds at 17376190.

Re-ran with the pinned llvm-mingw (the earlier run_all was g++): 541 passed, the same 18 failing as main 9e6f231d on this PC, none new; the renderer builds at 17376190.

HumanBean commented 2026-11-15 18:46:11 +00:00

Owner

• Copy link
• Copy Markdown

Hi, this conflicts with main again, in gpu/vk/vk_texture.cpp (texture_frame, where the pool's offer and the driver's count are read) and docs/development.md. Main's changes there are #771 and #223. The texture_frame hunk has both sides changing the same logic (the pressure test and the budget look), so I haven't guessed at it. Please rebase onto current main.

Hi, this conflicts with `main` again, in gpu/vk/vk_texture.cpp (`texture_frame`, where the pool's offer and the driver's count are read) and docs/development.md. Main's changes there are https://git.magicbean.dev/MagicBeanDev/Longshot/pulls/771 and https://git.magicbean.dev/MagicBeanDev/Longshot/pulls/223. The `texture_frame` hunk has both sides changing the same logic (the pressure test and the budget look), so I haven't guessed at it. Please rebase onto current `main`.

Amateurwizrd force-pushed fix/target-pool-cap from 1737619000 to 13f95b24b0 2026-11-15 19:53:20 +00:00 Compare

Amateurwizrd commented 2026-11-15 19:53:27 +00:00

Author

Contributor

• Copy link
• Copy Markdown

@HumanBean rebased by hand onto main @ b8d2b04e (head 13f95b24). On this main the texture_frame hunk merged on its own; checked it by reading: main's pressure block (by_blocks, the compaction's reclaim, kept_only) is the one this PR moves into look(), look() runs each present for the pool and again before the budget's rules every tenth, and budget_less_pool now comes after main's card-based budget (#735). One conflict in docs/development.md: main's new RX_VK_ASTC_CPU row and this PR's RX_VK_TARGET_POOL_MB row, both kept.

Checks that read this diff, one at a time with the pinned llvm-mingw: 37 run, 26 passed; the 11 that fail also fail on main b8d2b04e here. One more needed a change: test_readback_timeout_source (from #553) cuts texture_frame's dead list, which now calls pool_offer, so its stub moved from pool_put to pool_offer in 13f95b24; it passes with g++, and with llvm-mingw it fails the same way main does. test_target_pool_cap passes.

Still WIP: the measurements are from main 9c9d69ed and need a new run, plus the 8 GB card run and the Linux build (T-2KFX).

@HumanBean rebased by hand onto `main` @ b8d2b04e (head 13f95b24). On this main the `texture_frame` hunk merged on its own; checked it by reading: main's pressure block (`by_blocks`, the compaction's `reclaim`, `kept_only`) is the one this PR moves into `look()`, `look()` runs each present for the pool and again before the budget's rules every tenth, and `budget_less_pool` now comes after main's card-based budget (#735). One conflict in `docs/development.md`: main's new `RX_VK_ASTC_CPU` row and this PR's `RX_VK_TARGET_POOL_MB` row, both kept. Checks that read this diff, one at a time with the pinned llvm-mingw: 37 run, 26 passed; the 11 that fail also fail on main b8d2b04e here. One more needed a change: `test_readback_timeout_source` (from #553) cuts `texture_frame`'s dead list, which now calls `pool_offer`, so its stub moved from `pool_put` to `pool_offer` in 13f95b24; it passes with g++, and with llvm-mingw it fails the same way main does. `test_target_pool_cap` passes. Still WIP: the measurements are from main 9c9d69ed and need a new run, plus the 8 GB card run and the Linux build (T-2KFX).

BeanIssues added the

risk

medium

label 2026-11-15 20:28:25 +00:00

Amateurwizrd force-pushed fix/target-pool-cap from 13f95b24b0 to f827ee53af 2026-11-15 21:11:39 +00:00 Compare

Amateurwizrd commented 2026-11-15 21:43:56 +00:00

Author

Contributor

• Copy link
• Copy Markdown

Rebased onto main @ 13e8b6da (f827ee53), no conflicts, and measured again there: test_target_pool_cap fails on main twice and passes here twice; the 38 checks that read this diff all pass. The log excerpt in Measurements is from the earlier run on 9c9d69ed; the failing step on main is the same. Still WIP for the 8 GB run and the Linux build (T-2KFX). @HumanBean could you add the testing wanted label so T-2KFX can be claimed? It shows as waiting for a maintainer.

Rebased onto main @ 13e8b6da (f827ee53), no conflicts, and measured again there: `test_target_pool_cap` fails on main twice and passes here twice; the 38 checks that read this diff all pass. The log excerpt in Measurements is from the earlier run on 9c9d69ed; the failing step on main is the same. Still WIP for the 8 GB run and the Linux build (T-2KFX). @HumanBean could you add the `testing wanted` label so T-2KFX can be claimed? It shows as waiting for a maintainer.

Amateurwizrd commented 2026-11-15 21:44:10 +00:00

Author

Contributor

• Copy link
• Copy Markdown

@Beanstalk linux, build the renderer at this head: it should build with no error in the files this PR changes; no change in play expected from the build alone.

@Beanstalk linux, build the renderer at this head: it should build with no error in the files this PR changes; no change in play expected from the build alone.

Beanstalk commented 2026-11-15 21:44:11 +00:00

Member

• Copy link
• Copy Markdown

@Amateurwizrd only members of BigBeans can start the farm. One of them can approve this request by reacting 👍 to it.

@Amateurwizrd only members of `BigBeans` can start the farm. One of them can approve this request by reacting 👍 to it.

Beanstalk added the

beanstalk: needs approval

label 2026-11-15 21:44:11 +00:00

BeanIssues referenced this pull request 2026-11-15 22:12:34 +00:00

WIP: fix(vk): let render targets go as newer ones together cover them, and pool their images at once #943

Amateurwizrd referenced this pull request 2026-11-15 22:14:35 +00:00

Game: on a 6 GB card VRAM goes over the driver's allowance after a few area changes, Hyrule Field falls from 31 to 14 fps until a restart (GTX 1060, nightly-189) #939

Amateurwizrd commented 2026-11-15 22:46:44 +00:00

Author

Contributor

• Copy link
• Copy Markdown

@Beanstalk windows, an 8 GB NVIDIA or AMD card: Hyrule Field and Castle Town for a few minutes on main and on this PR, comparing the log's render target pool line (it should stay under 256 MB here) and the texture eviction count. (This replaces test request T-2KFX, now closed: test requests gave way to the Test Farm in #953, so the label I asked about is no longer needed.)

@Beanstalk windows, an 8 GB NVIDIA or AMD card: Hyrule Field and Castle Town for a few minutes on main and on this PR, comparing the log's render target pool line (it should stay under 256 MB here) and the texture eviction count. (This replaces test request T-2KFX, now closed: test requests gave way to the Test Farm in #953, so the label I asked about is no longer needed.)

Beanstalk commented 2026-11-15 22:46:46 +00:00

Member

• Copy link
• Copy Markdown

@Amateurwizrd only members of BigBeans can start the farm. One of them can approve this request by reacting 👍 to it.

@Amateurwizrd only members of `BigBeans` can start the farm. One of them can approve this request by reacting 👍 to it.

Some checks are pending

Hide checks

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

Guide screenshots / Guide images and local UI source review (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

Website / Website on Cloudflare (pull_request_target) Has been skipped

Details

beanstalk/approval waiting for a BigBean's 👍 on the request

Details

PR description / Description follows the template (pull_request_target) Successful in 4s

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 'fix/target-pool-cap:Amateurwizrd-fix/target-pool-cap'

git switch 'Amateurwizrd-fix/target-pool-cap'

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

Developer tools: scripts, CI, build and release tooling

  

area/upscaling

DLSS, FSR, frame generation

  

beanstalk: approved

Set by Beanstalk for show; the farm's database is what counts

  

beanstalk: needs approval

Set by Beanstalk for show; the farm's database is what counts

  

beanstalk: running

Set by Beanstalk for show; the farm's database is what counts

  

ci: approved

A maintainer approved CircleCI for this fork PR (sticky; removed after 14 quiet days)

  

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

Affects Linux (a change for every system carries both Windows and Linux)

  

platform/macos

macOS (Apple silicon or Intel Macs)

  

platform/steam-deck

Steam Deck

  

platform/windows

Affects Windows (a change for every system carries both Windows and Linux)

  

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

  

regression

Worked in an earlier build, broken in a newer one: highest priority, above other bugs

  

risk

high

Broad or core change: the renderer, defaults on many systems, saves, installs, security

  

risk

low

Small, contained change: little can break

  

risk

medium

Changes behaviour in one area, or a default on some systems

  

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)

  

ci: approved

No labels

area/accessibility

area/audio

area/input

area/install

area/menu

area/renderer

area/saves

area/tooling

area/upscaling

beanstalk: approved

beanstalk: needs approval

beanstalk: running

ci: approved

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

platform/steam-deck

platform/windows

preview

priority

critical

priority

high

priority

low

regression

risk

high

risk

low

risk

medium

status

blocked

status

confirmed

status

duplicate

status

invalid

status

needs-info

status

wontfix

testing wanted

ci: approved

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

3 participants

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

No description provided.