1D read() is specified to support a level/lod parameter. The MSL
specification claims it needs to be 0 because "mipmaps are not supported
for 1D textures", but that restriction isn't documented for the
"mipmapLevelCount" property of MTLTextureDescriptor. Other APIs do
supported mipmapped 1D textures. Multi-sample textures aren't supported
by msl_ld(), so we don't need to worry about them.
The cube variants are simply disallowed in Direct3D, and currently
mishandled by msl_ld(). It's less clear whether multi-sample fetches
should be allowed, and how they're supposed to behave if they are,
although typically the "ld2dms" instruction would be used for those.
They're not supported on the MSL side either way.
Currently a descriptor set is represented with a structure
whose fields are the various descriptors that the shader is
going to use, each of them qualified with its type. This model
doesn't match very well what happens with D3D12 and with Vulkan
and descriptor indexing and mutable descriptors, where many
descriptor of different types can overlap, and only at shader
runtime it is decided which of them must be used.
Therefore with this patch a descriptor is represented as a
structure whose fields carry no intrinsic typing information,
but are reinterpreted according to the shader behavior on
each access. For the moment there is just one field, but more
will be added to account for fancier descriptor types and
to workaround Metal limitations.
When completed, this design will be similar in spirit to what
the Metal shader converter does, with little technical
differences.
This choice has a couple of drawbacks:
1. shader debugging with Xcode is less comfortable, because
the shader doesn't carry static descriptor typing
information and Xcode is therefore less able to provide
useful context;
2. it requires tier 2 argument buffer support and macOS
version >= 13, which includes guarantees on the runtime
layout for descriptors.
Supporting descriptor indexing and mutable descriptors is
considered to be worthy of those drawbacks, though, is
effectively required by many applications and appears to be
the first goal we should aim for. If needed, in the future
we might also add support for older hardware, at least for
shaders that do not make use of advanced features.
Like we do for GLSL; there's no reason to abort compilation here. Note
that this also avoids leaking "gen->buffer" and "gen->string_buffers" on
the error path.
The previous names "not normalised" and "fully normalised" have meanings
which are likely to change with time. OTOH including a description of the
normalisation level in the enumerant seems excessive. Relating
normalisation levels to shader model versions might be a reasonable
compromise.
