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.
Set the `opaque` property of the `CAMetalLayer` based on this. In the
past, we did nothing; this actually corresponds to
`VK_COMPOSITE_ALPHA_INHERIT_BIT_KHR`.
Drop support for premultiplied alpha. In Core Animation, this is managed
by the `contents` of the layer. Most layers use a `CGImage` or an
`NSImage` for their contents; the `AlphaInfo` property of a `CGImage`
determines whether or not it uses premultiplied alpha. However,
`CAMetalLayer` doesn't use a `CGImage`, but a custom opaque Core
Foundation object which ostensibly vends images to be displayed by the
layer. I don't know which kind of alpha it uses, but since most
applications render postmultiplied colors I'm going to assume that
premultiplied alpha isn't supported yet.
Add MVKEvent class. MVKEventNative subclass uses native MTLEvent. MVKEventEmulated
subclass uses emulation using CPU blocking and MTLCommandBuffer completion handling.
MVKConfiguration::synchronousQueueSubmits now disabled by default if MTLEvents are not supported.
Document updated use of MVK_ALLOW_METAL_EVENTS and MVK_CONFIG_SYNCHRONOUS_QUEUE_SUBMITS
environment variables and synchronousQueueSubmits config setting, in vk_mvk_moltenvk.h.
MVKDevice check highest queue family index before expanding queue family collection.
MVKVector add bounds check to at(), [], front() & back() functions.
MVKDispatchableVulkanAPIObject::getVkHandle() re-establishes the loader magic number
before returning, in case the loader overwrote it before returning the object.
Update to latest external dependency libraries.
Rename components of VK_INTEL_shader_integer_functions2 to match 1.1.114 Vulkan spec.
Update What's New document.
Remove the descriptor set pool associated with a MVKDescriptorSetLayout when the layout
is destroyed. MVKDescriptorPool and MVKDescriptorSetLayout track each other to tell the
other when it has been destroyed.
This is the instance half of device-group support. This provides the
means to enumerate all known physical device groups, and to create
grouped logical devices.
This provides just enough to satisfy the Vulkan spec. Metal won't
support this fully until Metal 3.0 in the upcoming macOS 10.15.
Advertise linear filtering of linear textures on macOS. I don't see any
reason this was disabled, and I don't know why I didn't turn it on in
PR #391.
Advertise that texel buffers of `VK_FORMAT_A2R10G10B10_UNORM_PACK32` are
supported. This was another oversight of mine in #391.
*Don't* advertise that sRGB formats can be used as vertex attributes.
I'm not sure what that would even mean--I'm guessing that the
implementation performs sRGB->linear conversion on the attribute before
loading it? But we don't do that and neither does Metal.
