feat(menu): a Quality preset "Auto (this PC)" that picks settings from the hardware and tunes them in play #2850
Open
github-sync
wants to merge 17 commits from
github/pr/2850 into main
pull from: github/pr/2850
merge into: MagicBeanDev:main
MagicBeanDev:main
MagicBeanDev:github/pr/2893
MagicBeanDev:github/pr/2890
MagicBeanDev:github/pr/2887
MagicBeanDev:github/pr/2878
MagicBeanDev:github/pr/2875
MagicBeanDev:github/pr/2874
MagicBeanDev:github/pr/2873
MagicBeanDev:github/pr/2871
MagicBeanDev:github/pr/2756
MagicBeanDev:github/pr/2897
MagicBeanDev:github/pr/2896
MagicBeanDev:github/pr/2718
MagicBeanDev:github/pr/2842
MagicBeanDev:github/pr/2691
MagicBeanDev:github/pr/2895
MagicBeanDev:github/pr/2743
MagicBeanDev:github/pr/2765
MagicBeanDev:github/pr/2708
MagicBeanDev:github/pr/2732
MagicBeanDev:github/pr/2755
MagicBeanDev:github/pr/2817
MagicBeanDev:github/pr/2876
MagicBeanDev:release-please--branches--main
MagicBeanDev:release-please--branches--main--release-notes
MagicBeanDev:github/pr/2778
MagicBeanDev:github/pr/2888
MagicBeanDev:github/pr/2866
MagicBeanDev:github/pr/2877
MagicBeanDev:github/pr/2800
MagicBeanDev:github/pr/2829
MagicBeanDev:github/pr/2889
MagicBeanDev:github/pr/2882
MagicBeanDev:github/pr/2860
MagicBeanDev:github/pr/2849
MagicBeanDev:github/pr/2886
MagicBeanDev:github/pr/2794
MagicBeanDev:github/pr/2840
MagicBeanDev:github/pr/2830
MagicBeanDev:github/pr/2834
MagicBeanDev:github/pr/2719
MagicBeanDev:github/pr/2742
MagicBeanDev:github/pr/2741
MagicBeanDev:github/pr/2820
MagicBeanDev:github/pr/2771
MagicBeanDev:github/pr/2859
MagicBeanDev:github/pr/2858
MagicBeanDev:github/pr/2823
MagicBeanDev:github/pr/2757
MagicBeanDev:github/pr/2769
MagicBeanDev:github/pr/2844
MagicBeanDev:github/pr/2843
MagicBeanDev:github/pr/2673
MagicBeanDev:github/pr/2855
MagicBeanDev:github/pr/2739
MagicBeanDev:github/pr/2807
MagicBeanDev:github/pr/2851
MagicBeanDev:github/pr/2789
MagicBeanDev:github/pr/2814
MagicBeanDev:github/pr/2818
MagicBeanDev:github/pr/2774
MagicBeanDev:github/pr/2772
MagicBeanDev:github/pr/2750
MagicBeanDev:github/pr/2786
MagicBeanDev:github/pr/2785
MagicBeanDev:github/pr/2782
MagicBeanDev:github/pr/2779
MagicBeanDev:github/pr/2775
MagicBeanDev:github/pr/2706
MagicBeanDev:github/pr/2766
MagicBeanDev:github/pr/2747
MagicBeanDev:github/pr/2759
MagicBeanDev:github/pr/2745
MagicBeanDev:github/pr/2740
MagicBeanDev:github/pr/2733
MagicBeanDev:github/pr/2725
MagicBeanDev:github/pr/2727
MagicBeanDev:github/pr/2728
MagicBeanDev:github/pr/2729
MagicBeanDev:github/pr/2721
MagicBeanDev:github/pr/2722
MagicBeanDev:github/pr/2715
MagicBeanDev:github/pr/2714
MagicBeanDev:github/pr/2707
MagicBeanDev:github/pr/2703
MagicBeanDev:github/pr/2705
MagicBeanDev:github/pr/2697
MagicBeanDev:github/pr/2679
MagicBeanDev:github/pr/2676
MagicBeanDev:github/pr/2669
MagicBeanDev:docs/what-hookshot-connects-to
MagicBeanDev:fix/hdr-encode-test
MagicBeanDev:fix/main-tests
MagicBeanDev:fix/play-cache-files
MagicBeanDev:perf/game-barrier-order
MagicBeanDev:feat/heap-lazy
MagicBeanDev:feat/texture-detail
MagicBeanDev:perf/astc-opaque-bc1
MagicBeanDev:fix/fs-dir-lock
MagicBeanDev:fix/framegen-native-kept
MagicBeanDev:fix/update-no-downgrade
MagicBeanDev:port/k10-gcn-f16-mirrors
MagicBeanDev:fix/framegen-mult-cap
MagicBeanDev:chore/release-as-2.1.1
MagicBeanDev:perf/pcache-load-switch
MagicBeanDev:fix/prepare-progress-log
MagicBeanDev:fix/update-closes-stale-game
MagicBeanDev:fix/hdr-scaled-sampled
MagicBeanDev:perf/first-start-preset
MagicBeanDev:perf/zero-upload
MagicBeanDev:fix/vcore-escape-2s
MagicBeanDev:test/fake-gh-atomic
MagicBeanDev:perf/batch-idle-flush
MagicBeanDev:test/finish-stub-a
MagicBeanDev:chore/record-2.1.0
MagicBeanDev:fix/main-red-tests
MagicBeanDev:fix/test-display-startup-driver-cache
MagicBeanDev:feat/mesh-shader-mode
MagicBeanDev:fix/menu-probes-at-startup
MagicBeanDev:fix/fps-counter-classic
MagicBeanDev:fix/test-log-batch-flake
MagicBeanDev:fix/narrow-screen-hud
MagicBeanDev:ci/prereleases
MagicBeanDev:release/v2.0.15
MagicBeanDev:hotfix/v2.0.15
MagicBeanDev:fix/present-ahead-replay
MagicBeanDev:release/v2.0.13
MagicBeanDev:fix/bracket-paths-2013
MagicBeanDev:fix/hdr-overlays-2013
MagicBeanDev:fix/fps-counter-scale-2013
MagicBeanDev:fix/stick-seen-at-rest
MagicBeanDev:hotfix/menu-fits-screen
MagicBeanDev:fix/f1-always-opens-menu
MagicBeanDev:fix/ini-keep-lines
MagicBeanDev:claude/cranky-pike-7cf247
MagicBeanDev:perf/texture-answer-flat
MagicBeanDev:fix/stamp-test-modules
MagicBeanDev:fix/appimage-fonts
MagicBeanDev:fix/display-awake
MagicBeanDev:release/v2.0.12
MagicBeanDev:fix/discord-windows
MagicBeanDev:rc/v2.0.12-tests
MagicBeanDev:fix/dlss-keep-feature
MagicBeanDev:rc/v2.0.12
MagicBeanDev:button-icons
No reviewers
Labels
Clear labels
accessibility
Barrier affecting people with disabilities
autorelease: pending
autorelease: tagged
bug
Something isn't working
dependencies
Pull requests that update a dependency file
documentation
Improvements or additions to documentation
duplicate
This issue or pull request already exists
enhancement
New feature or request
github_actions
Pull requests that update GitHub Actions code
good first issue
Good for newcomers
help wanted
Extra attention is needed
invalid
This doesn't seem right
question
Further information is requested
testing wanted
wontfix
This will not be worked on
No labels
accessibility
autorelease: pending
autorelease: tagged
bug
dependencies
documentation
duplicate
enhancement
github_actions
good first issue
help wanted
invalid
question
testing wanted
wontfix
Milestone
Clear milestone
No items
No milestone
Assignees
Clear assignees
No assignees
1 participant
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/Hookshot!2850
Loading…
Reference in a new issue
No description provided.
Delete branch "github/pr/2850"
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?
A first start today only looks at video memory: a small card gets Minimum or Low, and every other PC starts on the same plain defaults whether it's a 3060 or a 5090. This adds a Quality preset, Auto (this PC), that new players start on and that picks settings for the PC it runs on, then checks them against how the GPU actually does in play.
Draft until it has been tried on AMD, Intel, a 6-8 GB card and a Steam Deck (test request to follow).
What it does
On launch (
gpu/vk/auto_settings.h, one rule table, no list of GPU models):One log line says what it chose and why, e.g.
vk: Auto (this PC): first start: 12282 MB of video memory: tier 4; NVIDIA RTX: DLSS Quality; output 2560x1440 (the screen's) (NVIDIA GeForce RTX 4070 Ti, ..., screen 2560x1440 at 60 Hz, 30987 MB of RAM, 16 threads).With another preset chosen it still logs what Auto would choose, for bug reports.
Each start it compares a fingerprint of the GPU, its memory, the screen and the build's upscalers with the one it chose for (
auto_for=inhookshot_options.ini) and chooses again when they differ: a new card or monitor gets new settings. Changing any row yourself turns the preset into Custom, as with the other presets, and from then on Auto touches nothing. The rows no preset sets (Output resolution, VRAM budget, Mesh shaders) leave it on Auto; when Auto chooses again for new hardware, the Output resolution and VRAM budget you set there stay yours (auto_output=records the Output Auto set). Mesh shaders Auto never sets, and the row is not in the fingerprint.In play (the first ~15-50 s of gameplay; menus and loading screens don't count), it measures over the replay's 120-frame windows and moves the Render resolution:
When DLSS or FSR 4 was chosen but the game's own upscaler runs (the build has it, this PC's driver or files don't), the Render resolution goes back to the tier's own once in play, and back to the choice if the chosen one runs again; a step the tuning made is left alone.
At most two changes, never up after a down, then done for that PC (
auto_tuned=). The steps so far are saved after each one (auto_steps=), so both rules hold across restarts. Not with frame generation on.Switches:
RX_VK_AUTO_PRESET=0(a first start keeps the defaults),RX_VK_AUTO_PRESET_VRAM_MB=<MB>(pretend the card has that much memory),RX_VK_AUTO_TUNE=0(no tuning in play). The Linux window bridge passes the desktop size (MKWVK_WINDOW_VERSION3,desktop_size);MKWVK_API_VERSIONis unchanged.Tested
RTX 4070 Ti 12 GB, driver 595.99.02, Ubuntu 26.04, a private KWin virtual output at 2560x1440 (headless runs, scripted input, the test save to Kokiri Forest and Hyrule Field). Game and renderer built from this branch.
RX_VK_AUTO_PRESET_VRAM_MB=6144No validation, device-lost or "not made" line in any of the runs.
tests/test_auto_settings.pycovers the rule table (RTX/RDNA 4/8 GB on 4K/6 GB/iGPU/Deck/no mesh shaders/low RAM, the fingerprint) and the tuning (gather, down only on missed frames, up only with the cap held, the CPU-bound case, the ceiling, two steps, no seesaw), and since the review: a card with mesh shaders run as compute against one without, the 10/11/12 GB steps, the upscaler snap-back, the steps restored after a restart.tests/test_low_vram_texture_mips.pyhas Auto at tier 1 and at a higher tier.python -I -B tests/run_all.pyon Linux: 428 passed;test_lift_cachefails here as on main (the system Python has no numpy).The in-game runs above were made before the review fixes (
c2c2b2b7); the 4070 Ti's and the faked 6 and 8 GB tiers are the same under the new steps. After them:python -I -B tests/run_all.pyon Linux: 464 passed;test_lift_cache(no numpy) andtest_updater_asset_digest(this PC's .NET has no packages to restore) fail here as on main.Three checks that cut functions out of
vk_menu.cppgot the new names in their stubs (test_framegen_preset,test_menu_keys,test_menu_env_overrides); none was loosened.Not tested: AMD, Intel, any Windows run (the screen size comes from
EnumDisplaySettingsWthere), a real 6-8 GB card, a Steam Deck, frame generation users (the tuning skips them). Known limit: it measures once, at the start of play, so a heavier area later (Hyrule Field, Castle Town) can still dip below the cap.Overlaps
Conflicts with this branch that they don't already have with main (
git merge-treeagainst each open PR): #2676 (preset VRAM budgets), #2465, #2371, #2274, #1872, #1590. #2557 (Texture detail Auto) touches the same idea from the texture side.Drafted by _trash.panda's agent; reviewed by _trash.panda.
🤖 Generated with Claude Code
This is this run's mode, not the card's capability. On Linux, Automatic picks Compute for every AMD card (
mesh_mode_used = 2above, #2245), so every RADV card lands here asmesh_native = falseand on Minimum. A player anywhere who sets Mesh shaders to Compute gets the same. I'd record whether the card has mesh shaders before the mode is applied and use that.With High starting above 9 GB, a 10 GB card (RTX 3080, RX 6700) gets the High (12GB) preset: 7.5 GB of textures plus 2 GB of mirrors, 9.5 GB of its 10 before render targets and DLSS. 12 GB cards report about 12,000-12,288 MB, so a step near 11.5 GB would put 10-11 GB cards on Balanced. It's worth checking again once #2676's budgets are in.
dlss_built()says the build has DLSS, not that it runs on this PC. With an old driver, or a Linux install without the NGX libraries (#1748),temporal_mode()falls back to the game's own upscaler. The player then gets DLSS's share (50-67%) drawn by the game's own upscaler, lower than the tier would set for it.dlss_why()is optimistic until NGX answers, so checking it here may not help. Another option: the tuning, or the probe's answer, could snap back to the tier's own Render resolution whenupscaler()isn't the upscaler Auto chose. The same applies to FSR 4.This runs before the step-down check and compares against the frame actually shown. At 40 fps under a 60 cap with the GPU at 17 ms, already over the 16.7 ms budget, it decides the CPU is the limit and finishes for good, because
menu_auto_tunesavesauto_tunedon CPU_BOUND. I'd only call it CPU-bound when the GPU is also under the budget (sayg < 0.9f * budget). The verdict is also taken in the first minute of play, while pipelines may still be compiling and textures streaming in, so maybe CPU_BOUND should end this run without writingauto_tuned.stepsandwent_downlive in this run's staticTuning, andauto_tunedis only written here, on KEEP or CPU_BOUND. If the game is closed after a step and before the next verdict, the next start measures again from the new resolution and can step back up. So the no-seesaw rule holds within a run but not across runs. Saving that state, or writingauto_tunedafter a step down, would fix it.The description says Auto touches nothing once you change a row, but changing a preset-exempt row doesn't make the preset Custom: Output resolution, the VRAM budget row, and Mesh shaders (which is in the fingerprint). A player who picks their own Output resolution stays on Auto. The next fingerprint change then applies the whole profile over their choice, and a different primary monitor, a laptop or Deck docked or undocked, or a build with or without DLSS all count. Two fixes: turn the preset to Custom when one of those rows changes under Auto, or keep the player's values for them here.
Nit:
apply_presetsnaps the tier's Render resolution to the currentupscaler()beforeopts.dlssis set below. When Auto chooses again and switches from DLSS to the game's own (say, a build without DLSS), Balanced's 100% is snapped to DLSS's 92% stop and stays there with the game's own upscaler. Settingopts.dlssbeforeapply_presetavoids that.This is why
tests/test_low_vram_texture_mips.pyfails in CI (no member named 'budget'in its fixture'sopts). Please addbudgetto the stub, plus cases for Auto at tier 1 and at a higher tier. Nit:kAutoPresetrather than a bare 6, if it can be shared throughvk_menu.h.Thanks for this. The rule table is easy to follow, the log line will help with bug reports, and the tuning has the right shape: medians over 8 play windows, at most two steps. I reviewed it from the code. A few things need settling before it comes out of draft; the first two matter most.
1. Linux AMD cards start on Minimum. On Linux, Mesh shaders on Automatic picks Compute for every AMD card (the RADV hang workaround in
vk_main.cpp, #2245). That leavesdev.mesh_shaderfalse, soauto_profilereportsmesh_native = false, and every RX 6000-9000 on RADV, which docs/workflow.md puts in Tier 1, starts on Minimum. That means a 50% Render resolution, the plain scale, the game's output, and no FSR 4 even on a 9070 XT. On main these cards start on the defaults. The same happens on any PC where the player sets Mesh shaders to Compute.mesh_nativeis also in the fingerprint, so changing that row makes Auto choose again. It should come from what the card supports (the feature query, before the mode is applied), not from the mode this run uses. EveryHardwarein the C++ test leavesmesh_nativeat its default of true, so a case for this would help.2. The presets' memory budgets (#2676). Auto moves every card over 6.5 GB off the renderer's Auto budget rule, which is what they get on main today, and onto a preset's budget: Balanced's 4.8 GB on 8 GB cards, High's 7.5 GB plus 2 GB of mirrors from 9 GB up, and Ultra's 11 GB on 16 GB. In #2676's table, Balanced's 4.8 GB paged an RTX 3060 Ti and an RTX 4050 (13-55 ms a frame), and Ultra's 11 GB is the fill-up from #105/#106. I'd land #2676 first and rebase this on it. The High step is a separate problem (inline): a 10 GB card gets the 12 GB preset.
3. Measurements (rule 3c). This changes the first start for every new player. The description needs before/after numbers on the same scene, main's first start against Auto, with fps and VRAM, on several tiers:
The 4070 Ti runs are a good start, and you already list the rest as untested. These are the runs that take it out of draft. Another option is to land the row first with the first start unchanged, and make Auto the default once the numbers are in.
4. CI.
tests/test_low_vram_texture_mips.pyfails on Linux part 1/2 and Windows part 2/2, and this PR is the cause: its fixture'soptshas nobudget(inline).The smaller points are inline:
apply_autoThe rest looks fine:
vk_api.honly bumpsMKWVK_WINDOW_VERSION, as therefresh_mhzaddition did.MkwVkHostandMkwVkRendererare unchanged, soMKWVK_API_VERSIONcan stay.display_sdl.cchange is the Linux side of the desktop size (Windows reads it from the window handle) and uses the existinghos_sdl_desktop_size.auto_forandauto_tunedare new ini keys only.tune(). It doesn't cover what feeds them (point 1) or the menu code around them (apply_auto, the step choice inmenu_auto_tune).menu_first_start_for_gpu, which this renames. #2557 also changeslow_vram_texture_mipsand its test, so whichever lands second updates the other's stub.Nit: in
vk_menu.h, themenu_auto_tunedeclaration carries the old trailing comment "(no options file: the preset for the card)", and thepresetcomment inOptionsstill lists 0-5.Fixed in
c2c2b2b7: create_device now reads the card's own task and mesh shader features (dev.mesh_capable) before the Mesh shaders mode is applied, and auto_profile uses that. A RADV card on Automatic, or any card with the row on Compute, gets its memory tier. The log line notes that this run uses compute, and the run's mode is not in the fingerprint. test_auto_settings.cpp has an RX 6800 run as compute (Ultra, and the same fingerprint as native) against an RX 5700 with the same memory and no mesh shaders (Minimum). The Python check makes sure mesh_capable is read before the mode turns mesh_shader off.Fixed in
c2c2b2b7: High now starts above 11,776 MB (11.5 GB), so 10 and 11 GB cards land on Balanced and 12 GB cards (12,000-12,288 MB) stay on High. The test has 9216, 10240, 11264 and 11776 MB on Balanced and 12000 on High. I'll check it again against #2676's budgets when this is rebased on it.Fixed in
c2c2b2b7with the cheap version of your second option. menu_auto_tune now checks in play, once the upscaler has run and NGX has answered, whether the engine running is the one Auto chose. If DLSS or FSR 4 was chosen and the game's own runs, the Render resolution goes back to the tier's own (Balanced's 100%, Low's 75%). If the chosen one runs again later (after a driver update, say), it goes back to the choice. This only happens while the resolution is still one of those two values, so a step the tuning made is left alone. The rule is auto_settings.h resolution_for and has C++ cases. kTierResolution is checked against apply_preset's cases.Fixed in
c2c2b2b7: CPU_BOUND now also needs the GPU under 0.9 of the cap's frame time, and the check comes after the step-down. Your 40 fps case with the GPU at 17 ms now steps down, and that's a test case. CPU_BOUND ends the tuning for this run only: menu_auto_tune writes no auto_tuned for it, so the next start measures again. The Python check holds that branch to it.Fixed in
c2c2b2b7: the tuning's state (steps, and whether one went down) is saved after every step as auto_steps=, and menu_init restores it. A restart after a step down can't step back up, and the two-step limit holds across runs. Choosing again for new hardware clears it. The C++ test restores a Tuning after a step down (no step up) and one at two steps (no third).Fixed in
c2c2b2b7: I kept the player's values rather than switching to Custom. The exempt rows exist so that a player can set them without leaving a preset, and someone who sets their own Output resolution on Auto still wants the rest chosen for their card. When Auto chooses again for new hardware (apply_auto(keep_own)), an Output resolution different from the one Auto set stays the player's. Auto records the one it set as auto_output=. A VRAM budget set on the row also stays, since that row already leaves budget at 0. Choosing Auto on the preset row still applies all of it, as any preset does. Auto never sets Mesh shaders, and with the fix above the row is no longer in the fingerprint, so changing it doesn't make Auto choose again.Fixed in
c2c2b2b7: apply_auto sets opts.dlss before apply_preset, so the tier's Render resolution is snapped to the upscaler Auto chooses. The Python check holds that order.Fixed in
c2c2b2b7: the fixture's opts now has budget, and the Python side passes it. There are four new cases: Auto at tier 1 (trimmed), Auto at tier 1 with a large budget (not trimmed), Auto at tier 3 (not trimmed) and Auto with the player's VRAM budget (budget 0, not trimmed). kAutoPreset is now in vk_menu.h, and both vk_menu.cpp and low_vram_texture_mips use it.Thanks for the review, hckrman101. I merged main in and fixed what can be fixed in code. Points 2 and 3 are still open.
Main merged (
38809f64). There were two conflicts, both rows added next to each other. Indocs/development.mdmain rewrote theRX_VK_VRAM_MBrow; I kept main's row and put this branch'sRX_VK_AUTO_PRESETandRX_VK_AUTO_TUNErows after it. Indocs/tested-configurations.mdboth sides added rows dated 2026-11-12; I kept all of them. #2834, #2557 and #2676 are all still open, so I made no changes for them.1. Linux AMD on Minimum: fixed in
c2c2b2b7.create_devicereads the card's task and mesh shader features before the Mesh shaders mode is applied (dev.mesh_capable), and Auto uses that. A RADV card on Automatic, or any card with the row on Compute, now gets its memory tier. The log line notes that this run uses compute, and the run's mode is no longer in the fingerprint. The C++ test compares a card with mesh shaders run as compute against one without.2. The presets' memory budgets (#2676): still open. I agree #2676 should land first, and I'll rebase this onto its budgets then; I didn't pull it in here. The High step (inline) is fixed separately: High now starts above 11.5 GB.
3. Measurements: still open. The before/after runs on an 8 GB NVIDIA card, a 10-12 GB card at 4K, an RX 6000/7000 on Windows and Linux, a Steam Deck and an iGPU need that hardware. That's what keeps this in draft. Landing the row with the first start unchanged is a good fallback if the numbers are slow to come.
4. CI: fixed in
c2c2b2b7. The fixture intest_low_vram_texture_mips.pyhasbudgetnow. The new cases are Auto at tier 1, at tier 1 with a large budget, at tier 3, and with the player's VRAM budget.kAutoPresetis now invk_menu.h.Inline points, all in
c2c2b2b7:auto_tuned.auto_steps=), so the no-seesaw rule and the two-step limit hold across restarts.opts.dlssis set beforeapply_preset.vk_menu.hcomment nits are fixed.Tested. I ran
test_auto_settings(new C++ cases and new source checks),test_low_vram_texture_mips, and the stub updates intest_menu_keys,test_menu_env_overridesandtest_framegen_preset. The fullpython -I -B tests/run_all.pyon Linux: 464 passed. Two tests fail on this PC the same way without this change:test_lift_cache(no numpy here) andtest_updater_asset_digest(.NET can't restore its packages here).vk_main.cpp,vk_menu.cppandvk_texture.cppcompile on Linux. I haven't run the game since these fixes; the in-game runs in the description were made before them.(_trash.panda's agent)
Merged main again (
327ac12e) and fixed one thing it broke: #2566 made the Output resolution's choices the screen's own resolutions, so Auto's old index into the fixed list (1 = 2560x1440) would have picked whatever sits at that position now.a1507649makes Auto choose a size (the screen's, where the tier carries its pixels: up to 2048x1152 any tier, up to 2560x1600 Balanced, up to 4K's pixels High, past that Ultra) and look it up among the menu's choices; a size the menu doesn't offer falls back to 2048x1152 and is logged, never taken as a custom size. Side effect: 1080p, 1920x1200 and the Deck's 1280x800 now get their own size at any tier. Tests updated; the full suite passes here apart from the two environment-only failures. (_trash.panda's agent)Thanks, Joey.
c2c2b2b7anda1507649answer the review, and I've merged current main in on top so this can land.On top of your head:
cbd02b9cmerges main (#2793 and #2710 since your merge, no conflicts).ba361a91: test_menu_keys' Auto stubs are[[maybe_unused]]. Newer clang fails the fixture on set-but-unused globals.4f4c33d5:auto_output=is saved as the size (auto_output=2560x1440), not the choice's number. Since #2566 the numbers follow the screen's modes, so after a monitor change (the moment Auto chooses again) the old number pointed at another size, and Auto took its own earlier output for the player's. test_auto_settings.py checks the wiring.Review points:
mesh_nativecomes fromdev.mesh_capable, which is read before the Mesh shaders mode is applied, and the C++ test covers RADV running mesh shaders as compute.test_low_vram_texture_mips): fixed. The stub hasbudget, and the test passes locally with the Vulkan headers.opts.dlssbeforeapply_preset, High from 11.5 GB, andkAutoPreset.Follow-ups, not blocking this:
resolution_fornow puts the tier's own Render resolution back in play. Choosing the game's own upscaler from the start when NGX won't run is still open.Tests: the Auto, menu, display-mode, output-resolution, VRAM-budget and stick tests pass, and so does the full suite apart from main's own failures (
test_readme_menu_rows's "Skip opening" row) and local tool gaps.hookshot_vk.sobuilds and its ABI check passes.Re-approving at the new head.
2387a36fmerges main again (#2709 and #2684 landed in the meantime). The only conflict was the tested-configurations table: both rows are kept. The Auto, menu and output tests pass again, and so does the vk build with its ABI check.Re-approving at
905c35e4, which merges main again (#2881, #2649, #2788 and others). #2881 took the Mesh shaders row out of the menu. The conflicts were its comment invk_main.cppand the save() key list invk_menu.cpp, and both sides are kept:mesh_capableis still read before the mode, and themesh_shadersline is still dropped. Auto's comments now nameRX_VK_MESH_SHADERSinstead of the row. The related tests and the vk build with its ABI check pass.