WIP: perf(vk): below 60 fps the eviction's waits are seconds, not presents: the compaction's hold and the GPU-drawn textures' keep #875

Draft

HumanBean wants to merge 2 commits from HumanBean/Longshot:perf/evict-seconds-again into main

pull from: HumanBean/Longshot:perf/evict-seconds-again

merge into: MagicBeanDev:main

MagicBeanDev:main

Conversation 1 Commits 2 Files changed 8 +71 -7

HumanBean commented 2026-11-15 18:34:55 +00:00

Owner

• Copy link
• Copy Markdown

Re-opened from #771, which was merged while its review asked for a change and was reverted by #873. The two commits are Yeetbot90's from #771, unchanged, now on main after the revert, so this PR's diff is #771's change again (8 files, +71/-7). Still to do here: the fix from the review (each texture's age measured in seconds rather than through one rate averaged over ten seconds), #771 (comment).

Type: perf · Risk: low · Tested on: Windows 11, game-free checks (no game run) · Needs: Windows, a GPU under 60 fps with VRAM near its limit (an integrated GPU or a 4-8 GB card)

Why

When video memory runs short, the compaction lets go of textures nobody has drawn for ten seconds, and of more once they are thirty seconds old. Those times are written as ten and thirty seconds, but they are counted as 600 and 1800 frames, which is only right at 60 fps. Below 60 fps the wait gets longer: at 20 fps it is 30 s and 90 s, and at 3.5 fps (Unity's UHD Graphics laptop, an i3-1115G4) it is three and nine minutes. That laptop held 1,776 MB of textures against a budget of 1,299 MB, and the compaction freed 0 to 13 textures a pass. Textures the GPU drew have a wait of their own, a minute (3600 frames; 600 near the driver's limit), which nothing frees sooner: at 3.5 fps that is 17 minutes, and on that laptop 1,011 MB of the 1,776 MB were GPU-drawn, with 47 MB of all textures used in the last 8 frames. Players below 60 fps are the ones with the least VRAM to spare, the same players behind the worklist's top row (memory filling up over play, worst on 4-8 GB cards). See NotRexed/Hookshot#993.

What changed

The compaction's two waits and the GPU-drawn textures' keep now go by time, from the frame rate over the last ten seconds. At 60 fps or more nothing changes. The keep never goes under 120 frames, and the eviction's own one-second wait stays counted in frames, because the game samples some GPU-drawn textures every so many of its own frames (a terrain normal map every 40) and one let go between two samples comes back empty.

• memory: age_at_60 in gpu/vk/vram_compact.h (a texture's unused presents as at 60 fps; unchanged at 60 fps or more or with no rate known; under 2 fps counted as 2 fps, so a load's stall does not age every texture at once).
• memory: texture_frame in gpu/vk/vk_texture.cpp keeps a mark (time, present count) at each budget look (every 10 presents) and measures the presents a second over the last ten seconds; the hold's pass calls vram_compact::hold_target with age_at_60(frame_no - last, present_rate). The eviction's own wait stays in presents: RX_VK_EVICT_MIN_UNUSED (60).
• memory: at_rate in gpu/vk/keep_rendered.h (the keep as many presents as it is seconds at 60 fps, 120 at least), used where texture_frame takes keep_rendered::presents.
• tests: tests/test_keep_rendered.cpp and .py (at_rate at 60, 30, 3.5 and 0.5 fps and its floor; the call), tests/test_vram_compact.cpp (age_at_60 and hold_target with it, Unity's 3.5 fps), tests/test_vram_compact.py (the call, the rate, the switch, and the eviction's own wait still in presents).
• docs: docs/development.md (RX_VK_EVICT_BY_PRESENTS).

Measurements

Verdict: the game-free checks pass; nothing was measured in the game. This PC runs the game at well over 60 fps, where the change does nothing, and has no game data in this worktree. The in-game run is under Must be tested.

