Is there any way to use vulkan internal allocation callbacks without overwriting real allocations?

Question

When specifying a VkAllocationCallbacks struct to vkCreate* functions, I would like to use only the vulkan notification without overwriting the real allocators, but I can't find how.

From https://www.khronos.org/registry/vulkan/specs/1.1-extensions/man/html/VkAllocationCallbacks.html

• pfnAllocation must be a valid pointer to a valid user-defined PFN_vkAllocationFunction

• pfnReallocation must be a valid pointer to a valid user-defined PFN_vkReallocationFunction

• pfnFree must be a valid pointer to a valid user-defined PFN_vkFreeFunction

• if either of pfnInternalAllocation or pfnInternalFree is not NULL, both must be valid callbacks

It seems weird to me that I can't just pass a nullptr to use the default allocations, is there any rationals for this ?

Maybe that it is possible to query the default allocators at runtime, but I haven't found any way to do it, I'd be glad to know if it is possible in a portable way.

Answer 1

As it seems that it's not possible, I would simply use a hand written allocator fulfilling the required alignement (with for exemple ::operator new in C++17). This allocator is very likely to be less performant than the Vulkan default one, but if it is only needed for debugging purposes it should do the trick.

Answer 2

You may not be fully understanding the difference between these sets of functions.

The first set of functions, the allocation functions, are used by Vulkan to allocate CPU memory... most of the time. The other two functions, the internal notification functions, are for the other times.

See, there are times when the Vulkan implementation needs to make OS-specific system calls to allocate memory. The Vulkan specification recognizes such a case: to allocate "executable memory": memory containing opcodes for the CPU's instruction set. For security reasons, OS's don't let you just execute random memory addresses; modern OS's require most apps to allocate memory in a special way in order for it to be executable. Therefore:

The application is not expected to handle allocating memory that is intended for execution by the host due to the complexities of differing security implementations across multiple platforms. The implementation will allocate such memory internally and invoke an application provided informational callback when these internal allocations are allocated and freed.

Normal memory allocation functions like ::operator new or malloc can't do that. And the Vulkan specification does not expect the client code to be able to make those system calls either.

However, the client code may need to be able to track such allocations, so that it can know how much memory the Vulkan implementation is keeping around. Therefore, when "internal allocations" are made/freed, the internal notification functions are called.

This is the only time such functions are called.

So if your goal is just to track when implementation allocations are being made/freed, the internal notification functions alone are not going to get the job done. You have to override them all, which means you'll need to actually do the allocation/reallocation/freeing.