What makes the aforementioned workarounds ugly or difficult?
A simple example is a typical buffer use in form of calls: (1) `vkCreateBuffer()`, (2) `vkGetBufferMemoryRequirements()`, (3) `vkAllocateMemory()`. Delaying is not enough because we need a handle for (2). If we re-create buffer in (3) we have no guarantees that the result of (2) is still valid (it's probably valid in practice, but implementation is free to return different requirements for host importable buffers).
If we recreate the buffer in (3), recheck that the memory still meets the buffer requirements, and find that it doesn't, can we fall back to two buffers and a blit? Or return VK_ERROR_OUT_OF_HOST_MEMORY from vkBindBufferMemory()?
Also, wrapping buffers/images means a lot more unwrapping code even for targets that don't need it. The number of required private thunks also quickly grows, meaning non-trivial future maintenance cost. This could be bearable if we didn't have a choice, but with VK_EXT_map_memory_placed on the horizon, I think it's valuable to keep fallback code path simple.
Well, at a certain point I think the fallback code path has to just be "don't enumerate the device".
If this isn't going to expose optimal performance anyway (I at least think two games are not really enough to accurately measure a difference), I would assert that we should do something slow yet completely safe, like copy the whole buffer, as with GL.
I wouldn't call memcpy() solution safe. At very least because it would require quite invasive changes and memory coherency would be just broken. I would expect something like that to quickly get very ugly.
Hmm, well, it wouldn't necessarily be memcpy(), you could create a separate VkBuffer/VkMemory and blit. For coherency you'd presumably need to do an explicit blit command every time you do a draw or copy command. Granted, yes, this does get complicated.
Failing that, I'd just say it's not worth merging this. But then again, I suppose I also don't understand the rush to merge WoW64 upstream at any cost of performance or correctness, without first addressing those costs.
I'm not sure what you're referring to. The MR was marked as a draft for a reason. And even if we had VK_EXT_map_memory_placed available tomorrow, having some fallback for existing drivers would still be interesting.
Well, that's partly that it's not just this merge request that gives me that impression, partly because I didn't notice it was a draft (though I'm still unclear on what "draft" is supposed to mean with gitlab), and partly because the subject seems to imply that (except for the last patch) it's meant to be merged eventually anyway.