Add reserved_bytes method for Allocator

[ftilde]

This fills the use case where one needs the total number of reserved bytes from an Allocator, but compiling a complete report (in particular due to the calls to report_allocations from the SubAllocator) would be too costly.

I've encountered this in a (not yet open) project of mine and would be happy if you would accept this contribution. My workaround of just counting the allocation size myself underestimates the total allocated memory due to fragmentation.

[Jasper-Bekkers]

Thanks for the contribution, please don't forget to sign the commits.

What's the intended use-case for this, and would it be OK to chose another name so it doesn't conflict with the Dx12 feature of reserved memory (CreateReservedResource)? I tend to want to stay away from overloading terms as much as possible (though not too extreme).

[ftilde]

On 24.02.2025 05:39, Jasper Bekkers wrote: Jasper-Bekkers left a comment (Traverse-Research/gpu-allocator#266) Thanks for the contribution, please don't forget to sign the commits.

Sure, I'll figure this out shortly.

What's the intended use-case for this

In my application, (large 3D volume visualization/processing), I basically expect to use the whole VRAM, however (at least Linux with mesa vulkan drivers) the OS does not seem to report OOM when I just keep allocating. I suspect that part of VRAM is swapped to RAM because everything becomes very slow in that case. My workaround so far has been to count the allocated memory on every alloc/dealloc and clean up some of the allocations when I hit a user-specified limit (e.g. 80% of physical VRAM). The problem is that due to fragmentation this count is below the actual memory requested by the allocator which results in sometimes causing swapping again if the limit is not chosen very conservatively. I tried to use the property `total_reserved_bytes` of `AllocatorReport`, which works in principle, but is relatively slow to call due to the detailed information collected about all subblocks which I'm not even interested in, in this case. Hence I moved this functionality of `generate_report` into a separate function.

and would it be OK to chose another name so it doesn't conflict with the Dx12 feature of reserved memory (`CreateReservedResource`)?

Sure! Do you have a preference? I picked this name due to the similar name of the property of `AllocatorReport` and was not aware of the Dx12 feature. Maybe `total_memory_block_size`?

[MarijnS95]

Sure! Do you have a preference?

How about picking the capacity term from Rust? @Jasper-Bekkers wdyt?

I picked this name due to the similar name of the property of AllocatorReport and was not aware of the Dx12 feature.

Ouch, maybe we should update that as well in-line with this choice.

[Jasper-Bekkers]

Capacity would be the proper name here indeed. We should also update the reporting api in that case.

[ftilde]

Alright, I've added a commit to change AllocatorReport, changed the name of the added method and signed the commits.