The goal is to make a requirement for VSIR that signature element
masks are always contiguous. The SPIR-V backend already implicitly
makes that assumption, since it just consider the LSB and popcount
of the mask.
For example, consider this HLSL pixel shader:
float4 main(float4 color : COLOR) : SV_Target
{
return float4(color.x, 10.0f, 11.0f, color.w);
}
Currently the parser describes the input signature element
corresponding to semantic COLOR as having mask .xw, which is
sensible. However, the SPIR-V parser will interpret that as
a mask starting at x and with popcount 2, and assuming it is
contiguous it will implicitly act as if it were .xy. This is
not correct, because the wrong component will be loaded from
the vertex stage.
Slightly simplifies descriptor write addressing, and makes layouts
essentially the same as array layouts, differing only in the binding
details, and therefore easier to understand. This also simplifies the
addition of storage buffer bindings, which can all be added onto the end.
Allows descriptor set layouts to be created after all bindings are
mapped. This is less complex and fragile than the current scheme, and in
a future patch it will support separating descriptor types into different
sets. Descriptors on virtual heaps are currently allocated from pools
which contain an equal number of each descriptor type used by vkd3d, and
this can waste a significant amount of device memory.
On virtual heaps, SRV/UAV unbounded ranges are implemented using two
descriptor sets, one for buffers and another for textures, and this case
should be tested.
Here, we implement single inheritance by inserting a field at the
beginning of the derived struct with name "$super".
For the following struct declarations
struct a
{
float4 aa;
float4 bb;
};
struct b : a
{
float4 cc;
};
struct c : b
{
float4 bb;
};
this commit generates the following:
struct a
{
float4 aa;
float4 bb;
};
struct b
{
struct a $super;
float4 cc;
};
struct c
{
struct b $super;
float4 bb;
};
Similarly to the already done split from
HLSL IR -> d3dbc
to
HLSL IR -> vsir -> d3bc
we now start splitting the
HLSL IR -> tpf
translation into
HLSL IR -> vsir -> tpf
So hlsl_sm4_write is split into two functions, sm4_generate_vsir() and
tpf_compile().
This translation should be completed once tpf_compile() no longer needs
the hlsl_ctx and entry_func parameters.
This allows the Vulkan runner to execute in environments which do
not support geometry shaders, most notably MoltenVK. In particular,
that enables SM<4 shaders to run in such environments
Specifically we should write the sysval semantic as an instruction idx
for the following instructions:
VKD3D_SM4_OP_DCL_INPUT_SGV
VKD3D_SM4_OP_DCL_INPUT_PS_SGV
VKD3D_SM4_OP_DCL_INPUT_SIV
VKD3D_SM4_OP_DCL_INPUT_PS_SIV
VKD3D_SM4_OP_DCL_OUTPUT_SIV
and not the following ones:
VKD3D_SM4_OP_DCL_INPUT
VKD3D_SM4_OP_DCL_PS_INPUT
VKD3D_SM4_OP_DCL_OUTPUT
Which is consistent with what we do when reading these instructions in
the following functions:
shader_sm4_read_declaration_register_semantic()
shader_sm4_read_dcl_input_ps_siv()
and
shader_sm4_read_dcl_input_ps()
shader_sm4_read_declaration_dst()
for the non-SGV and non-SIV cases.
Note that the non-SGV and non-SIV instructions don't need/use this
extra information because they rely on the dst register type and index.
I suggest to introduce this change because the here replaced check is
brittle, and we might be omitting the sysval semantic in some cases.
