Since we created them using the device. Otherwise, the device won't know
that it needs to stop tracking them for the purposes of generating
memory barriers.
In Metal 1.2 on Mac, the `MTLSamplerAddressModeClampToBorderColor`
address mode was added. This mode actually lets clients specify the
border color, instead of hardcoding it to black (opaque without alpha,
transparent with alpha). Use this new mode instead of
`MTLSamplerAddressModeClampToZero` when possible.
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.
For each GPU, log MSL version and updated list of feature sets.
Add SPIRVToMSLConverterOptions::printMSLVersion() function.
Update to latest SPIRV-Cross version.
Update MoltenVK version to 1.0.29.
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.