Hardware: Windows 11, llvm-mingw clang 20261104 (the nightly's toolchain), Python 3
Scene: none (the checks need no game). The 3.5 fps and the textures and budget come from Unity's nightly-132-5e072fc8 logs (UHD Graphics, i3-1115G4, 16 GB, 7.2 GB allowed)
Method: tests/test_vram_compact.py (compiles vram_compact.h and runs its rules, and reads texture_frame's source) against main's source and this PR's; tests/run_all.py on both, one after the other
How to reproduce: python -I -B tests/test_vram_compact.py; for main, copy this PR's tests/test_vram_compact.* into a worktree at aa95d35f and run it

	Before: main @ aa95d35f	After: this PR @ a8a41ddf
A texture unused 10 s at 3.5 fps (35 presents): the hold's line	not reached (35 of 600; reached after 171 s)	reached (age 600)
Unused 30 s at 3.5 fps (105 presents): the reserve's line	not reached (reached after 514 s)	reached (age 1800)
A GPU-drawn texture unused a minute at 3.5 fps (210 presents)	kept (3600 presents: 17 minutes)	may go (keep 210)
The same near the driver's limit, unused 10 s at 3.5 fps	kept (600 presents: 3 minutes)	kept to 120 presents (34 s), the floor
Any frame rate of 60 fps or more	600 and 1800 presents; keep 3600 or 600	the same
tests/test_vram_compact.py and tests/test_keep_rendered.py (this PR's versions)	both fail	both pass
tests/run_all.py	540 passed, 18 failed, 35 skipped	540 passed, 18 failed, 35 skipped: the same 18 (this worktree's setup: packaging, the builder's preflight, release; none reads the changed files)

main @ aa95d35f, with this PR's test_vram_compact:
vk_texture.cpp: texture_frame() no longer has: const uint64_t to = vram_compact::hold_target(vram_compact::age_at_60(frame_no - last, present_rate), need_unused,

main @ aa95d35f, with this PR's test_keep_rendered:
vk_texture.cpp no longer has: keep_rendered::at_rate(keep_rendered::presents(known, used, allowed, keep_over_only), present_rate)

this PR:
PASS: the compaction's rules
keep rendered: all checks passed

Unity's log (nightly-132, the last look before Hyrule Castle):
vk: VRAM: 6709 MB used of 7172 MB allowed (1121 MB of it free in the blocks); textures 1776 MB (budget 1299 MB), 1208 textures
vk: textures: decoded ASTC 0 MB, rendered 1011 MB (32 drawn in one frame, kept: 4634 KB), other 449 MB; used in the last 8 presents 47 MB
vk: 7 textures retired (1156 left, 1988 MB): budget 0, drawn over 0, dead targets 7
vi: 13439 frames presented (3.8 fps over the last 5.2 s, interval 1)

Flags and settings

One new switch, to go back to counting in presents for both.

Flag	What it is	Before this PR	After this PR	Effect	Helps / doesn't help / untested	Recommendation
RX_VK_EVICT_BY_PRESENTS=1	The compaction's waits and the GPU-drawn textures' keep counted in presents whatever the frame rate	(always so)	unset: waits in seconds	Below 60 fps unused textures go after 10 s and 30 s instead of 600 and 1800 presents, GPU-drawn ones after a minute (120 presents at least) instead of 3600	Helps: under 60 fps with VRAM over the compaction's lines. Doesn't: 60 fps or more (no change). Untested: in the game	Unset: only for A/B tests

Testing

Tested: On this PC (Windows 11), the game-free checks: tests/test_vram_compact.py and tests/test_keep_rendered.py fail on main's source and pass here; tests/test_texture_squeeze.py and tests/test_blocks_at_start.py pass; tests/run_all.py on main and on this PR (Measurements). The renderer (longshot_vk.dll) builds with llvm-mingw.

Not tested: The game, on any GPU. Not measured: how many more textures go, and come back as uploads, on a PC below 60 fps; whether ten seconds is still the right wait at 20-30 fps (it was measured at 60). Not built on Linux (the change is portable C++: std::chrono, std::deque).

Must be tested:

• Windows, an integrated GPU or a 4-8 GB card running under 30 fps (Unity's UHD Graphics laptop is one): play 10 minutes through Hyrule Field into Castle Town on main and on this PR, same settings, expecting the VRAM: lines' textures to come down to their budget on this PR (on main they stay over it), and no more than a few textures made a frame more (by hand: the vk: VRAM:, textures retired and a frame: lines in longshot_log.txt; test request T-JA2B, waiting for the testing wanted label)

Risks

What could break: Below 60 fps, with VRAM over the compaction's lines, textures unused for 10 or 30 seconds now go where they stayed for minutes; one seen again is uploaded again, a hitch on a slow PC. Textures the GPU drew now go after a minute below 60 fps too; the 120-present floor and the eviction's own 60 are what keep a periodically sampled one from coming back empty, and a game texture sampled less often than every 120 of its frames but drawn only once would not be covered (none is known). A frame rate measured too low (a load) could age textures faster: the age goes as at 2 fps at most.

Turning it off: RX_VK_EVICT_BY_PRESENTS=1, or revert the commits.

Compatibility: Nothing changes: no save, options, cache or interface change.

Issues

See NotRexed/Hookshot#993 (memory filling up over play, the worklist's top row)

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.
• Docs updated.

🤖 Generated with Claude Code

> **Re-opened from [#771](https://git.magicbean.dev/MagicBeanDev/Longshot/pulls/771)**, which was merged while its review asked for a change and was reverted by [#873](https://git.magicbean.dev/MagicBeanDev/Longshot/pulls/873). The two commits are Yeetbot90's from #771, unchanged, now on `main` after the revert, so this PR's diff is #771's change again (8 files, +71/-7). Still to do here: the fix from the review (each texture's age measured in seconds rather than through one rate averaged over ten seconds), https://git.magicbean.dev/MagicBeanDev/Longshot/pulls/771#issuecomment-26880. **Type:** perf · **Risk:** low · **Tested on:** Windows 11, game-free checks (no game run) · **Needs:** Windows, a GPU under 60 fps with VRAM near its limit (an integrated GPU or a 4-8 GB card) ## Why When video memory runs short, the compaction lets go of textures nobody has drawn for ten seconds, and of more once they are thirty seconds old. Those times are written as ten and thirty seconds, but they are counted as 600 and 1800 frames, which is only right at 60 fps. Below 60 fps the wait gets longer: at 20 fps it is 30 s and 90 s, and at 3.5 fps (Unity's UHD Graphics laptop, an i3-1115G4) it is three and nine minutes. That laptop held 1,776 MB of textures against a budget of 1,299 MB, and the compaction freed 0 to 13 textures a pass. Textures the GPU drew have a wait of their own, a minute (3600 frames; 600 near the driver's limit), which nothing frees sooner: at 3.5 fps that is 17 minutes, and on that laptop 1,011 MB of the 1,776 MB were GPU-drawn, with 47 MB of all textures used in the last 8 frames. Players below 60 fps are the ones with the least VRAM to spare, the same players behind the worklist's top row (memory filling up over play, worst on 4-8 GB cards). See [NotRexed/Hookshot#993](https://github.com/NotRexed/Hookshot/issues/993). ## What changed The compaction's two waits and the GPU-drawn textures' keep now go by time, from the frame rate over the last ten seconds. At 60 fps or more nothing changes. The keep never goes under 120 frames, and the eviction's own one-second wait stays counted in frames, because the game samples some GPU-drawn textures every so many of its own frames (a terrain normal map every 40) and one let go between two samples comes back empty. - memory: `age_at_60` in `gpu/vk/vram_compact.h` (a texture's unused presents as at 60 fps; unchanged at 60 fps or more or with no rate known; under 2 fps counted as 2 fps, so a load's stall does not age every texture at once). - memory: `texture_frame` in `gpu/vk/vk_texture.cpp` keeps a mark (time, present count) at each budget look (every 10 presents) and measures the presents a second over the last ten seconds; the hold's pass calls `vram_compact::hold_target` with `age_at_60(frame_no - last, present_rate)`. The eviction's own wait stays in presents: `RX_VK_EVICT_MIN_UNUSED` (60). - memory: `at_rate` in `gpu/vk/keep_rendered.h` (the keep as many presents as it is seconds at 60 fps, 120 at least), used where `texture_frame` takes `keep_rendered::presents`. - tests: `tests/test_keep_rendered.cpp` and `.py` (`at_rate` at 60, 30, 3.5 and 0.5 fps and its floor; the call), `tests/test_vram_compact.cpp` (`age_at_60` and `hold_target` with it, Unity's 3.5 fps), `tests/test_vram_compact.py` (the call, the rate, the switch, and the eviction's own wait still in presents). - docs: `docs/development.md` (`RX_VK_EVICT_BY_PRESENTS`). ## Measurements **Verdict:** the game-free checks pass; nothing was measured in the game. This PC runs the game at well over 60 fps, where the change does nothing, and has no game data in this worktree. The in-game run is under Must be tested. Hardware: Windows 11, llvm-mingw clang 20261104 (the nightly's toolchain), Python 3 Scene: none (the checks need no game). The 3.5 fps and the textures and budget come from Unity's `nightly-132-5e072fc8` logs (UHD Graphics, i3-1115G4, 16 GB, 7.2 GB allowed) Method: `tests/test_vram_compact.py` (compiles `vram_compact.h` and runs its rules, and reads `texture_frame`'s source) against main's source and this PR's; `tests/run_all.py` on both, one after the other How to reproduce: `python -I -B tests/test_vram_compact.py`; for main, copy this PR's `tests/test_vram_compact.*` into a worktree at aa95d35f and run it | | Before: main @ aa95d35f | After: this PR @ a8a41ddf | |---|---|---| | A texture unused 10 s at 3.5 fps (35 presents): the hold's line | not reached (35 of 600; reached after 171 s) | reached (age 600) | | Unused 30 s at 3.5 fps (105 presents): the reserve's line | not reached (reached after 514 s) | reached (age 1800) | | A GPU-drawn texture unused a minute at 3.5 fps (210 presents) | kept (3600 presents: 17 minutes) | may go (keep 210) | | The same near the driver's limit, unused 10 s at 3.5 fps | kept (600 presents: 3 minutes) | kept to 120 presents (34 s), the floor | | Any frame rate of 60 fps or more | 600 and 1800 presents; keep 3600 or 600 | the same | | `tests/test_vram_compact.py` and `tests/test_keep_rendered.py` (this PR's versions) | both fail | both pass | | `tests/run_all.py` | 540 passed, 18 failed, 35 skipped | 540 passed, 18 failed, 35 skipped: the same 18 (this worktree's setup: packaging, the builder's preflight, release; none reads the changed files) | ``` main @ aa95d35f, with this PR's test_vram_compact: vk_texture.cpp: texture_frame() no longer has: const uint64_t to = vram_compact::hold_target(vram_compact::age_at_60(frame_no - last, present_rate), need_unused, main @ aa95d35f, with this PR's test_keep_rendered: vk_texture.cpp no longer has: keep_rendered::at_rate(keep_rendered::presents(known, used, allowed, keep_over_only), present_rate) this PR: PASS: the compaction's rules keep rendered: all checks passed Unity's log (nightly-132, the last look before Hyrule Castle): vk: VRAM: 6709 MB used of 7172 MB allowed (1121 MB of it free in the blocks); textures 1776 MB (budget 1299 MB), 1208 textures vk: textures: decoded ASTC 0 MB, rendered 1011 MB (32 drawn in one frame, kept: 4634 KB), other 449 MB; used in the last 8 presents 47 MB vk: 7 textures retired (1156 left, 1988 MB): budget 0, drawn over 0, dead targets 7 vi: 13439 frames presented (3.8 fps over the last 5.2 s, interval 1) ``` ### Flags and settings One new switch, to go back to counting in presents for both. | Flag | What it is | Before this PR | After this PR | Effect | Helps / doesn't help / untested | Recommendation | |---|---|---|---|---|---|---| | `RX_VK_EVICT_BY_PRESENTS=1` | The compaction's waits and the GPU-drawn textures' keep counted in presents whatever the frame rate | (always so) | unset: waits in seconds | Below 60 fps unused textures go after 10 s and 30 s instead of 600 and 1800 presents, GPU-drawn ones after a minute (120 presents at least) instead of 3600 | Helps: under 60 fps with VRAM over the compaction's lines. Doesn't: 60 fps or more (no change). Untested: in the game | Unset: only for A/B tests | ## Testing **Tested:** On this PC (Windows 11), the game-free checks: `tests/test_vram_compact.py` and `tests/test_keep_rendered.py` fail on main's source and pass here; `tests/test_texture_squeeze.py` and `tests/test_blocks_at_start.py` pass; `tests/run_all.py` on main and on this PR (Measurements). The renderer (`longshot_vk.dll`) builds with llvm-mingw. **Not tested:** The game, on any GPU. Not measured: how many more textures go, and come back as uploads, on a PC below 60 fps; whether ten seconds is still the right wait at 20-30 fps (it was measured at 60). Not built on Linux (the change is portable C++: `std::chrono`, `std::deque`). **Must be tested:** - Windows, an integrated GPU or a 4-8 GB card running under 30 fps (Unity's UHD Graphics laptop is one): play 10 minutes through Hyrule Field into Castle Town on main and on this PR, same settings, expecting the `VRAM:` lines' textures to come down to their budget on this PR (on main they stay over it), and no more than a few `textures made` a frame more (by hand: the `vk: VRAM:`, `textures retired` and `a frame:` lines in `longshot_log.txt`; test request T-JA2B, waiting for the testing wanted label) ## Risks **What could break:** Below 60 fps, with VRAM over the compaction's lines, textures unused for 10 or 30 seconds now go where they stayed for minutes; one seen again is uploaded again, a hitch on a slow PC. Textures the GPU drew now go after a minute below 60 fps too; the 120-present floor and the eviction's own 60 are what keep a periodically sampled one from coming back empty, and a game texture sampled less often than every 120 of its frames but drawn only once would not be covered (none is known). A frame rate measured too low (a load) could age textures faster: the age goes as at 2 fps at most. **Turning it off:** `RX_VK_EVICT_BY_PRESENTS=1`, or revert the commits. **Compatibility:** Nothing changes: no save, options, cache or interface change. ## Issues See [NotRexed/Hookshot#993](https://github.com/NotRexed/Hookshot/issues/993) (memory filling up over play, the worklist's top row) ## 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. - [x] Docs updated. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

HumanBean added 3 commits 2026-11-15 18:34:55 +00:00

revert(vk): the eviction's waits in presents again at any frame rate, as before #771 ... d8c9a4aa28

This reverts commit fd770e7f5f (#771), merged with a request for changes standing:
its rate, averaged over the last ten seconds, reads far too low for ten seconds after any gap without presents (a
load's stall, a long hitch), so textures are aged several times too fast right after an area loads, even at 60 fps.
The change comes back in a new pull request with that fixed.

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

perf(vk): the compaction's hold and reserve wait ten and thirty seconds at any frame rate, not 600 and 1800 presents ... 90b40c755a

The hold lets go of live textures unused for 600 presents and the reserve for 1800: ten and thirty seconds at 60 fps, as
vram_compact.h says, but they were counted in presents. Below 60 fps they stretched: at 3.5 fps (Unity's UHD Graphics
laptop, i3-1115G4) three and nine minutes, and with 1,776 MB of textures held against a budget of 1,299 MB the hold
retired 0 to 13 textures a pass. A texture's age now goes to hold_target as at 60 fps (vram_compact::age_at_60), by the
presents a second over the last ten seconds, measured at each budget look. At 60 fps or more nothing changes.

The eviction's own wait (RX_VK_EVICT_MIN_UNUSED, 60) and the rendered textures' keep (keep_rendered.h) stay in presents
and still run first: the game samples some of those every so many of its frames, and a GPU-drawn one evicted between
two samples comes back empty. Under 2 fps (a load's stall) the age goes as at 2 fps. RX_VK_HOLD_BY_PRESENTS=1: as before.

Co-Authored-By: Cursor <[email protected]>

perf(vk): the GPU-drawn textures' keep is a minute at any frame rate, 120 presents at least ... fb37e32208

An unused texture the GPU drew is kept 3600 presents (a minute at 60 fps; 600 near the driver's limit) before the eviction
may let it go, and the compaction's hold cannot take it sooner. Below 60 fps that stretched like the hold's waits: 17 and
3 minutes at 3.5 fps. On Unity's UHD Graphics laptop 1,011 MB of the 1,776 MB of textures were GPU-drawn, 47 MB of all of
them used in the last 8 presents. keep_rendered::at_rate gives the keep as many presents as it is seconds at 60 fps, by
the presents a second the hold's waits use, and never fewer than 120: the game samples some GPU-drawn textures every so
many of its own frames (a terrain normal map every 40), and one let go between two samples comes back empty.

RX_VK_HOLD_BY_PRESENTS is RX_VK_EVICT_BY_PRESENTS now, for both.

Co-Authored-By: Cursor <[email protected]>

BeanIssues added the

kind

performance

area/renderer

labels 2026-11-15 18:34:57 +00:00

HumanBean referenced this pull request 2026-11-15 18:35:04 +00:00

perf(vk): below 60 fps the eviction's waits are seconds, not presents: the compaction's hold and the GPU-drawn textures' keep #771

HumanBean force-pushed perf/evict-seconds-again from fb37e32208 to b573d3c656 2026-11-15 18:48:03 +00:00 Compare

HumanBean force-pushed perf/evict-seconds-again from b573d3c656 to d51401bc37 2026-11-15 18:50:40 +00:00 Compare

HumanBean commented 2026-11-15 18:50:48 +00:00

Author

Owner

• Copy link
• Copy Markdown

Rebased onto main @ b9e95173 now that the revert (#873) has merged: the diff is #771's change again, 8 files, +71/-7, the same as #771's merge. No tests were run here. The review's fix comes next.

Rebased onto main @ b9e95173 now that the revert (#873) has merged: the diff is #771's change again, 8 files, +71/-7, the same as #771's merge. No tests were run here. The review's fix comes next.

Some checks are pending

Hide checks

PR description / Description follows the template (pull_request_target) Waiting to run

Details

CI / Conventional Commit title (pull_request) Waiting to run

Details

CI / Python source checks (ubuntu-24.04, part 1/2) (pull_request) Has been skipped

Details

CI / Python source checks (ubuntu-24.04, part 2/2) (pull_request) Has been skipped

Details

CI / SPIR-V fixtures (global narrow load/store, direct surface atomics, F2I immediate) (pull_request) Has been skipped

Details

CI / Workflow lint (actionlint) (pull_request) Waiting to run

Details

Guide screenshots / Guide images and local UI source review (pull_request) Waiting to run

Details

Third-party parts / As their notes say (pull_request) Waiting to run

Details

Third-party parts / The same as upstream (pull_request) Has been skipped

Details

Website / Website on Cloudflare (pull_request) Has been skipped

Details

This pull request is marked as a work in progress.

View command line instructions

Checkout

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

git fetch -u 'perf/evict-seconds-again:HumanBean-perf/evict-seconds-again'

git switch 'HumanBean-perf/evict-seconds-again'

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

  

beanstalk: approved @ 1697603

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

  

beanstalk: approved @ 2c5a62e

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

  

beanstalk: approved @ 4fd82b7

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

  

beanstalk: approved @ 64d6d09

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

  

beanstalk: approved @ 6f91fae

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

  

beanstalk: approved @ 70a78f9

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

  

beanstalk: approved @ 8d361dc

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

  

beanstalk: approved @ 9d8356e

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

  

beanstalk: approved @ abf2227

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

  

beanstalk: approved @ d82f202

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

  

beanstalk: approved @ e5f1e40

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

  

beanstalk: approved @ ee8ab5f

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

  

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

beanstalk: approved @ 1697603

beanstalk: approved @ 2c5a62e

beanstalk: approved @ 4fd82b7

beanstalk: approved @ 64d6d09

beanstalk: approved @ 6f91fae

beanstalk: approved @ 70a78f9

beanstalk: approved @ 8d361dc

beanstalk: approved @ 9d8356e

beanstalk: approved @ abf2227

beanstalk: approved @ d82f202

beanstalk: approved @ e5f1e40

beanstalk: approved @ ee8ab5f

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

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

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

No description provided.