This node type will be deleted (again) once the hlsl->vsir->tpf
translation is complete. It serves the purpose of allowing to keep
both real hlsl_ir_nodes and vsir_instructions in the hlsl_block,
until all the former can be translated into the latter.
Currently the mutable descriptor set is repeated many times in the
pipeline layout in order to cover the indices for all the
descriptor types that would be present if mutable descriptors were
not used. This is useless and wasteful, but was necessary before
the descriptor sets backing the SRV-UAV-CBV heap were moved at the
end of the allocation table because descriptor set indices are
currently a compile-time constant in many places.
Now this is not needed any more and we can just avoid putting
many copies of the mutable descriptor set in the pipeline layout,
making it easier to meet Vulkan implementation limits.
So that when mutable descriptors are in use we can avoid putting
the other descriptor sets backing the SRV-UAV-CBV descriptor heap
in the pipeline layout altogether.
So we avoid hardcoding that it is number zero. There are two
goals here: first making the code easier to understand and
second allow reshuffling the descriptor set allocation in a
later commit.
Most Vulkan drivers are happy to compile a pipeline with interstage
interface mismatches, even if the pipeline will be broken. Metal,
and therefore MoltenVK, instead doesn't and errors out immediately.
This is required to properly optimize signatures, because these
semantics must be alligned while being packed:
- Array elements.
- The first fields of structs.
- Major vectors of a matrix.
For now this has no effect since semantics are allocated with reg_size
4, but will have effect when optimizing interstage signatures.
The generated pixel shader input signature must be consistent with the
generated vertex shader output signature for the same data type.
Since the interpolation mode affects allocation order, the allocator
needs to know the modifiers for both input and output signature elements.
The descriptor heap implementation is a rather central behavior element
in vkd3d, so it's useful to have all the relevant information logged
in a single place.
Vulkan doesn't mandate whether sampling exactly in the middle between
two levels should resolve to one or the other, while D3D specifies
that it should result into sampling the higher level. llvmpipe
happens to choose the lower one instead, at least in some cases.
