feat(menu): a VRAM budget row of its own (builds on #1358) #1859
No reviewers
Labels
No labels
accessibility
autorelease: pending
autorelease: tagged
bug
dependencies
documentation
duplicate
enhancement
github_actions
good first issue
help wanted
invalid
question
testing wanted
wontfix
No milestone
No assignees
1 participant
Due date
No due date set.
Dependencies
No dependencies set
Reference
MagicBeanDev/Hookshot!1859
Loading…
Reference in a new issue
No description provided.
Delete branch "feat/vram-budget-row"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Players can't choose a VRAM limit: the texture and mirror budgets come only from the Quality preset. On a 12 GB card, for example, "Custom" means the automatic 6 GB and "High (12GB)" means 7.5 GB, nothing in between and nothing lower (null and Gummi in #dev-work). This adds a VRAM budget row of its own.
Built on #1358, which is now merged (DarkzGG's work, squashed into main as
26b2f744). This branch is rebased onto main and carries only the row.The row (Graphics, next to Render resolution):
opts.budget = 0), so it applies on any card. A preset's own budget still applies only on the card size it is for (#1358'spreset_caps_memory).preset_exempt: changing it leaves the preset alone. It's saved asvram_budget=like any row. An options file from before the row takes its preset's (memory_budget's) budgets.memory_budgetis always saved, 0 included, so a budget chosen on the row with a preset on stays the player's after a restart.RX_VK_VRAM_MB/RX_VK_MIRROR_MB, the integrated-GPU cap and the 75%-of-allowed safety clamp all apply as before.Tests
tests/test_vram_budget_row.py. It builds the menu's functions andpreset_caps_memoryfrom the source and checks:preset_exempt, and the old-file fallback (source checks).It fails without the row and passes here.
test_framegen_preset.pyandtest_rumble_menu.pycompile the row-change handler, so their stubs gainvram_budget_sync.run_all.py: 278 passed. 2 fail on main too (test_present_ahead.py,test_present_semaphores.py: main's renderer doesn't link sincea259978, see #dev-work). For the same reason a standalone build of this branch stops at the link with those two symbols. The row itself compiles: I built it on a tree from beforea259978.quality_preset=4:budget 7299 MB(High's 7.5 GB under the 75% clamp, as before);quality_preset=0withvram_budget=3:budget 4800 MB, kept in the file.Not on screen beyond the new row. The High preset's 7.5 GB on 12 GB cards at DLAA is a separate question (null's numbers); this PR doesn't change it.
🤖 Generated with Claude Code
Read through the diff and the new test. It's a tidy change and the preset-to-row mapping checks out (each preset still gives its old budgets, 2.2 GB skipped by the row's steps). One real problem, below.
On the #1358 questions: this PR does carry #1358's two commits (8379f61a, d6cbbee2, same SHAs) plus three merges of main, so it works without #1358 landing first. If #1358 merges first, the shared hunks (
opts.budget,preset_caps_memory,memory_budget) are identical, so it should shrink cleanly. No collision I can find: the row is not given a numeric id, its ini key comes from the name (vram_budget), and nothing on main or in the open PRs I searched uses that key oropts.budget.Bug: a budget chosen on the row is forgotten after a restart when a preset is on. The row is
preset_exempt, so with High (12GB) on, choosing 4.8 GB setsopts.budget = 0and leavespreset = 4.save()only writesmemory_budgetwhenopts.budget > 0, so nothing marks the row as the player's. At the next startif (opts.preset > 0) opts.budget = opts.preset;puts it back to 4. On a card bigger than that preset's size (e.g. High or Low on a 16 GB card, Low on 12 GB),preset_caps_memory()is false again, so the savedvram_budget=3shows in the menu but the renderer uses the card's own budget. The in-game check in the description (quality_preset=0,vram_budget=3) doesn't reach this. Suggest writingmemory_budget=0explicitly and only derivingopts.budgetfrom the preset when the file has nomemory_budgetline (same flag pattern ashas_vram_budget), plus a case in the test.CI: the failures are test_bake_mimo / test_bake_skeleton (clang++ has no C++23 on the runner) on Linux and test_bake_ds (libzstd.so) / test_log_batch (a timing check) on Windows, none of them touched by this PR; test_vram_budget_row and the two stubbed tests pass. Builds and AppImage are green.
This is where the row's choice gets lost: with a preset on,
opts.budgetis always the preset's after a restart, even if the player set the row (budget 0, nothing saved to say so). Only take the preset's here when the file has nomemory_budgetline, and writememory_budget=0in save() when a preset is on and budget is 0.Heads-up: this conflicts with main now. Could you rebase onto main and resolve the conflicts? Thanks!
Fixed in
f1ffd279as suggested:save()always writesmemory_budget(0 included), and the preset only suppliesopts.budgetwhen the file has nomemory_budgetline (has_memory_budget, the same pattern ashas_vram_budget).Thanks, good catch. Fixed in
f1ffd279:save()always writesmemory_budget, 0 included, andmenu_inittakes the preset's budget only when the file has nomemory_budgetline.test_vram_budget_rowhas a restart case built fromvk_menu.cpp's own save and load lines:budget 0,vram_budget 3and 4800 MB after the restart, andpreset_caps_memory()holds.memory_budgetstill takes the preset's budget.It fails without the fix (on the first case) and passes with it.
Rebased onto current
main. #1358 was squashed into26b2f744, so I replayed only this PR's two commits on main and dropped #1358's original commits and the three merges. The conflicts were mechanical: main'ssnap_render/env_releaseblock next to this row's handler, main'senv_overridelines, and theenv_releasestubs in two tests.tests/run_all.pyon Linux: 393 passed, 0 failed.Confirmed in
f1ffd279:memory_budgetis written every time, and the preset only fills it in when the file has no such line. The restart case in the test covers it. Thanks!Re-checked at
f1ffd279after the rebase. The restart bug from my last review is fixed, exactly as suggested:save()always writesmemory_budget(0 included), andmenu_initonly falls back to the preset's budget when the file has nomemory_budgetline (has_memory_budget). The new restart case intest_vram_budget_row(High on a 16 GB card, 4.8 GB chosen on the row) usesvk_menu.cpp's own save, parse and fallback lines, so it follows the source and would catch a regression. The case for a file from beforememory_budgetstill gets the preset's budgets.The rest checks out:
26b2f744), and the branch now has only this PR's three commits on top of main. The row hunks are the same as the version I reviewed, apart from the fix.memory_budgetis in save()'sminelist, so writing it every time still leaves one line in the file, andtest_options_budget_oncepasses.memory_budgetline whenever a preset was on, sohas_memory_budgetcan't change what they load. The first-start preset andRX_VK_LOW_SPECboth go throughapply_preset/sync_preset_budgets, so the row follows them.vram_budget), and the PR touches onlyvk_menu.cpp/.hand tests.vk_texture.cpp/vk_vma.cppand only reads the budget this row sets. #2401 is closed.test_framegen_presetandtest_rumble_menu, which compileset_rowfromvk_menu.cpp, have their stubs updated and pass.CI: the only failure is
test_native_astc_texture_count.pyon Windows (scanfdeprecated under -Werror), and main fails it too at this branch's base (2ed98c46).test_vram_budget_rowpasses on both Linux and Windows, and the builds and the AppImage are green. The branch is mergeable.One small request: the new row is on screen, so per CONTRIBUTING a screenshot of the Graphics tab with it would be good to add to the description (for example with a preset on and the row showing "2.2 GB (4GB preset)", or a size chosen on the row). Not a blocker on the code side.
Windows follow-up after the merge:
tests/test_vram_budget_row.pyfails to compile on main3e95ca68with llvm-mingw Clang under its-Wall -Wextra -Werrorfixture flags:I saw the same failure in a full main-baseline suite and in the separate Builder-runtime candidate based on it. This is fixture compilation, not a measured VRAM-row runtime regression. Are you already covering the follow-up? I can validate the Windows fixture once adjusted.
github-sync referenced this pull request2026-11-12 06:22:54 +00:00