[Nathanw1014]

Summary

The compute buffer is split into chunks of at most the backend's max buffer size (1 GiB on Vulkan). The chunk list was a fixed array of 16, so the 16th chunk was made unbounded to hold whatever was left. Once a graph needs more than ~16 chunks, that last chunk can be larger than the device allows.

This came up with Flash-Next at -c 262144 on a 128 GB Strix Halo. The compute buffer was 19.5 GB, which left a 4.4 GiB 16th chunk, over RADV's 4 GiB buffer limit, so the load failed (strix-halo-llamacpp#22).

Change

• The chunk lists in the allocator and the vbuffer grow on demand: 16 to start, then doubling.
• Every chunk stays within the backend max size, unless one tensor alone is larger.
• Graphs that fit in 16 chunks are laid out exactly as before.
• test_not_enough_chunks used to assert the old behaviour (the last chunk grows). It now also runs check_max_size.

Testing

• test-alloc: all 17 pass. As a control, the updated test_not_enough_chunks fails on master (offset + nbytes <= max_size).
• Full Vulkan build has no new warnings.
• Flash-Next UD-Q5_K_XL at the reporter's settings (-c 262144 -ub 2048, experts on CPU), Strix Halo 64 GB, Mesa 26.2.4. Loads fine with and without the patch, so this is a regression check, not a repro. On this box halo-box needs only ~12-14 chunks.
• The same change has shipped in strix-halo-llamacpp v0.7.8.1. There, forcing 512 MiB chunks took the same model to 17 chunks, past the old cap, and it loaded with every chunk at most 1 GiB. The release gate showed no perf change.

🤖 Generated with Claude Code