VKR: My Vulkan experiment written in Rust

[Fahien]

Hi everyone!

I started this project to improve my skills with both Vulkan and Rust and it also happens that I own a M1 macbook so I gladly use it for development and testing.

A bunch of releases are available which show the progress, from drawing simple shapes and textures, to changing pipelines at runtime within a renderpass with two subpasses.

My last effort was to introduce shadow mapping, unfortunately it does not work as expected on the M1 and I am not sure if it makes sense to open an issue here.

Using one renderpass with two subpasses works fine. Inserting another render pass (shadowmap) before the main one breaks rendering in this way: while the shadowmap is correctly sampled and drawn in the second renderpass, the attachments drawn in the first subpass of the main renderpass are black in some frames (2/3?), so they are either:

• incorrectly drawn in the first subpass of the main renderpass.
• incorrectly sampled in the second subpass of the main render pass.

If you would like to reproduce the issue, please checkout branch sync-issue and follow the README.md to set everything up, then run cargo run --bin 5-shadow.

[Fahien]

I think I found the issue, even though I do not understand it completely.

It relates to VMA, which allows me to better use memory taking advantage of big preallocated chunks of memory.

So, I create a buffer A of 16 bytes (VMA puts it at offset 0 of the block), and a buffer B of 32 bytes (offset 16) containing my quad vertices for the second subpass. At a certain point I need more memory for buffer A, therefore I destroy it and create a new buffer.

This is where something bad happens: when I destroy buffer A at offset 0, instead of clearing just 16 bytes, for some reason it clears 32 bytes. Last 16 bytes belong to my quad vertex buffer, now unusable.

My workaround for the moment is to force all buffers size to a minimum of 32 bytes.

[billhollings]

What's happening under the covers?

Do all three buffers use the same VkDeviceMemory? And if so, what is the offset used for the larger version of buffer A?

[Fahien]

@adam-sawicki-a would probably know more about what happens under the hood, but yes, I think all three buffers use the same VkDeviceMemory. The offset of the new buffer is correctly computed, therefore in the example above it would be 48.

[adam-sawicki-a]

VMA doesn't clear or otherwise change contents of a buffer or image it allocates and deallocates, unless you use special debug features: VMA_DEBUG_INITIALIZE_ALLOCATIONS, VMA_DEBUG_DETECT_CORRUPTION. They are disabled by default, so if you didn't use them, it must be your Vulkan implementation (MoltenVK) not VMA that is overwriting the data.

Forcing alignment of all your resources to some minimum value e.g. 32 B, using function vmaCreateBufferWithAlignment and/or a custom pool with VmaPoolCreateInfo::minAllocationAlignment may workaround the problem, but it would be still a bug in MoltenVK if it returns too low alignment for a resource from vkGetBufferMemoryRequirements.

If you access these buffers via mapped pointer, it is very likely that you calculate wrong offset and overwrite the data yourself. Please note vmaMapMemory returns a pointer already shifted to the beginning of an allocation not whole memory block, so you should not add an offset of your allocation. See documentation: https://gpuopen-librariesandsdks.github.io/VulkanMemoryAllocator/html/vk__mem__alloc_8h.html#ad5bd1243512d099706de88168992f069