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>
10 lines
790 B
Markdown
10 lines
790 B
Markdown
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.
|