Null the `sampler` field of the stored `VkDescriptorImageInfo` if the
descriptor uses an immutable sampler. That way, we won't try to
double-free a sampler.
Retain immutable samplers when the set is created. Release them when the
set is destroyed.
In which I am proved wrong again. While Metal indeed won't assert if the
pixel formats don't match, the results of attempting such a copy are...
mixed, to say the least. Sometimes, nothing is copied at all. Other
times, pixels are copied in weird ways that don't seem to conform at all
to expectation. (This is most apparent in the output of the CTS's image
copying tests.) It's best, then, to ensure that the source and
destination have the same format.
Unfortunately, in the process of writing this, my fears regarding not
being able to make uncompressed views of compressed images were
confirmed. So we can't do this for compressed images.
In the past, this function just used the passed-in binding number to
index into the array of bindings. When the binding numbers and the
indices of the array matched up, this worked really well.
When they didn't, it broke spectacularly.
So now we keep track of which binding numbers map to which elements in
the array. That way, we don't have to assume that the array indices and
the binding numbers will match up.
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.
