perf(vk): a 6 GB card mirrors a quarter of its VRAM, not an eighth or 512 MB #237
No reviewers
Labels
No labels
area/accessibility
area/audio
area/input
area/install
area/menu
area/renderer
area/saves
area/upscaling
good first issue
gpu/amd
gpu/igpu
gpu/intel
gpu/nvidia
help wanted
kind
bug
kind
chore
kind
docs
kind
feature
kind
performance
kind
question
needs measurements
platform/linux
platform/steam-deck
platform/windows
preview
priority
critical
priority
high
priority
low
status
blocked
status
confirmed
status
duplicate
status
invalid
status
needs-info
status
wontfix
testing wanted
No project
No assignees
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
MagicBeanDev/Longshot!237
Loading…
Reference in a new issue
No description provided.
Delete branch "i12bp8/Longshot:perf/low-vram-mirror-budget"
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?
Why
On 6 GB cards, Hyrule Field runs at about 18 fps on the Low (6GB) preset, which every 6 GB card with mesh shaders starts on. The game's largest memory pools don't fit in its 512 MB of VRAM mirrors (768 MB on Auto), so the GPU reads them over PCIe. Giving these cards a quarter of their VRAM, as larger cards get, more than doubles the frame rate. It costs VRAM headroom: on the card measured, the process then uses about 95% of what the driver allows, against 82% on main (below).
Ported from https://github.com/NotRexed/Hookshot/pull/2834 (Hookshot, before the move).
What changed
gpu/vk/mirror_budget.h(budget_byteswas namedpreset_bytesuntil091daa9):auto_bytes()is Auto's rule: a quarter of the card, at most 3 GB, and an eighth only on a small card, 4.5 GB or less (small_card()). It was an eighth on cards of 6.5 GB or less.budget_bytes()caps a budget's mirrors at Auto's. That applies to a budget set by a Quality preset on any card. It also applies to one chosen on the VRAM budget row itself on a small card, so a 4 GB card on the row's 3.6 GB step stays at 512 MB as before. Its 4.8 GB-and-up steps, past what such a card has, also keep 512 now (1024-3072 on main).mirror_budget()ingpu/vk/vk_memory.cppuses both, with the card's size fromdevice_vram_bytes().RX_VK_MIRROR_MBstill wins over both. The comment abovemirror_on()no longer names a 3072 MB default.kVramMirrorMbingpu/vk/vk_menu.cpp: the 3.6 GB VRAM budget step (the Low (6GB) preset's) asks for 1536 MB of mirrors, not 512. Throughbudget_bytes()a 6 GB card gets Auto's quarter (1498 MB on the card measured, which reports 5992 MB), and a 4 GB card gets 512.tests/test_mirror_budget.{py,cpp}compiles and checks both rules, including the small-card cap on the row, and checks thatmirror_budget()uses them.tests/test_vram_budget_row.pynow expects Low's 1536.RX_VK_MIRROR_MBindocs/development.mdsays what the default is.docs/tested-configurations.mdhas the three runs below.Out of scope, on purpose: the row's mirrors are now non-monotonic. The 3.6 GB step (Low) asks for 1536 MB, more than the 4.8 GB step's (Balanced) 1024. Hyrule Field mirrors 1.3-1.5 GB here, so 8 GB cards on Auto or Balanced (RTX 3070, 4060, RX 6600) may still leave a pool in system memory. That is a question for a follow-up with measurements on an 8 GB card.
Flags and settings
mirror_budget.hauto_bytes;RX_VK_MIRROR_MB=<MB>overrides it)preset_caps_memory()is false so Auto's rule applies (768 → 1536 MB): GTX 1060 6 GB (the README's minimum card) and RX 5600 XT (RDNA1, mirrors on). They run the compute fallback, with the least GPU headroom. Desktop 6 GB cards that drive monitors (RTX 2060, 1660 Super), whose allowance is smaller than this laptop'sTo go back to main's sizes for a run:
RX_VK_MIRROR_MB=512(Low's former) or768(Auto's former on 6 GB).Measurements
main:
fbd4202(2026-11-13)this PR: perf/low-vram-mirror-budget @
c17b339, on mainfbd4202(the code measured). Since rebased onto maind964886as38c1a48: the same diff, plus a comment and the tested-configurations row.Why the numbers still hold after the rebase: main's 9 commits since
fbd4202don't touch the mirrors, their budget or the VRAM budget row (mirror_budget(),kVramMirrorMb,preset_caps_memoryanddevice_vram_bytesare unchanged, as isMKWVK_API_VERSION21). They do touch occlusion queries and pipelines, which could move both sides' fps alike, not the gap between them.Hardware: NVIDIA GeForce RTX 3060 Laptop GPU 6 GB (Optimus: it drives no desktop; the driver reports 5992 MB and allows the process about 5.0 GB), driver 621.14, AMD Ryzen 7 6800HS, 16 GB RAM, Windows 11 Home (26200)
Scene: Hyrule Field, walking the same route, about 2 minutes a run; output 2048x1152; Quality preset Low (6GB), with its own settings: VRAM budget 3.6 GB, DLSS render size 1152x648 in every run (no Auto stepping); frame generation off, no cap
Method: the launcher's v3.0.0-rc.3 game (source cb01b5a3,
MKWVK_API_VERSION21 as main) with its renderer,longshot_vk.dll, built alone from each commit (RX_VK_ONLY=1 RX_RELEASE=1 python -I nx2/build.py --standalone, llvm-mingw, NVIDIA DLSS SDK) and swapped in before each run. 6 runs, alternated main, PR, PR at 1024 MB (RX_VK_MIRROR_MB=1024), twice. Frame rates come fromlongshot_log.txt's "N presents, X fps" lines (every 120 presents), counting only in-field lines (over 1000 draws a frame) and dropping the first one (loading). VRAM comes from the in-fieldvk: VRAM: ... used of ... allowedlines (every 600 frames). The median is taken per run and over both runs.How to reproduce: build the renderer alone as above from each commit, put it in a copy of a game folder's
bin/, choose Quality preset Low (6GB), and walk through Hyrule Field.fbd4202c17b339c17b339,RX_VK_MIRROR_MB=1024RX_VK_LOG_REMADE, was off)commit limit nearlines (system RAM: this PC has 16 GB), the least commit leftWhat it costs. The extra GB comes out of the headroom. On this card the process goes from 82% to 95% of the driver's allowance, at most 98%, and the render-target pool gives images back when VRAM runs short (5 times in two runs, never on main). The textures' budget reads 0 MB on both sides because of system RAM, not VRAM: every run, main and PR alike, hit the commit-limit path (
commit limit near) on this 16 GB PC, which sets the textures' budget down to 0. So "textures held" says little about the VRAM squeeze. What does: no texture was evicted and uploaded again in the PR's runs (20 or more in main's first run), as far as the always-on counter shows. The mirrors themselves are not squeezed when VRAM runs short, becauseRX_VK_MIRROR_TIGHTis opt-in. The texture cache takes the squeeze (Risk, below). No texture went missing and nothing failed here, but this laptop is close to a best case: its GPU drives no desktop. A desktop 6 GB card that drives monitors and shares VRAM with a browser has less allowance, and gets closer to the situation in #130 sooner (T-NWN5 asks for one).1024 MB as a middle. It keeps more headroom (89%) and still gains (30.7 fps median), but it is uneven: 22.4 in one run, 33.1 in the other. The pools are filled first come, first served, so which large pool is left out varies (152 MB in one run, 40 MB in the other). Auto's quarter is the size at which the scene's pools fit every time here. If reviewers prefer the headroom, 1024 on 6 GB cards is the alternative.
Earlier runs, kept in
docs/tested-configurations.md: the same card at a 33% render size (Auto's step-down) with main 0edc137's and this branch's renderers, 20.1 against 42.2 fps. Also rc.3's own renderer with onlyRX_VK_MIRROR_MBset, 18.8 against 38.6.Testing
Tested:
python -I -B tests/run_all.pyon Windows 11 with the launcher's llvm-mingw, at the branch's head091daa9(on maind964886): 451 passed, 10 failed, 73 skipped.tests/test_menu_i18n.pyfails on maind964886itself (a pt_BR string no longer invk_menu.cpp). The other 9 failed on mainfbd4202as well (447 passed there):test_release,test_check_third_party,test_lift_cache,test_spawn_emit,test_portable_builder_home,test_portable_builder_startup,test_fpx_sticky,test_bake_portabilityandnx2/test_nup_paths. None of them reads the files this PR changes.test_mirror_budgetandtest_vram_budget_rowpass.python -I scripts/check_third_party.py: 11 parts as their notes say.RX_VK_ONLY,RX_RELEASE, with NVIDIA DLSS), 0 failed, linked.longshot_vk.so, asscripts/linux/appimage.shbuilds it, with tools.lock's linux-x64 tools andRX_MARCH=x86-64-v3 RX_VK_ONLY=1 RX_RELEASE=1) inscripts/linux/Dockerfile's Ubuntu 22.04 image, ata5ee84d(this branch's head, with the small-card cap): 0 failed, linked.test_mirror_budgetpasses there with g++.Not tested:
Needs other testers:
VRAM:lines, the render-target pool lines andRX_VK_LOG_REMADE=1, expecting no device lost, no VRAM-full stutter and VRAM under the allowance (T-XFT3, replacing T-NWN5)Screenshots
Nothing on screen
Risk and rollback
mirrors_trimonly cuts away the parts of a mirror outside every game pool while VRAM is over 80%, and the 90% rule for mirrors exists only behindRX_VK_MIRROR_TIGHT, which is opt-in. What gives memory back is the texture cache (its 90% rule, and the compaction's hold at 85%) and the render-target pool. So the trade-off is "mirrors take the extra GB, and textures take the squeeze". The worst case is a desktop 6 GB card with a small allowance: textures re-uploaded more often or held at lower detail, or the driver over its limit as in #130.RX_VK_MIRROR_MB=768(Auto's former) or512(Low's former). Otherwise, reverting the commit is enough.Reviewer notes
Start with
gpu/vk/mirror_budget.h, where the rules and the reasons sit together. On cards of 8 GB or more nothing changes. On small cards (4.5 GB or less) Auto and the presets are unchanged, and the VRAM budget row is now capped at Auto's, which lowers its 4.8 GB-and-up steps there. Only the band between 4.5 and 6.5 GB moves from an eighth to a quarter.Issues
See https://github.com/NotRexed/Hookshot/pull/2834
See #130
Checklist
For everyone
type(scope): description).main.python -I -B tests/run_all.pyrun and passing (any failure that also fails onmainis named above).third_party/untouched (a new folder with aPROVENANCE.mdinstead).If applicable
Assisted-by:/Co-Authored-By:trailers.docs/tested-configurations.mdfor each measured run.tests/that reads changed source updated in this PR, not weakened.On a 6 GB card (RTX 3060 Laptop, RTX 2060) Auto gave the game's memory pools an eighth of the card (768 MB) and the Low (6GB) preset, every 6 GB card's from its first start, 512 MB. The game's largest pools then stayed in system memory and the GPU read them over PCIe. - gpu/vk/mirror_budget.h: Auto's rule (a quarter, at most 3 GB, an eighth only on cards of 4.5 GB or less) and a preset's cap (never more than Auto's). - gpu/vk/vk_memory.cpp: mirror_budget() uses them. - gpu/vk/vk_menu.cpp: the 3.6 GB VRAM budget step (Low) mirrors 1536 MB. - tests/test_mirror_budget.{py,cpp}: the rules and their use; the VRAM budget row check updated. Ported from https://github.com/NotRexed/Hookshot/pull/2834 Co-Authored-By: Claude Opus 5.5 <[email protected]>Measured with builds: main 0edc137's and this branch's
d27a462renderers built alone (llvm-mingw, DLSS) and swapped into rc.3's game, 4 alternated runs in Hyrule Field on an RTX 3060 Laptop 6 GB: 20.1 fps median on main against 42.2 here; the budget 1498 MB (a quarter of the card as the driver reports it). Rows added to docs/tested-configurations.md (2320b95).Test requests opened: T-NWN5 (6 GB AMD or Intel) and T-9799 (4 GB card: mirrors stay at 512 MB). They need the testing wanted label to be claimable.
Built on Linux: longshot_vk.so from
2320b95in scripts/linux/Dockerfile's Ubuntu 22.04 image with tools.lock's tools, 0 failed; the two touched checks pass there with g++. Host-builds box ticked.WIP: perf(vk): a 6 GB card mirrors a quarter of its VRAM, 1536 MB, not 512to perf(vk): a 6 GB card mirrors a quarter of its VRAM, 1536 MB, not 5122320b958e4b2a011cfa2I rebased this onto main @
fbd42024to clear the conflicts; it's pushed asb2a011cf. Your two commits are unchanged apart from the rebase. The code applied cleanly. Both conflicts were indocs/tested-configurations.md, where main had added a row at the same place as yours, and I kept every row. No tests were run here. Forgejo now shows it as mergeable.The change is clean. Auto's rule and the preset cap now live in
mirror_budget.h, where they are tested on their own, andmirror_budget()still readsRX_VK_MIRROR_MBfirst, so the override wins as before. The fps gain on the RTX 3060 Laptop is large and was measured A/B: 20.1 against 42.2 fps, main, PR, main, PR. I checked the other sizes against the code:preset_bytescan only lower a preset's value, never raise it. The Steam Deck and iGPUs, which have no mirrors (mirror_onis for discrete cards only), and GCN cards, which have them off. Low on a 4 GB card, capped back to 512. Low on an 8 GB PC with under 12 GB of RAM:preset_caps_memoryis false there, so it gets Auto's 2048 as before.MIRROR_REFUSEDis still set for a pool over 1 GB and for a failed allocation. A pool over the budget is stillMIRROR_NONEand tried again.mirrors_trimandmirrors_give_backcompare against the samemirror_budget(). The PR leaves all of these alone.test_vram_budget_rowis updated, not weakened, andtest_mirror_trim's cut text is unchanged. No API or shader changes.Must change
RX_VK_MIRROR_TIGHT, which is opt-in, so it is off by default (vk_memory.cppmirror_make). Mirror trim only cuts away the parts of a mirror that lie outside every game pool, while VRAM is over 80%. Live mirrors stay at their budget whatever the driver allows. What gives memory back is the texture cache: the 90% rule in the texture budget, and the compaction's hold at 85%. Please correct the description. The real trade-off is "mirrors take the extra GB, and textures take the squeeze".VRAM: X MB used of Y allowed ... textures ... (budget ...)status lines, and the texture eviction and re-upload counts, main against PR. Please also add one A/B pair at the tier's own render resolution. AGENTS.md asks a new default to say what it costs where it wasn't measured. Right now the description doesn't say what happens to textures and VRAM use.opts.budgetis 0.preset_bytes(…, false, …)then returns 1536 uncapped, andpreset_caps_memory()is true whenbudgetis 0. A 4 GB card on that step goes from 512 MB of mirrors to 1536, next to a 3600 MB texture budget that is clamped only to 75% of the allowance. That is past the card.tests/test_mirror_budget.cpp:26pins this behaviour. Please either cap the row's choice atauto_byteson cards of 4.5 GB or less, or keep the behaviour on purpose and say so in the description and the Flags table.Should change
preset_caps_memory()is false for a 6 GB card on Minimum, so these get Auto's rule, which goes from 768 to 1536 MB. Their texture budget is Auto's 45%. Please name them under "Helps on / Untested on". They run the compute fallback, so they have the least GPU headroom.testing wantedlabel. For a default that reaches every 6 GB card, a result from one 6 GB AMD card (or one desktop 6 GB card driving a monitor) should come in before merge.mirror_on()invk_memory.cppstill says "RX_VK_MIRROR_MB: their budget (default 3072)".Not checked: I ran nothing (no build, no tests, no game). Allowance figures are estimates from the code's rules, not from logs.
@ -0,0 +22,4 @@/// The mirrors when a Quality preset set the budgets (by_preset): never more than Auto gives the card, so a preset made for a/// larger card (Low's 1536 MB on a 4 GB one, preset_caps_memory lets Low's budgets through up to 6.75 GB) keeps a small card at/// Auto's. A budget chosen on the VRAM budget row itself is the player's on any card, as choseninline uint64_t preset_bytes(uint64_t asked, bool by_preset, uint64_t vram) {by_presetisopts.budget > 0, so a 3.6 GB step chosen on the VRAM budget row itself (budget 0) gets 1536 MB uncapped, on a 4 GB card too: it was 512 there. The description says cards of 4.5 GB or less get exactly what they got before. Either cap the row's choice atauto_bytes(vram)on cards of 4.5 GB or less, or keep this on purpose and say so in the description and the Flags table.@ -2486,3 +2483,1 @@// percent and the frame stuttering)if (vram && vram <= (6ull << 30) + (512ull << 20)) return vram / 8;return vram ? std::min<uint64_t>(vram / 4, 3072ull << 20) : (uint64_t)(3072ull << 20);return mirror_rule::auto_bytes(device_vram_bytes());This Auto path also reaches 6 GB cards without mesh shaders. They start on the Minimum tier, where
preset_caps_memory()is false: the GTX 1060 6 GB (the README's minimum card) and the RX 5600 XT. These go from 768 to 1536 MB, unmeasured. Please name them in the Flags table.@ -853,0 +854,4 @@// PCIe, 30-32 GB of bound ranges every 600 submits in Hyrule Field on an RTX 3060 Laptop (6 GB), the GPU's frame 27 ms. A preset's// mirrors are never more than Auto's on the card (mirror_budget.h preset_bytes): Low on a 4 GB card, which preset_caps_memory lets// through, keeps 512constexpr int kVramMirrorMb[kVramBudgets] = {0, 256, 1536, 1024, 1536, 2048, 2560, 3072};Low (1536) now mirrors more than Balanced (1024). Your logs show Hyrule Field mirroring 1.27 to 1.48 GB, so 8 GB cards on Auto/Balanced (tier 3) probably still leave a pool in system memory. Fine as a follow-up, but please say in the description that it is out of scope.
@ -0,0 +23,4 @@CHECK(preset_bytes(256 * MB, true, 4 * GB) == 256 * MB); // (Minimum: its own, smaller)CHECK(preset_bytes(1024 * MB, true, 8 * GB) == 1024 * MB); // (Balanced on an 8 GB card: its own)CHECK(preset_bytes(3072 * MB, true, 16 * GB) == 3072 * MB); // (Ultra on a 16 GB card)CHECK(preset_bytes(1536 * MB, false, 4 * GB) == 1536 * MB); // (3.6 GB chosen on the row on a 4 GB card: the player's)This pins 1536 MB of mirrors on a 4 GB card, next to a 3600 MB texture budget (clamped only to 75% of the allowance) when the row's 3.6 GB step is picked. If that behaviour changes (see the comment on
preset_bytes), update this check to match.perf(vk): a 6 GB card mirrors a quarter of its VRAM, 1536 MB, not 512to WIP: perf(vk): a 6 GB card mirrors a quarter of its VRAM, 1536 MB, not 512WIP: perf(vk): a 6 GB card mirrors a quarter of its VRAM, 1536 MB, not 512to WIP: perf(vk): a 6 GB card mirrors a quarter of its VRAM, not an eighth or 512 MBPushed
c17b339anda5ee84dafter HumanBean's review: the VRAM budget row is capped at Auto's mirrors on small cards; the Risk section is corrected; new runs on the Low preset's own settings (main, PR, 1024 MB, alternated) with VRAM use. Title no longer says 1536 MB (a 6 GB card gets a quarter as the driver reports it, 1498 MB here). Point-by-point reply follows.a5ee84d90e38c1a4898bRebased onto main
d964886(one conflict in docs/tested-configurations.md, all rows kept), pushed as38c1a48. run_all: 451 passed, 10 failed; test_menu_i18n is new and fails on maind964886itself. The description says why thefbd4202measurements still hold.Thanks for the careful review, and for the rebase. Point by point:
Must change
Risk section. You're right, and I've rewritten it. Nothing gives the mirrors' extra GB back when VRAM runs short:
mirrors_trimonly cuts the parts outside every game pool, and the 90% rule for mirrors is behind the opt-inRX_VK_MIRROR_TIGHT. It is the texture cache (its 90% rule and the compaction's hold at 85%) and the render-target pool that give way. The section now says "mirrors take the extra GB, and textures take the squeeze", names the worst case (a desktop 6 GB card with a small allowance, as in #130), and gives the switches to go back.Memory, and a run at the tier's own settings. I made new runs on the Low (6GB) preset with its own settings (DLSS render size 1152x648, fixed in every run, no Auto step-down), alternated main
fbd4202, this PRc17b339, and this PR atRX_VK_MIRROR_MB=1024, twice each. From the in-fieldVRAM:lines:So your estimate was right: the PR takes this card to the edge of its allowance, with about 4% less held in textures. Nothing failed here, but this laptop is a best case (Optimus, it drives no desktop), and the description now says so. 1024 MB is listed as the alternative if you prefer the headroom. It gains less, and unevenly, because the pools are filled first come, first served. I'd keep the quarter, but it's your call: tell me and I'll switch 6 GB cards to 1024.
4 GB cards and the VRAM budget row. That was a real bug, thanks.
c17b339caps a budget chosen on the row itself at Auto's mirrors on a small card (small_card(), 4.5 GB or less), as a preset's already was. So a 4 GB card on the row's 3.6 GB step stays at 512 MB.tests/test_mirror_budget.cppnow checks that (and a smaller choice, and 6 and 8 GB cards on the row) instead of pinning 1536. One side effect: the row's 4.8 GB-and-up steps on a 4 GB card now also keep 512 (1024-3072 on main). That is said in What changed and Reviewer notes.Should change
mirror_on()now points toauto_bytesinstead of saying "default 3072".Also rebased onto main
d964886and pushed as38c1a48. The title no longer says 1536 MB: a 6 GB card gets a quarter of what the driver reports, 1498 MB here.Builds and checks:
run_all: 451 passed, 10 failed. The failures are the same as on main, plustest_menu_i18n, which fails on maind964886itself.WIP: perf(vk): a 6 GB card mirrors a quarter of its VRAM, not an eighth or 512 MBto perf(vk): a 6 GB card mirrors a quarter of its VRAM, not an eighth or 512 MBRe-review at
38c1a48. Code only: I didn't build it, run the tests or run the game.Earlier points
mirror_budget.h.preset_bytesnow caps a row choice at Auto's on a card of 4.5 GB or less. I checked the menu: picking a step on the row setsopts.budget = 0, and a preset sets it to the preset. So 4 GB cards are back to 512 on the 3.6 GB step, and the cards of 8 GB or more still get what they chose on the row. The side effect on the row's 4.8 GB and higher steps on a 4 GB card is stated.test_mirror_budget.cppchecks it now instead of pinning 1536.mirror_on(): addressed.New since
b2a011cffbd4202don't touchmirror_budget(),preset_caps_memory(),device_vram_bytes()orkVramMirrorMb, so the reason given for keeping thefbd4202numbers holds. The Measurements section namesmain @andthis PR @hashes, and it says which hardware was measured and what the change costs elsewhere.test_menu_i18nfailure also happens on main.VRAM:lines show the textures' budget at 0 MB on both sides (textures 1706 MB (budget 0 MB)on main,1486 MB (budget 0 MB)on the PR). Is that the commit-limit path (commit limit nearlines) on this 16 GB PC? If so, system RAM sets the texture numbers at those moments, not VRAM, and "textures held" is a weak measure of the squeeze. The texture eviction and re-upload counts, main against PR, would settle it.vk: VRAM: ... used of ... allowedlines and the render-target pool line too, not only fps and the mirrors. Also accept a desktop NVIDIA 6 GB card that drives a monitor (RTX 2060, 1660 Super). The risk is about memory, so fps alone won't show it.1024 or a quarter
I'd keep the quarter. The 1024 runs gain less and unevenly (22.4 and 33.1), and the quarter's cost falls on the texture cache, which is built to give way. But 98% at peak on a laptop that drives no desktop is close. If a desktop 6 GB card's run shows device lost, heavy re-uploads or VRAM-full stutter, 6 GB cards should go to 1024.
Verdict
Comment, not approve yet. The code is right and every earlier point is addressed, except the one that needs hardware we don't have. I'll approve once T-NWN5 (or a desktop 6 GB run) comes back clean. If one has come back by then, please answer the question about the 0 MB budget too.
@ -0,0 +30,4 @@/// a small card at Auto's. Chosen on the VRAM budget row itself: the player's, except on a small card, where it is capped at Auto's/// too (the row's 3.6 GB step on a 4 GB card was 512 MB before Low's mirrors went to 1536; its steps of 4.8 GB and more, past/// what such a card has, now keep 512 as well)inline uint64_t preset_bytes(uint64_t asked, bool by_preset, uint64_t vram) {Nit: since
c17b339this also caps a budget chosen on the row (by_presetfalse, small card), sopreset_bytesno longer says what it does. Something likebudget_byteswould read better. Optional.Pushed
091daa9: preset_bytes renamed budget_bytes (HumanBean's nit). Description: the 0 MB texture budget is the commit-limit path on this 16 GB PC on both sides; eviction counts added. T-NWN5 replaced by T-XFT3, which asks for the VRAM and render-target pool lines and accepts desktop NVIDIA 6 GB cards.Thanks for the re-review.
The 0 MB texture budget: yes, it's the commit-limit path, on both sides. Every run, main and PR alike, logged
commit limit nearon this 16 GB PC (main 7 and 2 times, PR 3 and 4, 1024 MB 2 and 3). The least commit left was 495 MB on main and 575 MB on the PR, and that set the textures' budget to 0 MB at those moments. So, as you say, "textures held" doesn't measure the VRAM squeeze. The description now says that.Evictions: the per-texture log (
RX_VK_LOG_REMADE) was off in these runs, so I only have the always-on counter of evicted textures that were uploaded again from the game's memory:So nothing points to the PR thrashing textures on this card. This laptop is still the best case, though, so the desktop run decides.
T-NWN5: replaced by T-XFT3, with your suggestions. It accepts a desktop NVIDIA 6 GB card that drives a monitor (RTX 2060, 1660 Super/Ti) as well as AMD and Intel. It asks for every
VRAM: ... used of ... allowedline, the render-target pool lines, anycommit limit near, device lost or VK_ERROR, and a run withRX_VK_LOG_REMADE=1. Its pass criteria are no device lost, no VRAM-full stutter, and VRAM under the allowance.Nit: done in
091daa9.preset_bytesis nowbudget_bytes.run_allis unchanged: 451 passed, and the same 10 fail as on main.Agreed on the fallback: if the desktop 6 GB run shows device lost, heavy re-uploads or VRAM-full stutter, I'll move 6 GB cards to 1024.
View command line instructions
Checkout
From your project repository, check out a new branch and test the changes.