VRAM: find and track the untracked ~1.5 GB (it varies per machine); feed measured overhead into the budget

sky_line commented

2026-10-05 03:23:41 +00:00

Owner

Part of #405.

The renderer's VRAM log accounts for only part of what the process actually uses. On the owner's machine (RTX 5090, Linux, 1080p window, quiet region, 2026-10-05) the gap was:

VRAM heap0(dev) 5748/24163MB [proc 6064] ... | renderer 4636MB of 6155MB tracked

That leaves ~1.5 GB untracked. The size and makeup of that gap almost certainly differ by GPU vendor, driver, OS (WDDM vs Linux), resolution, monitor count and HDR. So a budget that assumes ~1.5 GB of overhead is wrong for most people. Part A of #405 (one VRAM budget, fixed costs first) can't be right until this is accounted for.

Goals

Find exactly what we're not tracking. Candidates:
- swapchain images (count × size × format, HDR / 10-bit)
- render targets and attachments outside the tracked pools: gbuffer, HDR, TAA/FSR history, depth pyramids, bloom/DoF chains, UI targets
- descriptor pools and heaps
- pipeline and shader memory
- query pools
- VMA / allocator block slack: fragmentation and unused space in large blocks
- driver internal allocations: command buffers, staging the driver does itself
- external memory: CEF/media textures, video decode
- per-frame-in-flight duplicates
Track every allocation we own. Route every vkAllocateMemory and every VMA allocation through one tracker with a category tag (no "other" bucket). Separately report:
- allocator slack: block size minus live suballocations
- driver / external overhead: the OS/driver process usage minus our tracked total
Report it everywhere.
- The VKMem log line gets a full category breakdown.
- The budget readout (#405 part D) shows the same.
- In-viewer bug reports include the breakdown, so we see real numbers from other machines.
Feed the budget. Measured fixed costs plus slack plus overhead become the "fixed" term in the #405 budget, re-measured continuously instead of assumed.

Data to collect

NVIDIA, AMD (RADV and Windows), and Intel if possible.
Windows and Linux.
1080p, 1440p and 4K; one versus two monitors; HDR on and off.
The in-viewer reporter's breakdown gives most of this for free once it's in.

Tools

VK_EXT_memory_budget (process usage)
nvidia-smi --query-compute-apps, radeontop / amdgpu_top
RenderDoc / Nsight / RGP memory views
VMA statistics (vmaCalculateStatistics / budget)

Done when

Untracked gap below ~5% of process VRAM on the test machines, or the remainder explained as driver overhead with a measured value.
Every allocation has a category; allocator slack is reported.
Breakdown in the log, the readout and bug reports.
The #405 budget uses measured fixed and overhead costs.

Related: #244 (VRAM footprint / over-allocation investigation).

Part of #405. The renderer's VRAM log accounts for only part of what the process actually uses. On the owner's machine (RTX 5090, Linux, 1080p window, quiet region, 2026-10-05) the gap was: ``` VRAM heap0(dev) 5748/24163MB [proc 6064] ... | renderer 4636MB of 6155MB tracked ``` That leaves **~1.5 GB untracked**. The size and makeup of that gap almost certainly differ by GPU vendor, driver, OS (WDDM vs Linux), resolution, monitor count and HDR. So a budget that assumes ~1.5 GB of overhead is wrong for most people. Part A of #405 (one VRAM budget, fixed costs first) can't be right until this is accounted for. ## Goals 1. **Find exactly what we're not tracking.** Candidates: - swapchain images (count × size × format, HDR / 10-bit) - render targets and attachments outside the tracked pools: gbuffer, HDR, TAA/FSR history, depth pyramids, bloom/DoF chains, UI targets - descriptor pools and heaps - pipeline and shader memory - query pools - VMA / allocator block slack: fragmentation and unused space in large blocks - driver internal allocations: command buffers, staging the driver does itself - external memory: CEF/media textures, video decode - per-frame-in-flight duplicates 2. **Track every allocation we own.** Route every `vkAllocateMemory` and every VMA allocation through one tracker with a category tag (no "other" bucket). Separately report: - **allocator slack**: block size minus live suballocations - **driver / external overhead**: the OS/driver process usage minus our tracked total 3. **Report it everywhere.** - The VKMem log line gets a full category breakdown. - The budget readout (#405 part D) shows the same. - In-viewer bug reports include the breakdown, so we see real numbers from other machines. 4. **Feed the budget.** Measured fixed costs plus slack plus overhead become the "fixed" term in the #405 budget, re-measured continuously instead of assumed. ## Data to collect - NVIDIA, AMD (RADV and Windows), and Intel if possible. - Windows and Linux. - 1080p, 1440p and 4K; one versus two monitors; HDR on and off. - The in-viewer reporter's breakdown gives most of this for free once it's in. ## Tools - `VK_EXT_memory_budget` (process usage) - `nvidia-smi --query-compute-apps`, `radeontop` / `amdgpu_top` - RenderDoc / Nsight / RGP memory views - VMA statistics (`vmaCalculateStatistics` / budget) ## Done when - [ ] Untracked gap below ~5% of process VRAM on the test machines, or the remainder explained as driver overhead with a measured value. - [ ] Every allocation has a category; allocator slack is reported. - [ ] Breakdown in the log, the readout and bug reports. - [ ] The #405 budget uses measured fixed and overhead costs. Related: #244 (VRAM footprint / over-allocation investigation).

sky_line added the

perf

rendering

labels

2026-10-05 03:23:41 +00:00

sky_line added a new dependency

2026-10-05 03:23:41 +00:00

#405 Epic: RAM/VRAM management -- one budget, tiered texture storage, run on a stated minimum

sky_line referenced this issue

2026-10-05 03:23:41 +00:00

Epic: RAM/VRAM management -- one budget, tiered texture storage, run on a stated minimum #405

sky_line referenced this issue

2026-10-05 06:04:01 +00:00

VRAM: suballocate textures from shared blocks (~0.9 GB of 64 KiB page padding); bonus: group spatially related textures #411