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>
9 lines
675 B
Markdown
9 lines
675 B
Markdown
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.
|