* The only formats the spec requires are for optimalTiledFeatures and already
requires all the usage bits we are going to enable ourselves. The only cases
where we can get in trouble is for formats that support a subset of those
features e.g. on linear tiled images.
* So we can safely remove the reported support for those formats and still be
compliant. The application must then work with that lack of support the same
way as it would do if the ICD itself didn't have that support.
* For some reason the actual paint event never makes it through after converting
to metal-compatible widgets, but painting in response to UpdateRequest (which
should become a paint really) works about as well.
* This assumes it will be used in concert with dyld interposing so it doesn't
actually do any hooking apart from intercepting dlopen/dlsym to substitute any
dynamic access to hooked functions. Otherwise it just fulfills the contract by
calling callbacks and populating original function pointers
* We never should have serialised size_t in the first place so this shouldn't
have happened, but since we want to keep some semblence of best-effort
backwards compatibility, we'll keep the code and just disable it on macOS.
* 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).
baldurk