Device with no maintenance 4 support incorrectly trying to use it.

[jmccarthy634]

This may be a mistake on how we are using the API, but the logic in vmaFindMemoryTypeIndexForBufferInfo (and possibly elsewhere, I didn't check) that decides is as follows:

#if VMA_KHR_MAINTENANCE4 || VMA_VULKAN_VERSION >= 1003000
    if(funcs->vkGetDeviceBufferMemoryRequirements)

We currently have VMA_STATIC_VULKAN_FUNCTIONS for our application set to false and provide our own function pointers to VMA, which we do so unconditionally if they are compiled in. We then provide VMA_ALLOCATOR_CREATE_KHR_MAINTENANCE4_BIT only if the device in question actually has support for the extension. On some older devices it looks like we have valid function pointers for some functions even though we can't use them, or at the very least the return value from vkGetInstance/DeviceProcAddress for them is not null. Obviously as a workaround we can just not set the function pointers in that case, but maybe VMA should also be checking against m_UseKhrMaintenance4 before trying to call these functions.

[sawickiap]

Thank you for reporting this problem. I've made a change as you suggested - using functions vkGetDeviceBufferMemoryRequirements, vkGetDeviceImageMemoryRequirements only when the usage of VK_KHR_maintenance4 or Vulkan version >= 1.3 has been explicitly requested at the allocator initialization.

I applied the change on my fork for now. Please let me know if it works for you.

https://github.com/sawickiap/VulkanMemoryAllocator