All that is required is that we can either read the format
(`TRANSFER_SRC`) or sample from it (`SAMPLED_IMAGE`). Every image format
that Metal supports supports those two features.
This marks the depth/stencil formats as able to be the source of a
blit. The spec requires in particular that `D16_UNORM` and `D32_SFLOAT`
support that.
Compressed formats only support reading and filtering. They also can't
be used to create linear textures, so they can't be used for buffer
views, either.
Use `MTLVertexFormatChar`, `UChar`, `Short`, `UShort`, and `Half` when
available. Add `MTLVertexFormatUChar4Normalized_BGRA` for
`VK_FORMAT_B8G8R8A8_UNORM`.
These are only available on Metal 2.0 (iOS 11, macOS 10.13) and up, so
this adds what MoltenVK was using before as a fallback, similar to how
some `MTLPixelFormat`s have substitutes.
Setting that usage bit on a non-renderable format, especially a
compressed one, will cause Metal to crash. (And I mean crash, without
raising an assertion failure.)
Because they're packed formats, they correspond to
`MTLPixelFormatRGBA8`. In fact, these formats would only be distinct on
a big endian system, and no current Apple hardware is big endian
anymore.
If the device memory is subsequently bound to a `VkBuffer` after it has
been mapped, the heap memory will be freed, leaving dangling pointers in
the client. Instead, create an `MTLBuffer` right away--it is *device*
memory after all--and use its memory.
Another option might be to use `-[MTLDevice
newBufferWithBytesNoCopy:length:options:deallocator:]`, but that
requires that the entire allocation come from a single contiguous
virtual memory mapping, a requirement that is not necessarily satisfied
by `malloc(3)` memory.
Fixes#377.
Metal always gives the components in little endian order, while Vulkan
always lists them in big endian order. This also brings us more in line
with the spec, which says that the formats
`VK_FORMAT_R5G6B5_UNORM_PACK16` and `VK_FORMAT_A1R5G5B5_UNORM_PACK16`
must be supported.
Fixes#353.
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.
