Persistently Mapped Buffer is Causing Bad VK_IMAGE_TILING_LINEAR Temporary Image about vulkanmemoryallocator

[adam-sawicki-a]

Unfortunately I don't have a Mac environment to test the code.

First of all, I can see you are not using VkSubresourceLayout::offset returned by vkGetImageSubresourceLayout, which you should do when accessing mapped data of a linear image.

If that doesn't help, you may check if adding VMA_ALLOCATION_CREATE_DEDICATED_MEMORY_BIT flag to allocation created for that image helps. That would be a valuable information.

Please also check if Vulkan validation layers are really enabled and if they don't report any warnings or errors.

How does the corruption (invalid image data) looks like? Maybe something can be concluded from this data.

What memory heaps and types are available on this platform? Can you please show output of vulkaninfo command?

[DiegoAce]

Thanks for letting me know about VkSubresourceLayout::offset. I implemented it but it unfortunately it didn't make a difference in this example because the offset was 0.

Adding the VMA_ALLOCATION_CREATE_DEDICATED_MEMORY_BIT flag does fix the problem. I can use that if that's how you expect persistently mapped data to be created, but it seems unusual because the problem occurs regardless the size of the persistently mapped data. In the example its only 1 byte. Also I don't believe I'm mapping any data simultaneously.
I also tried using VMA_ALLOCATION_CREATE_MAPPED_BIT flag but that didn't help and sounds relatively identical to calling vmaMapMemory after creation.

The validation layers are working. I've used them quite extensively. There are no reported warnings or errors in the example.

The corruption has always appeared as if the image was just a solid color. In this example it is black. So if I change the screen clear color to something other than black then you can see a black rectangle where the image should be. In another example the image just became solid blue. I'm not sure what determines the color.

I attached the vulkan info output.

vulkaninfo.txt

[DiegoAce]

I'm not sure if this is related but I'm getting a validation warning with this updated code. It's nearly identical to the previously attached main.cpp. At the beginning of the createTextureImage function I create two images. I transition one to VK_IMAGE_LAYOUT_TRANSFER_SRC_OPTIMAL and map the second. In the call to vmaMapMemory on stagingImageMemory2 I get the validation warning, "Mapping an image with layout VK_IMAGE_LAYOUT_TRANSFER_SRC_OPTIMAL can result in undefined behavior if this memory is used by the device. Only GENERAL or PREINITIALIZED should be used." This seems unusual because I never transitioned the second image. I get this validation warning regardless if any data is persistently mapped.

main.cpp.zip

[adam-sawicki-a]

Thank you very much for this test. Indeed this is a very strange bug. I think it is possible that it's a bug in MoltenVK and not in VMA.

Please make sure you use latest version of Vulkan SDK (or whatever is the MacOS equivalent).

One thing you may try is a debug session where you could compare the pointer returned by vmaMapMemory with VmaAllocation's (char*)m_BlockAllocation.m_Block->m_pMappedData + m_BlockAllocation.m_Offset to check if it's offseted correctly.

You could also try to allocate your images in similar way but without using VMA and see if that works:

• Allocate one big block of VkDeviceMemory, like 256 MB.
• Bind your images to different non-zero offsets of this block, respecting their VkMemoryRequirements (especially offset).

[DiegoAce]

Yes, that's possible. I can bring this to the attention of the MoltenVK devs.

The pointer returned by vmaMapMemory is correctly offset from that m_pMappedData. I noticed that these two image allocations share the same m_BlockAllocation.m_Block, and when I follow the vmaMapMemory function it goes into VmaAllocator_T::Map and then VmaDeviceMemoryBlock::Map, and inside there it calls

VkResult result = (*hAllocator->GetVulkanFunctions().vkMapMemory)(
            hAllocator->m_hDevice,
            m_hMemory,
            0, // offset
            VK_WHOLE_SIZE,
            0, // flags
            &m_pMappedData);

I could be missing something simple, but that looks like to me it maps the entire block. After returning from vmaMapMemory both vmaAllocation's have the same m_pMappedData and the second has a nonzero m_Offset.
Are you saying that I should be able to map the whole memory block and I shouldn't be getting the validation warning for another reason?

[adam-sawicki-a]

You are right. The way VMA implements mapping is that it always maps entire block, as described in documentation chapter "Memory mapping" → "Mapping functions".

The warning from Vulkan validation layers you experience is expected in that case. I'm sorry I forgot to mention that before. It's described in documentation chapter "General considerations" → "Validation layer warnings" → point 2.

Still I believe it should work correctly. If it's not, then my best guess is that it's the fact that some of the images is bound to a non-zero offset that is causing the problem. Question is: which one and where is the bug with offset not respected: in MoltenVK, VMA, or in your code.

[adam-sawicki-a]

Hey, any update on this? :)

[DiegoAce]

I had not gotten around to doing the more testing that this needed until now. I determined that it is not a VMA bug and is in fact a limitation with MoltenVK as referenced here:
KhronosGroup/MoltenVK#175

I wish I had found that sooner.
Sorry for the trouble. Thanks for your help!

[adam-sawicki-a]

Thank you for finding this out. If you use memory type that has HOST_COHERENT flag and you still need to Flush or worse Unmap then surely it's a bug in Vulkan implementation.