Hi! I’m building a Vulkan/OpenGL rendering engine, primarily for games. (in Java with LWJG3 but I don’t think that’s relevant)
So I clearly have much to learn about vulkan and its ins and outs. But one thing that I really struggle to understand and find any explanations is the memory allocator. I’ve sifted trough the Khronos talks about Vulkan on YouTube and am tempted to go to page 2 on google. I’ve really struggled to find an explanation. (although there is an example on github with questionable quality)
So I’m wondering:
[ul]
[li]What is the difference if I create my own from not using one?
[/li][li]Why should I need one?
[/li][li]If I should, is there an explanation of it and how it should work in theory?
[/li][/ul]
Thank you for your time! 
It’s not clear what any of these questions mean. What exactly are you referring to by “a custom allocator”? And what would you be using if you weren’t using one?
What you shouldn’t do is use vkAllocateMemory the way you would have used glBufferData and glTexImage*D in OpenGL. You should never create an allocation for every individual buffer and texture.
So while you may not need some object to govern which Vulkan objects are associated with exactly which regions of memory, you do need some kind of scheme in place to apportion out the vkAllocateMemory storage. You could call that a “custom allocator”. Also, your allocation strategy needs to recognize that implementations may limit which memory types particular objects can be allocated from.
I’m sorry. I thought it was clear.
I was referring to the VkAllocationCallbacks. Not the act of allocating memory.
They’re tools of low-level optimization, for when you need to control where Vulkan implementations get most of their memory from. For example, using them with VkCommandPool objects would allow you some control over how often you’re allocating memory from the OS. OS allocation requires locking a mutex and is pretty expensive, so if you can preallocate a range of storage and sub-allocate from within it, you might save some performance in your command buffer building code.
Or it might save nothing.
Basically, writing your own VkAllocationCallbacks allocators is something you should do when you have specific needs for specific memory optimizations (and in some cases, you might only do it for specific Vulkan implementations that you know the allocation patterns of). It’s not something you should do just because you’re using Vulkan.
How they work is well specified by the specification. The callbacks you register for a specific object will be used by any allocations caused by that object and any other objects which are owned by that object (unless you specify different callbacks for that object).
Ohh! Thank you! That clears up so much…