The hlsl_ir_compile node is introduced to represent the "compile"
syntax, and later the CompileShader() and ConstructGSWithSO()
constructs.
It basically represents a function call that remembers its arguments
using hlsl_srcs and keeps its own instruction block, which is discarded
when working on non-effect shaders.
For shader compilations it can be asserted that args_count is 1, and
that this argument (and the last node in hlsl_ir_effect_call.instrs)
is a regular hlsl_ir_call pointing to the declaration of the function
to be compiled.
This node type will be deleted once the hlsl->vsir->d3dbc translation is
complete. For now 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.
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.
This would allow us to use vkd3d-utils directly in Wine [with the exception of
D3D_COMPILE_STANDARD_FILE_INCLUDE, but we can simply pass the ID3DInclude object
to D3DCompile2VKD3D().]
This way the same shader is always dumped to the same path and when
launching the same program over and over we avoid both creating new
copies of the same file each time and overwriting different dumped
shaders.
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.
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.