Commits 343c7942e1 and
94c74d2c00 moved applying the NonReadable
and Coherent decorations from spirv_compiler_emit_resource_declaration()
to spirv_compiler_build_descriptor_variable(), but unfortunately missed
the non-array path in the latter function.
The missing NonReadable decoration causes segmentation faults in
rasteriser-ordered-views.shader_test (among others) on my Intel SKL GT2
setup in particular.
In the case two uav descriptors are mapped to the same variable, and one is
read from while the other is not, the variable would get the NonReadable
decorator, while being read from later.
The existing code reuses the same SPIR-V variable for all descriptors mapped to
the same Vulkan binding, and applies the NonReadable decoration based on the
VKD3D_SHADER_DESCRIPTOR_INFO_FLAG_UAV_READ only. This potentially causes the
decoration to be applied twice, should two non-read descriptors be mapped to
the same variable, which isn't allowed in SPIR-V, and the validator complains.
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.
This codepath path is currently triggered when transpiling d3dbc shaders
that use vPos (or other of these special registers).
While vPos gets added to the input signature and gets assigned an INPUT
register, the registers in the shader instructions are still of
VKD3DSPR_MISCTYPE type and are not propperly mapped yet. This gives
invalid results.
Some SM1 tests must be set back to "todo" but they only work because, by
coincidence, we are assigning vPos the input register with index 0.
Propper mapping of these registers is still required.