* We try to call vkEnumerateInstanceExtensionProperties to figure out instance
extensions we might want to add, and we can only do this at the moment by
loading the vulkan dynamic library and calling into it.
This fixes a bug where the memory backing an image could be initialized
after the image itself, causing corruptions. ApplyInitialContents was
processing the resources in order of resource id. It is possible that a
VkImage and the VkDeviceMemory it is bound to both have InitialContent
(e.g. because the VkDeviceMemory also backs a buffer), and it is also
possible that the VkImage has a lower resource id than the
VkDeviceMemory. In this case, the VkImage's InitialContent is loaded,
and then the VkDeviceMemory's InitialContent is loaded. This direct
write of the backing memory causes the VkImage content to become
undefined and, at least on my AMD card, causes image corruption.
This is fixed by sorting the resource ids by type, which works because
eResDeviceMemory < eResImage. This sorting is applied only for
VulkanResourceManager.
* The AMD plugins e.g. don't have consistent incrementing versions, and in
general we don't care too much about version numbers or creation/modified
dates. We want the installer to always install the files it should.
* We can load up the msdia140.dll manually and initialise it that way even if
it's not registered properly. That does mean we need to locate the DLL on our
own though - we try in PATH and in a few default paths, and otherwise prompt
the user for it (and save the path in our config).
* It's possible for two threads to hit GetProcAddress on the same module at
once, try to late-fetch the ordinals, and clash. If we lock then only one
thread will perform the fetch, the other thread can wait and bail out once it
finds the ordinals already filled out.
* The WrappedOpenGL constructor may run too early, before capture options are
properly processed. So we re-process them when and if the API is properly
initialised.
* Instead of calculating the mesh output size exponentially by continuously
doubling, we instead double up to a reasonable size (256MB) and then just
allocate only enough to cover what we need after that point. This avoids
getting into the situation where a mesh needs 1.04GB of data and we allocate a
2GB buffer - which may then fail.
Replace call to SHCreateDirectoyExW on the win32 platform with multiple
calls to CreateDirectoryW to avoid deadlock within CoUninitialize which
is called from SHCreateDirectoyExW. MSDN states that calling
CoInitialize during DllMain is prohibited. SHCreateDirectoyExW
internally calls CoInitialize, thus calling SHCreateDirectoyExW inside
the DllMain is prohibited as well.
baldurk