Orkuncakilkaya
0141f99dd1
lp_os_platform and lp_os_arch malloc'd 8 KB per call (the uname buffer) and kept none of it: string_temps now asks both every round, 327 MB over 20,000 before, 0 after. Reseeded. render3d: MoltenVK made a mapped buffer's MTLBuffer at its first bind (fn_gvk_draw +4 blocks in the boat window); gvk_buf_reserve queues it and the next frame's command buffer copies 4 bytes out of it. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
790 B
bump: patch
type: fix
A frame that draws more than any before no longer grows the heap on the Mac. MoltenVK's command
pooling kept every command object a frame had ever recorded - about 650 bytes for each draw beyond the
busiest frame so far, for as long as the game ran. render3d turns it off
(MVK_CONFIG_USE_COMMAND_POOLING=0, unless the environment already says otherwise) before the first
Vulkan call; the objects are made and freed with their command buffer, at no measured cost.
examples/rendering/steady.ludic ramps a frame from 20 to 200 actors and fails on what pooling left.
A buffer written through its mapping is also read once at the start of the next frame's commands,
so MoltenVK makes its Metal buffer then rather than at its first draw, however much later that is.