有没有办法在不覆盖实际分配的情况下使用 vulkan 内部分配回调？
Is there any way to use vulkan internal allocation callbacks without overwriting real allocations?
当为 vkCreate* 函数指定一个 VkAllocationCallbacks 结构时，我想只使用 vulkan 通知而不覆盖真正的分配器，但我找不到如何做。
来自https://www.khronos.org/registry/vulkan/specs/1.1-extensions/man/html/VkAllocationCallbacks.html
pfnAllocation 必须是指向有效用户定义 PFN_vkAllocationFunction
pfnReallocation 必须是指向有效用户定义 PFN_vkReallocationFunction
pfnFree 必须是指向有效用户定义 PFN_vkFreeFunction
如果 pfnInternalAllocation 或 pfnInternalFree 中的任何一个不为 NULL，两者都必须是有效的回调
我不能只传递 nullptr 来使用默认分配，这对我来说似乎很奇怪，这有什么合理性吗？
也许可以在运行时查询默认分配器，但我还没有找到任何方法，我很高兴知道它是否可以以可移植的方式实现。
您可能没有完全理解这些函数集之间的区别。
第一组函数，即分配函数，Vulkan 使用它来分配 CPU 内存……大部分时间。另外两个功能，内部通知功能，是其他时间的。
看，有时 Vulkan 实现需要进行 OS-specific 系统调用来分配内存。 Vulkan 规范识别这样一种情况：分配 "executable memory": 包含 CPU 指令集的操作码的内存。出于安全原因，OS 不允许您只执行随机内存地址；现代 OS 要求大多数应用程序以特殊方式分配内存以使其可执行。因此：
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.
像::operator new 或malloc 这样的普通内存分配函数无法做到这一点。 Vulkan 规范也不期望客户端代码能够进行这些系统调用。
但是，客户端代码可能需要能够跟踪 此类分配，以便它可以知道 Vulkan 实现保留了多少内存。因此，当"internal allocations"为made/freed时，会调用内部通知函数。
这是唯一一次调用此类函数。
因此，如果您的目标只是跟踪实施分配的时间 made/freed，内部通知功能 单独 将无法完成工作。您必须全部覆盖它们，这意味着您需要实际执行 allocation/reallocation/freeing.
因为这似乎是不可能的，所以我会简单地使用手写的分配器来满足所需的对齐（例如 C++17 中的 ::operator new）。
此分配器的性能很可能不如 Vulkan 默认分配器，但如果仅用于调试目的，它应该可以解决问题。
当为 vkCreate* 函数指定一个 VkAllocationCallbacks 结构时，我想只使用 vulkan 通知而不覆盖真正的分配器，但我找不到如何做。
来自https://www.khronos.org/registry/vulkan/specs/1.1-extensions/man/html/VkAllocationCallbacks.html
pfnAllocation 必须是指向有效用户定义 PFN_vkAllocationFunction
的有效指针
pfnReallocation 必须是指向有效用户定义 PFN_vkReallocationFunction
的有效指针
pfnFree 必须是指向有效用户定义 PFN_vkFreeFunction
的有效指针
如果 pfnInternalAllocation 或 pfnInternalFree 中的任何一个不为 NULL，两者都必须是有效的回调
我不能只传递 nullptr 来使用默认分配，这对我来说似乎很奇怪，这有什么合理性吗？
也许可以在运行时查询默认分配器，但我还没有找到任何方法，我很高兴知道它是否可以以可移植的方式实现。
您可能没有完全理解这些函数集之间的区别。
第一组函数，即分配函数，Vulkan 使用它来分配 CPU 内存……大部分时间。另外两个功能，内部通知功能，是其他时间的。
看，有时 Vulkan 实现需要进行 OS-specific 系统调用来分配内存。 Vulkan 规范识别这样一种情况：分配 "executable memory": 包含 CPU 指令集的操作码的内存。出于安全原因，OS 不允许您只执行随机内存地址；现代 OS 要求大多数应用程序以特殊方式分配内存以使其可执行。因此：
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.
像::operator new 或malloc 这样的普通内存分配函数无法做到这一点。 Vulkan 规范也不期望客户端代码能够进行这些系统调用。
但是，客户端代码可能需要能够跟踪 此类分配，以便它可以知道 Vulkan 实现保留了多少内存。因此，当"internal allocations"为made/freed时，会调用内部通知函数。
这是唯一一次调用此类函数。
因此，如果您的目标只是跟踪实施分配的时间 made/freed，内部通知功能 单独 将无法完成工作。您必须全部覆盖它们，这意味着您需要实际执行 allocation/reallocation/freeing.
因为这似乎是不可能的，所以我会简单地使用手写的分配器来满足所需的对齐（例如 C++17 中的 ::operator new）。 此分配器的性能很可能不如 Vulkan 默认分配器，但如果仅用于调试目的，它应该可以解决问题。