* This doesn't translate well to metalsl and is in general not very useful - we
were only doing it to avoid packing issues which in some cases are moot
anyway. E.g. the histogram buffer doesn't have to be std140 and packed like an
array of vectors, it can be std430 and packed like an array of uints.
* We implement this with dyld interposing. This means we must decide at compile
time which functions to be hooked - in particular we require a manually
curated list of functions that are actually exposed in the latest macOS GL
version. Fortunately this is not a moving target anymore so this list should
now be complete.
* The hooking is not complete:
- It doesn't do full context tracking, just context create and make current
- There's no drawable/window querying or tracking, so windows aren't properly processed and their size is wrong
* Also note that this does not support the replay side yet (CGLPlatform is still
mostly stubs) and capturing actually still crashes.
* 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.
baldurk