Use device-sized allocator capacity and release resize targets before replacement
The user verified that raising the renderer's fixed allocator cap from 4 to 8 GiB resolves the reported 4K/three-frame resize failure. Replace this temporary fixed cap with allocation capacity driven by device memory rather than a global fixed byte limit. The allocator already grows/reclaims blocks on demand; default effective global capacity now equals the sum of physical heaps, bounded by any explicit MaxReservedBytes policy. Existing per-heap size/allocation-count checks and bounded driver-pressure retries remain. This is demand-driven growth within physical capacity, not live VK_EXT_memory_budget sampling or a claim to prevent all driver OOM. Release obsolete GPU-idle extent-dependent resources before allocating their replacements, preserving descriptor/command-buffer lifetime and failure/shutdown safety. Reuse the allocator's existing on-demand block growth/reclamation and renderer construction scopes. Acceptance: allocations can grow beyond the old fixed cap on capable devices while respecting physical heap/count limits and explicit caller policy; resize does not overlap old/new extent-dependent image allocations; successful and failed recreation/shutdown remain safe with one and three slots; relevant unit and real Vulkan checks pass, with validation limitations explicit. Verified: removed renderer fixed cap and allocator default 1 GiB cap; effective capacity reported in summary. Resize now resets completed frame command buffers, releases old extent-dependent targets/descriptors/framebuffers/AO/AA/bloom before replacement allocation, retains the old swapchain only for Vulkan handoff, and stops accepting work after recreation failure. Target cleanup is idempotently guarded so failed replacement can shut down safely. Committed as 76d04faad on fix/client-resize-memory-capacity. Pull request #2954: https://git.project-rk.com/prk/engines/pulls/2954 (base develop). Validation: new allocator growth/reclamation regression failed before the change; all 72 allocator tests pass afterward. New actual RX9070 3840x2160 one/three-slot recreation/failure checks pass with AO enabled, SMAA and bloom. Controlled mutation moving target cleanup back after replacement reproduces peak growth: one slot 866,547,200 -> 1,582,099,456 bytes; three slots 2,381,537,792 -> 4,494,640,128 bytes. Restored fix passes repeated recreation with unchanged peaks 866,547,200 / 2,381,537,792 bytes. Injected missing resize shader fails replacement, rejects subsequent rendering and shuts down twice with no live allocator resources or Vulkan validation errors. Full graphics suite: 719 pass / 1 installed-water-data skip; full hardware Vulkan suite: 52 pass / 1 opt-in benchmark skip, including real changed-extent/UI resize cases. Client Debug build with warnings-as-errors passes with zero warnings/errors; diff check passes. Static feature review found no actionable findings. No Windows, production populated-scene, live memory-budget, full solution or Native AOT validation performed.
Checklist
2 of 2 complete- Implement device-driven on-demand allocator capacity while preserving explicit limits; verify allocation growth and reclamation behavior.
- Release obsolete resize resources before replacement and verify successful/failed resize plus shutdown without stale handles or overlapping target generations.
- Area
- Project Rubi-Ka
- Project
- engines
- Kind
- Bug
- Task ID
tsk_xuacmxkme3- Updated