Add option to disallow increasing capacity when allocating

[ftilde]

As it turns out, exposing the capacity (#266) is not quite enough for my use case to restrict the size of the capacity (because I don't know when a new allocation would increase the capacity).

There are multiple ways I can think of on how to achieve that:

• Adding an API to give the allocator a maximum capacity. Since there are multiple memory heaps, whose sizes and properties are not exposed to the user, I'm not sure how that should look like exactly.
• Enabling the user to control whether (or not) the allocator increases the capacity on allocation (via a mutable property on the allocator).
• Enabling the user to control whether a specific allocation is allowed to increase the capacity.

I the PR I (for now) implemented the latter option since I consider it to be the most flexible. I'm open to changing the implementation to one of the other options (or another idea), however.

Also note that I have only implemented the proposed change for Vulkan so far. If you like the proposed change I can add the same for D3D12 and metal.

As another motivation for my use case: I just tried to use the allocator without any upper bound on the total allocation size or capacity, and it just keeps allocating until, first, VRAM memory is swapped to GTT (with huge slowdowns) and finally (when the GTT is full) the compositor becomes unresponsive, i.e. my graphical session freezes. It seems like some drivers just never return ERROR_OUT_OF_DEVICE_MEMORY.

[Jasper-Bekkers]

Can't you just use the dedicated memory feature at that point?

[MarijnS95]

Just noting that for the title, I'd have expected this to say something like Add an option to disallow allocating new blocks or similar, since we already support "increasing capacity" through various ways (new blocks, even growing blocks with #254) and the goal of this PR is to have an option to disable that :)

[ftilde]

On 28.02.2025 05:09, Jasper Bekkers wrote:

Can't you just use the dedicated memory feature at that point?

Hm, I'm not sure what you mean. Could you expand on that? Do you suggest using VK_KHR_dedicated_allocation/the respective Vk1.1 functionality/the respective AllocationScheme? If that's the case I'm not sure how it helps my problem, since (1) I'm not sure how much overhead the driver will have due to fragmentation and (2) the number of allocations (maxMemoryAllocationCount) can be quite limited apparently (e.g. 4096).