VK_ERROR_OUT_OF_DEVICE_MEMORY during memory heap allocation

Answer to the Core Questions

1. Prioritization when the primary device‑local heap is exhausted

• First, query vkGetPhysicalDeviceMemoryProperties and build a list of memory types that satisfy both the required usage flags and the VK_MEMORY_PROPERTY_DEVICE_LOCAL_BIT property.
• Iterate over that list in order of increasing heap index. Some GPUs expose multiple device‑local heaps (e.g., discrete VRAM and a shared pool). Selecting a type that belongs to a different heap can avoid the exhausted region.
• If no remaining device‑local type can accommodate the allocation size, fall back to a host‑visible type that still matches the usage flags. Accept the performance penalty but ensure the application continues to run.
• Record the VkMemoryHeap.size for each heap during initialization. Before calling vkAllocateMemory, compare the requested size against the heap’s remaining free space to predict VK_ERROR_OUT_OF_DEVICE_MEMORY and skip the call if it would fail.

2. Mapping memory types portably across GPU vendors

• Do not hard‑code heap indices or vendor‑specific flags. Instead, perform a generic scan:

VkPhysicalDeviceMemoryProperties prop; vkGetPhysicalDeviceMemoryProperties(phys, &prop);
for (uint32_t i = 0; i < prop.memoryTypeCount; ++i) {
    if ((prop.memoryTypes[i].propertyFlags & requestedProps) == requestedProps &&
        (prop.memoryTypes[i].propertyFlags & VK_MEMORY_PROPERTY_DEVICE_LOCAL_BIT)) {
        // candidate device‑local type
    }
}

• When no device‑local candidate exists, relax the property mask to include VK_MEMORY_PROPERTY_HOST_VISIBLE_BIT and repeat the scan.
• Because integrated GPUs may expose device‑local memory that is actually shared with system RAM, you should benchmark or monitor the performance impact of each chosen type on your target devices.

Practical Steps for Your Current Case

1. Collect heap metrics: Immediately after device creation, print each VkMemoryHeap.size and the corresponding VkMemoryType.propertyFlags so you can see the actual capacities.
2. Predict allocation failure: Before calling vkAllocateMemory, subtract the requested size from the free space you tracked. If the result is negative, skip the allocation and go to step 3.
3. Attempt a fallback allocation: Use the logic described above to pick the next best memory type. Prefer a different heap index first, then host‑visible if necessary.
4. Validate the fallback: After allocation, query the memory’s heap index via vkGetDeviceMemoryProperties (if available) or keep a mapping table. Verify that the allocation succeeded and that the heap size is sufficient.

Question for Clarification

Do you have the exact size of the asset you are trying to allocate on the production device? Knowing the requested size relative to the reported heap sizes can help refine the fallback selection logic.