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.
Some clients (DXVK primarily) always set all eight color attachments,
even if they are unused. Metal will treat them as though they weren't
specified at all. If none are used, then Metal won't know how big to
make the render area, and the pipeline will fail validation. We have to
treat this case the same as if no attachments were given.
Allow linear images to use host-coherent memory. But map its internal
storage mode to `MTLStorageModeManaged`, so we know that we need to keep
it in sync manually.
Enabling bitcode in Xcode only adds the -fembed-bitcode-marker flag, which doesn't actually create bitcode. The Archive action transforms that flag to -fembed-bitcode which actually creates the bitcode. Adding the User-Defined Setting BITCODE_GENERATION_MODE=bitcode forces bitcode to be created without archiving.
Support creation of static library and build framework and dynamic library from it.
Add Makefile to better support command line or script building integration.
Update demos to each use one of framework, static library, and dynamic library.
Refactor and rename the build scripts.
Refactor and rename the Xcode Schemes.
Update build and runtime documentation.
Update What's New document.
MVKPipelineLayout set auxiliary buffer MSL index relative to already-calculated
push constant buffer MSL index.
MVKPipeline destructor release auxiliary buffer MTLBuffer instance.
Nudge MVK_VERSION_PATCH.
Set `MTLPixelFormatRG11B10Float` for `VK_FORMAT_B10G11R11_UFLOAT_PACK32`
and `MTLPixelFormatRGB9E5Float` for `VK_FORMAT_E5B9R9G9_UFLOAT_PACK32`.
This should fix the rest of #302.
The swizzles are passed to shaders that need them using an "auxiliary
buffer", for which there must be room in the function argument table.
Code is inserted into the shaders to swizzle reads from sampled
textures--per the Vulkan spec, component mappings must only be applied
to sampled images.
Update SPIRV-Cross to pull in some fixes for handling swizzled image
data. Bump MoltenVK version.
The docs for the `MTLBlitCommandEncoder`'s `copyFromTexture:...` method
state that the source and destination textures must have the same
format.
This was true when it was written in the iOS 8 timeframe for Metal 1.0.
But, I suspect it was changed in Metal 1.1 when support was added for
texture views of differing formats. Like with texture views, the two
formats now need only be compatible. This is the same behavior that
Vulkan prescribes.
Some clients always set blend state for all eight attachments, even if
the attachments are unused. Since the attachments are unused, the
expectation is that the corresponding blend states won't matter. But in
Metal, there's no way to tell if an attachment won't be used. So, if you
enable blending on an unused attachment, its pixel format will be
`MTLPixelFormatInvalid`, which doesn't support blending; Metal will
assert on this.
Use `MTLVertexFormatUInt1010102Normalized`. This is the unsigned
equivalent to the signed `MTLVertexFormatInt1010102Normalized`, which we
already use for `VK_FORMAT_A2B10G10R10_SNORM_PACKED`.
According to the Vulkan spec, linear-tiled images *may* not be supported
unless certain restrictions are satisfied. That means that
implementations may support features--or restrictions--above and beyond
the restrictions given in the Vulkan spec.
Metal places these limitations on linear textures:
* They must be 2D.
* They may only have one mip level.
* They may only have one array layer.
* They may not be multisampled--sample count must be one.
* On macOS, they may not be used as attachments.
* They may not be depth/stencil textures.
* They may not have a compressed format.
Have `vkGetPhysicalDeviceFormatProperties()` and
`vkGetPhysicalDeviceImageFormatProperties()` return results consistent
with these constraints. Also, allow creation of linear textures with
usages other than `VK_IMAGE_USAGE_TRANSFER_{SRC,DST}_BIT`.
Otherwise, if the resource is destroyed first (which it almost always
will be), then when the `VkDeviceMemory` is freed, it will access a
freed resource, at which point it will then proceed to fandango on core.
