Orkuncakilkaya
df6ea046c3
Plan 25.1c: vk_mac.ll's @lvk_ac (posix_memalign under a 16-byte header of scope/offset/size, atomic counters) passed at every render3d create/destroy (49 sites; the caps probe keeps its own null pair); lvk_ac_bytes/_peak/_allocs/_scope_bytes for the fence, Vk.alloc_bytes. vk_win.ll: null and 0. MoltenVK 1.4.2 counted 0 live bytes through them in steady. Fence findings: gvk_pipeline freed its 17 create infos (and reuses one bufs list); actor_init fills ac_spare with 512 records (actor_fresh, m4_new, v3_new at first placement in play). Compiled, not run (the user's call). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
675 B
675 B
bump: patch
type: fix
Vulkan's host allocations can be counted, a pipeline built in play keeps nothing, and actors come
from a pool made at start-up. With R3D_ALLOC_VK=1 render3d hands one set of
VkAllocationCallbacks to every create and destroy; the runtime counts live bytes, the peak and
bytes per allocation scope (lvk_ac_bytes, lvk_ac_peak, lvk_ac_scope_bytes, Vk.alloc_bytes)
for the memory fence to read. MoltenVK 1.4.2 routes few of its own objects through them. A pipeline
made the first time a variant is drawn frees its seventeen create infos. actor_init makes 512 actor
records, so an actor first placed in play takes one instead of allocating.