VMA crashing at startup on Android 14 devices

[alecazam]

Our android 14 devices (now with Vulkan 1.3 support), are crashing in the following asserts. I don't have the supported extension list yet, since I don't have one of these devices. I think I'll clamp the version we send of to 1.1 maximum for now.

1. This should fallback to vkGetDeviceBufferMemoryRequirementsKHR if maintenance4 is set. That may be required on these Android devices even though they're "1.3".
2. This shouldn't be an assert if these are null, since VK_KHR_maintenance4 may not be set and for some reason these are VMA_NULL.

We are using volk.h, and it seems to support loading these extensions. Also not seeing this problem on Windows Vulkan 1.2 and 1.3, but we're loading maintenance4 on drivers 1.3+. Obviously 1.2 wouldn't enter this path.

if(m_VulkanApiVersion >= VK_MAKE_VERSION(1, 3, 0))
{
	VMA_ASSERT(m_VulkanFunctions.vkGetDeviceBufferMemoryRequirements != VMA_NULL);
         VMA_ASSERT(m_VulkanFunctions.vkGetDeviceImageMemoryRequirements != VMA_NULL);
}

Here is our workaround to just skip this code for now:

           if ( allocatorInfo.vulkanApiVersion >= VK_API_VERSION_1_2 )
	   {
		   allocatorInfo.vulkanApiVersion = VK_API_VERSION_1_1;
	   }

[alecazam]

More info on the assert. I fixed our maintenance4 extension loading to happen on 1.1 or 1.2, but if this is a 1.3 device the vkGetDeviceBufferMemoryRequirements should just be present. So this is an AMD part on Android. We'll keep the clamp to on vulkanApiVersion to 1.1 on Android for now just for safety.

Phone: Samsung Galaxy S22 Ultra
Chip: Samsung Xclipse 920
Gpu: AMD RNDA 2
OS: Android 14
Vulkan version: unknown (either 1.2 or 1.3)

m_VulkanFunctions.vkGetDeviceBufferMemoryRequirements != VMA_NULL

[adam-sawicki-a]

Functions vkGetDeviceBufferMemoryRequirements, vkGetDeviceImageMemoryRequirements have been added in extension VK_KHR_maintenance4, promoted to Vulkan 1.3, so if either of these are available and enabled, these functions are expected to exist. If their pointers cannot be fetched, this is not a bug in VMA, but in the Vulkan implementation on a specific platform. Please report this bug in a repository/website suitable for it.

VMA doesn't offer specifying that VK_KHR_maintenance4 extension has been enabled and using these functions in such case, only when Vulkan 1.3 is enabled. It was a decision made to simplify the code, as using vkGetDeviceBufferMemoryRequirements, vkGetDeviceImageMemoryRequirements versus old vkGetBufferMemoryRequirements, vkGetImageMemoryRequirements is a minor difference - just a matter of not having to create a dummy buffer/texture in functions like vmaFindMemoryTypeIndexForBufferInfo. Please let me know if you have a different opinion about the importance of supporting these functions with VK_KHR_maintenance4.

[alecazam]

We have a lot of PC users with only Vulkan 1.2. So seems odd to exclude calling this when there is a provided extension for 1.1 and 1.2. I don't know how critical this call is to how VMA functions though. I just thought an AMD part shouldn't crash. I've forwarded this message to a friend who works with Samsung, so they're aware of this missing call on what should be a 1.3 driver (I think). But the asserts seem a bit extreme and will cause other Android devs to crash on this rare part.

[adam-sawicki-a]

So, you mean there is a group of devices that only support Vulkan 1.2, but support VK_KHR_maintenance4 extension? If so, I can add support for VK_KHR_maintenance4 to VMA.

As the use of these functions depends on their pointers not being null, would removing these asserts solve the problem with AMD driver?

[alecazam]

All my drivers are 1.1 on Android and 1.3 on Win. But let me check our crash reports for maintenance4. The Vulkan docs really don’t indicate which version you can start using extensions. I also can’t find these parts on gpuinfo. VMA checks the other extensions for null and just skip so this should too. Expecting anything in Android even if in the spec is problematic.