100d7aa543
Largely minimal for now. Much of it, particularly most of the interactions with `VK_KHR_swapchain`, was already implemented previously. The only interesting bits are the `vkCmdDispatchBase()` command, and the ability to create arbitrary swapchain images and bind them to swapchain memory, which requires the use of the previously implemented `VK_KHR_bind_memory2` extension. Most everything else can be safely ignored for now. Non-zero dispatch bases use the compute stage-input region to pass the dispatch base group to the shader, which must manually adjust the `WorkgroupId` and `GlobalInvocationId` builtins, since Metal does not do this for us. I have tested that this approach works well--at least, well enough to pass the CTS. Because of the ability to bind arbitrary images to swapchain memory, I've sucked the guts out of `MVKSwapchainImage` and into `MVKSwapchain` itself. Availability and drawable management is now performed by the swapchain object. `MVKSwapchainImage` is now just a specialized kind of image, created when requested with a `VkImageCreateSwapchainInfoKHR` structure. Update SPIRV-Cross so we can support the `vkCmdDispatchBase()` command. One more step towards Vulkan 1.1.
2 lines
41 B
Plaintext
2 lines
41 B
Plaintext
4ce04480ec5469fe7ebbdd66c3016090a704d81b
|