VMA_ALLOCATION_CREATE_HOST_ACCESS_ALLOW_TRANSFER_INSTEAD_BIT usage

[tksuoran]

Quote from https://howtovulkan.com/:

The specific flags combination of VMA_ALLOCATION_CREATE_HOST_ACCESS_SEQUENTIAL_WRITE_BIT and VMA_ALLOCATION_CREATE_HOST_ACCESS_ALLOW_TRANSFER_INSTEAD_BIT used here make sure we get a memory type that's located on the GPU (in VRAM) and accessible by the host.

Meanwhile, quote from VMA / vk_mem_alloc.h:

Together with VMA_ALLOCATION_CREATE_HOST_ACCESS_SEQUENTIAL_WRITE_BIT or VMA_ALLOCATION_CREATE_HOST_ACCESS_RANDOM_BIT,
it says that despite request for host access, a not-HOST_VISIBLE memory type can be selected if it may improve performance.

By using this flag, you declare that you will check if the allocation ended up in a HOST_VISIBLE memory type (e.g. using vmaGetAllocationMemoryProperties()) and if not, you will create some "staging" buffer and issue an explicit transfer to write/read your data.

To prepare for this possibility, don't forget to add appropriate flags like VK_BUFFER_USAGE_TRANSFER_DST_BIT, VK_BUFFER_USAGE_TRANSFER_SRC_BIT to the parameters of created buffer or image.

To me it seems VMA_ALLOCATION_CREATE_HOST_ACCESS_ALLOW_TRANSFER_INSTEAD_BIT might not be used correctly in this sample. I believe either the bit should be dropped, or else the sample would need to check if the memory ends up host visible and deal with the case when it is not.

[SaschaWillems]

That assumption is correct. This might fall back to device only memory, but afaik there are no VK 1.3+ devices that don't support a device local + host visible type. I'll probably add some wording to clarify this.

[fbessou]

I tend to agree that we could remove this flag since 1. we don't expect it to have any effect and 2. we don't handle the case where the allocation is not visible by the host.

[JackJ30]

Yep, I feel like it should be removed. Why add the flag saying "I can use transfer", when we won't use transfer.