Add mvkMTLPixelFormatLinearTextureAlignment() function.
Add MVKDevice::getVkFormatTexelBufferAlignment() and use for Linear image memory alignment.
For non-linear image memory alignment, use mvkVkFormatBytesPerBlock().
Rename MVKDevice::mtlPixelFormatFromVkFormat() to getMTLPixelFormatFromVkFormat().
This extension allows multiple device memory objects to be bound in one
call. It also provides extensible versions of the memory binding calls.
It is a prerequisite for both the `VK_KHR_device_group` and
`VK_KHR_sampler_ycbcr_conversion` extensions.
The `VK_IMAGE_CREATE_ALIAS_BIT`, also added in this extension, would be
more interesting if we used `MTLHeap` objects for device memory, since
that would determine whether or not we would make images aliasable.
This allows clients to create views of a swapchain image with a
different format, just like a regular image created with the
`VK_IMAGE_CREATE_MUTABLE_FORMAT_BIT` set. This extension also supports
the additional features provided by `VK_KHR_maintenance2` and
`VK_KHR_image_format_list` for swapchain images.
We... admittedly don't do much with any of this. There wasn't really
anything in Metal stopping clients from doing this to begin with. This
change does, however, set the `MUTABLE_FORMAT` and `EXTENDED_USAGE`
image bits on any swapchain created with the new
`VK_SWAPCHAIN_CREATE_MUTABLE_FORMAT_BIT_KHR`.
Only the `shaderFloat16` feature is supported for now. The `shaderInt8`
feature may require additional work on SPIRV-Cross.
Update Vulkan-Headers to 1.1.95 to pull in the definitions for this new
extension.
Based on a patch by Stefan Dösinger.
Metal cannot do signedness conversion on vertex attributes, and for good
reason. Putting a `uint4` into an `int4`, or a `char4` into a `uint4`,
would lose those values that are outside the range of the target type.
But putting a `uchar4` into a `short4` or an `int4`, or a `ushort4` into
an `int4`, should work. In that case, force the signedness in the shader
to match the declared type of the host.
Update SPIRV-Cross to pull in the corresponding change. Bump MoltenVK
version.
They were using `Int32`/`UInt32`, which is fine I guess, but wasteful in
the blit/clear shaders. This will be more important later, when I work
around a bug in Metal.
Requires Metal 2.1 on Mac. Not supported at all on iOS.
I'm split as to whether or not to have
`mvkMTLTextureTypeFromVkImageType()` return
`MTLTextureType2DMultisampleArray`.
SPIRV-Cross already handles this. This extension was promoted to core in
Vulkan 1.1, and is a requirement for multiple other extensions, some of
which were also promoted to core in 1.1.
Update to latest dependency libraries for Vulkan SDK 1.1.92.
Generate Hologram demo dispatch files in fetchDependencies and remove them from git.
Update MoltenVK version to 1.0.27.
Update What's New document.
This exposes `MTLStorageTypeMemoryless` on iOS as lazily allocated
device-private memory. The semantics of lazily allocated memory are
exactly those of memoryless storage: namely, it can only be used with
images, and only those used as transient attachments. This enables
Vulkan clients to take advantage of this new storage mode starting on
iOS 10.
Fixes to create_dylib.sh to cleanup bitcode and architecture support.
Update to latest SPIRV-Cross version.
Update MoltenVK version to 1.0.26.
Update Xcode projects to Xcode 10.1.
Update What's New document.
Put it into a base class, MVKRefCountedDeviceObject. The intent is that
MVKImageView, MVKSampler, MVKBuffer, and MVKBufferView will all derive
from this and get reference-counting semantics, which will reduce all
the horrible duplication of code from the original change, and fix the
race condition as well.
According to the Vulkan spec:
"Entries that are not used by a pipeline can have uninitialized
descriptors or _descriptors of resources that have been destroyed_,
and executing a draw or dispatch with such a descriptor set bound
does not cause undefined behavior." [emphasis added]
But, in the current implementation, if a resource is destroyed, and a
descriptor set to which it was bound is subsequently bound to a
pipeline, then the now-freed object for the destroyed resource will be
passed to Metal, which almost always results in a segfault. To avoid
this, resources now keep track of descriptors to which they are bound,
and tell them to forget the resources when they are destroyed.
Conversely, if a descriptor set is destroyed before its bound resources,
the resources must now not notify the destroyed set. In this case, the
descriptor binding now tells the resource to forget the descriptor.
There is a race condition present if two threads attempt to destroy a
descriptor set and a resource at the same time. I've tried to mitigate
this with locking, but it won't help in the case where the resource
destruction happens first--the descriptor set will subsequently attempt
to modify a freed object. I don't know how to fix this.
