Exporting Memory handle

[Agrael1]

Hello, I have a use case for OpenGL/Vulkan interop for memory.

Documentation says, there is pNext equivalent for that for pools and for allocator.
However, there is no API for retrieving the handle. I could retrieve the allocation memory, but there is a problem:

VUID-VkMemoryGetWin32HandleInfoKHR-handleType-00663
If handleType is defined as an NT handle, vkGetMemoryWin32HandleKHR must be called no more than once for each valid unique combination of memory and handleType

If the allocation is shared between multiple distant resources, there is no guaranteed way to get the handle. One will always result in error. Is there a way make it work?

[adam-sawicki-a]

If I understand it correctly, the VK_KHR_external_memory_win32 extension is about retrieving a HANDLE from a VkDeviceMemory object, so you can create some other object from it in another API. This needs explicit control over when the VkDeviceMemory object is created and destroyed, which contradicts the core idea of VMA to manage those automatically, create and destroy them under the hood without explicit control.

I was thinking that maybe I could introduce some vmaGetMemoryWin32HandleKHR function that would retrieve the HANDLE on a first call and store it internally, but if you use the handle to create some objects in OpenGL, I guess you need to also destroy them before the Vulkan memory gets freed?

I think the right solution is to manage and keep track of Vulkan device memory blocks manually in this case. For example, you can:

• Save a map of {VkDeviceMemory -> HANDLE} so you make sure you retrieve the handle only once per memory block.
• Create a custom pool with specific minBlockCount equal to maxBlockCount to make sure you control when the blocks are allocated and freed.
• Allocate a memory block manually and place your resources inside of it. You can still use VMA for that:
  • To allocate a memory with a dedicated VkDeviceMemory object, without creating a buffer or a texture, use vmaAllocateMemory with VMA_ALLOCATION_CREATE_DEDICATED_MEMORY_BIT.
  • To create a buffer placed inside of it at a specific offset, use vmaCreateAliasingBuffer2. Similar function exists for images.
  • To use the core allocation algorithms to manage the space and find the best spot for a new resource, you can use the "virtual allocator" feature.

[Agrael1]

HANDLE as well as FD is a shared structure underneath. The best thing here would be to retrieve the handle, store it, and then on call just DuplicateHandle(). That would relieve the control over the handle for vma. The control over the memory is also in HANDLE (Issue #1). So if you deallocate the memory with vma, the memory will not be destroyed unless CloseHandle/Close is called. That would be much appreciated, since overhead of such solution is negligible, only 1 std::atomic<HANDLE>, even mutex will not be needed.

Save a map of {VkDeviceMemory -> HANDLE} so you make sure you retrieve the handle only once per memory block.

Too expensive and bloated.

Create a custom pool with specific minBlockCount equal to maxBlockCount to make sure you control when the blocks are allocated and freed.

The pool memory can't be retrieved, only allocated. I am not sure that allocating memory, getting handle and freeing is correct and will not result in UB. (tried that)

Allocate a memory block manually and place your resources inside of it. You can still use VMA for that:

Will try.

[Agrael1]

Also, as I have noticed there is no such problem with FD, it is only Win32 Handle I suppose

[adam-sawicki-a]

Implemented as #442