This is a proposed API change in 946, which won't make it into this release.
The intent is to allow slightly larger constants to be specified in the updated
vkd3d_shader_parameter1 structure. In particular, this is large enough to pass
4-dimensional integer or float vectors inline, which the proposed clip plane
implementation will use, as well as other Direct3D FFP parameters.
We could also simply add vkd3d_shader_immediate_constant1 as a separate union
member in vkd3d_shader_parameter1, but this API is a bit cleaner and simpler.
As the newly added documentation describes, this reroll serves two purposes:
* to allow shader parameters to be used for any target type (which allows using
parameters for things like Direct3D 8-9 alpha test),
* to allow the union in struct vkd3d_shader_parameter to contain types larger
than 32 bits (by specifying them indirectly through a pointer).
The SPIR-V backend may emit SPIR-V 1.3 if Vulkan 1.1 is available.
Some extensions which provide wave op instructions are available in
SPIR-V 1.0, but these are not sufficient to implement all Shader Model 6
wave op intrinsics. SPIR-V 1.3 has all of the required instructions, but
does not support reading from a quad at a non-constant (but uniform) lane
index, so it may later prove necessary to introduce a Vulkan 1.2
environment.
Type size_t is used in the file without importing any header which
defines it. This only works when the translation unit includes one of
the appropriate headers anyway or when the appropriate header is included
internally by other standard C headers; none of those strategies should
be relied upon.
d3dcompiler and d3dx9 versions before 42 don't emit this error; this will be
necessary to emulate that behaviour.
Other warnings exist that are introduced in different d3dcompiler versions,
although there are not very many distinct HLSL warnings to begin with.
We could of course group all these together under a single compiler option, but
I find that using separate top-level options is unilaterally friendlier to an
API consumer, and simpler to implement as well. It also in some sense maps
conceptually to e.g. "-Wno-implicit-conversion".
