VulkanBufferAllocator.h File Reference

donner::gpu::vulkan::BufferSuballocator - where a Vulkan buffer's memory comes from. More...

#include <vulkan/vulkan.h>
#include <cstdint>
#include <string_view>
#include "donner/gpu/GpuResult.h"

Include dependency graph for VulkanBufferAllocator.h:

Classes
struct	donner::gpu::vulkan::BufferAllocation
	Where one buffer's bytes live. More...
class	donner::gpu::vulkan::BufferSuballocator
	Supplies the memory a buffer is bound into. More...
class	donner::gpu::vulkan::DedicatedBufferAllocator
	The passthrough implementation: one dedicated VkDeviceMemory per buffer, mapped for its lifetime. Every allocation it returns owns its memory and starts at offset zero. More...

Namespaces
namespace	donner
	Top-level Donner namespace, which is split into different sub-namespaces such as donner::svg and donner::css.

Detailed Description

donner::gpu::vulkan::BufferSuballocator - where a Vulkan buffer's memory comes from.

The backend gives every buffer its own VkDeviceMemory, persistently mapped. That is the simplest thing that is correct, and it is what this seam's only implementation still does.

The seam exists because replacing it is a memory-management change, not an API change, and the two should not have to happen together. A device has a small, driver-reported cap on how many allocations may exist at once, and one allocation per buffer walks toward that cap in proportion to how many buffers a scene needs; suballocating many buffers out of a few larger allocations is the standard answer. Making that swap later means writing another implementation of this interface, not touching every call site that creates a buffer.

It is deliberately introduced without the suballocating implementation: which allocation sizes, which pooling, and whether the cap is actually the binding constraint here are questions for measurement, and shipping a suballocator before that measurement would be guessing at a policy no counter has justified yet.