Some thoughts about Vulkan memory allocation and drivers stuff

VulkanMemoryThoughts.txt

so usage will tell what are it's memory requirements, then we select the heap to allocate it from by comparing
the memory requirements for all available heaps in the physical device?

so vkGetBufferMemory erquirements takes in usage flags and returns which memoryType to use but not the Heap Index because that can be 
implicitly inferered frmo memorytype? 

so we check for compatible memortypes and return that index 

vkGetBufferMemoryRequirements(VkDevice device, VkBuffer buffer, VkMemoryRequirements* pMemoryRequirements)
This call returns a VkMemoryRequirements structure, which includes:

size — required allocation size.
alignment — required offset alignment.
memoryTypeBits — a bitmask of supported memory types (bit i set ⇢ memory Type i is compatible with this buffer) 


The driver exposes all memory types that meet the basic usage requirements—but does not narrow this mask according to the desired
VkMemoryPropertyFlags (e.g., host-visible, coherent). It is the application’s responsibility to:

Filter memoryTypeBits for bits corresponding to memory types whose propertyFlags satisfy its needs.

Select the corresponding heap index (from VkMemoryType::heapIndex) in order to build a valid VkMemoryAllocateInfo 

Queried via vkGetPhysicalDeviceMemoryProperties(…), VkPhysicalDeviceMemoryProperties structure reports:

memoryHeaps[n] (size, heap flags)
memoryTypes[m] (heapIndex + propertyFlags)

Each memory type points to one heap, and its propertyFlags (e.g., DEVICE_LOCAL, HOST_VISIBLE, HOST_COHERENT) determine what 
operations—such as vkMapMemory—are permitted.

Structure: VkMemoryAllocateInfo
When binding a buffer to memory via vkAllocateMemory, applications provide a memoryTypeIndex chosen from the filtered set, plus any 
additional flags or chained pNext structures to import/export or control allocation behavior 

The spec requires that the chosen memoryTypeIndex correspond to one of the bits set in memoryTypeBits, and that its propertyFlags
satisfy any VK_MEMORY_PROPERTY_* requirements.

Function: vkMapMemory(VkDevice device, VkDeviceMemory memory, …, void** ppData)
Only memory types with the HOST_VISIBLE bit may be mapped; using vkMapMemory on non-host-visible memory is invalid and must fail 

Certain drivers (e.g., Turnip on Mesa) may internally prioritize specific memory heaps—returning a memoryTypeBits that includes
\lazily-allocated, device-local-only types (e.g., flags = DEVICE_LOCAL | LAZILY_ALLOCATED) even when the application requested 
host-visible memory. Since the mask alone doesn’t encode which heap index to use, the driver leaves the choice to the application,
causing silent misconfiguration until vkMapMemory is called.