Investigate 4K three-frame resize allocator exhaustion
Investigate the reported Allocator capacity exhausted failure during PRK.Client window resize at 4K with three frames in flight despite approximately 3 GB reported VRAM usage. Trace allocator refusal conditions, renderer allocation policy, render-target footprint and resize ownership ordering. Distinguish source-proven causes from unmeasured runtime details; recommend a root-cause fix without silently changing resource lifetime guarantees. Acceptance: identify the internal versus driver failure path, explain the resize memory peak with reproducible calculations or runtime evidence, and report limitations and recommended next steps. Verified findings: BufferAllocator.cs:30 sets a renderer-wide 4 GiB MaxReservedBytes. DeviceMemoryAllocator.cs:262 emits the reported text only when no backend allocation failure was captured; CanAllocate checks global reserved bytes, per-heap reserved bytes and allocation count. RecreateSwapChainResources waits for device idle but builds replacement main/reflection/bloom/AO/AA resources before CleanupSwapChain frees the old generation. At 3840x2160 and three slots, source-derived unpadded main plus reflection image payload is 1.159 GiB without sky-behind or 1.344 GiB with it; two generations are 2.317/2.688 GiB before other resources. This makes the fixed cap the leading explanation given reported approximately 3 GB usage, not proof of which internal predicate failed. No live reproduction or failure-time allocator snapshot was obtained. All 71 allocator tests passed after restoring dependencies. No source changes made. Recommended follow-up: replace the arbitrary renderer-wide cap with an explicit hardware-aware/per-heap memory policy; review resize overlap and rollback ownership before changing cleanup order; make capacity diagnostics identify resource label, requested size, reserved bytes, configured cap, heap capacity and allocation count. Validate any fix with actual repeated 4K three-slot resize, rollback/failure lifetime checks and Vulkan validation.
Checklist
1 of 1 complete- Trace capacity refusal and resize ownership; calculate 4K/three-frame target overlap and report evidence, limitations and fix direction.
- Area
- Project Rubi-Ka
- Project
- engines
- Kind
- Research
- Task ID
tsk_hktuw2bkfc- Updated