[Question] Should Vulkan WriteTexture need vkFlushMappedMemoryRanges?

[BlurryLight]

nvrhi/src/vulkan/vulkan-texture.cpp

Lines 469 to 489 in 8942401

	m_UploadManager->suballocateBuffer(
	deviceMemSize,
	&uploadBuffer,
	&uploadOffset,
	&uploadCpuVA,
	MakeVersion(m_CurrentCmdBuf->recordingID, m_CommandListParameters.queueType, false));
	size_t minRowPitch = std::min(size_t(deviceRowPitch), rowPitch);
	uint8_t* mappedPtr = (uint8_t*)uploadCpuVA;
	for (uint32_t slice = 0; slice < mipDepth; slice++)
	{
	const uint8_t* sourcePtr = (const uint8_t*)data + depthPitch * slice;
	for (uint32_t row = 0; row < deviceNumRows; row++)
	{
	memcpy(mappedPtr, sourcePtr, minRowPitch);
	mappedPtr += deviceRowPitch;
	sourcePtr += rowPitch;
	}
	}
	auto imageCopy = vk::BufferImageCopy()

the code snippnet is trying to first transfer data to upload heap and then using vkCopyBufferToImage to transfer data into device-local memory.
However, the staging buffer is created with eHostVisible instead of eHostCoherent.

nvrhi/src/vulkan/vulkan-allocator.cpp

Lines 40 to 42 in 8942401

	case CpuAccessMode::Write:
	flags = vk::MemoryPropertyFlagBits::eHostVisible;
	break;

Taking Vulkan-Docs:Transfer-dependencies as reference, it seems there should be a vkFlushMappedMemoryRanges between the memcpy and the vkCopyBufferToImage, to ensure the host write is visible.