This requires Metal 1.2 (for the `MTLPixelFormatX24_Stencil8` and
`MTLPixelFormatX32_Stencil8` formats). Since Vulkan doesn't actually
have a corresponding format for that, add a new Metal feature for this.
Bump extension spec version.
Just add it to the buffer offset when encoding the command. The reason
for this is that we were using it to index the buffer--which, according
to the C++ spec (on which MSL is based), causes it to be offset by that
many 32-bit words instead of bytes. This caused the buffer to be filled
incorrectly. While Metal does require the offset to be aligned to the
type size (in this case, 4 bytes), Vulkan also requires the offset to
`vkCmdFillBuffer()` to be 4-byte aligned, so this shouldn't run into the
same problem as `vkCmdCopyBuffer()`.
For a copy, the spec requires only that the source and destination
bindings are valid, not that the source has been initialized. If the
source binding hasn't been initialized, then we crash attempting to get
the Metal resources corresponding to the uninitialized descriptors. So,
if the descriptor binding hasn't been initialized, don't try to fetch
Metal resources for it.
Yes, this causes us to accept writes of NULL descriptors (from
templates or otherwise), even though the spec forbids this. I don't know
how to solve this without specializing `writeDescriptorSets()`
specifically for the `VkCopyDescriptorSet` case (thereby duplicating
quite a bit of code). Given the general nature of Vulkan as a framework
that does little to no state validation, I wonder if it's even worth it.
Also, warn only when the texture may be used for a purpose other than as
a color attachment. Fail outright if it won't ever be used for that
purpose, or if the view doesn't cover the entirety of the volume.
The problem is that on 64-bit platforms (i.e. every platform we support)
there will be padding between the `sType` and `pNext` members of any
extensible Vulkan structure, because `sType` is only 4 bytes while
`pNext` is 8 (and needs 8-byte alignment).
Should fix a segfault running `vulkaninfo`.
This won't help using these image views from shaders, but it will help
attaching them to framebuffers.
I've left the warning in `validateImageViewConfig()` in place.
Add MVKExtensionList struct to track supported and enabled Vulkan extensions within MVKInstance & MVKDevice.
Log supported and enabled Vulkan extensions for VkInstance & VkDevice.
Add error handling for descriptor sets & 3D images in VK_KHR_maintenance1 extension.
All header files load mvk_vulkan.h instead of vulkan.h for consistent use of macOS & iOS extensions.
Much of this was already supported, simply by being supported by Metal.
Of course, this support is incomplete: Metal doesn't yet allow you to
create a 2D texture view from a 3D texture.
