I ran the compilation of ~1000 DXBC-TPF shaders randomly taken from
my collection and measured the performance using callgrind and the
kcachegrind "cycle count" estimation.
BEFORE:
* 1,846,641,596 cycles
* 1,845,635,336 cycles
* 1,841,335,225 cycles
AFTER:
* 1,764,035,136 cycles
* 1,767,948,767 cycles
* 1,773,927,734 cycles
So callgrind would estimate a 3.6% improvement at least.
The counterpoint is that the caller might get an allocation that
is potentially bigger than necessary. I would expect that allocation
to be rather short-lived anyway, so that's probably not a problem.
Avoid overflowing the (Wine) debug log buffer when output lines are too
long, and keep spirv-text output more legible. The output is still valid
SPIR-V asm, as the assembler does not care for which kind of whitespace
is used.
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.
