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).
CASTs from floats to integers are implemented as mere MOVs. These often,
but not always, end up moving the value from one register to the same
register.
This patch avoids writing the MOV instructions if they have no effect.
The idea is to start splitting the
HLSL IR -> d3dbc
translation into
HLSL IR -> vsir -> d3dbc
So hlsl_sm1_write is split into two functions, sm1_generate_vsir()
which should handle the first part and d3dbc_compile() which should
handle the second part.
This translation should be completed once the hlsl_ctx and entry_func
are no longer used in d3dbc_compile().
For tpf shader this would previously be a pointer into the original
shader code, and for d3dbc shaders we'd use static strings.
Unfortunately the dxil parser creates shader signatures where these
are pointers to metadata strings, and those go away when we call
sm6_parser_cleanup().
We could conceivably store a flag in the shader signature to indicate
whether shader_signature_cleanup()/vkd3d_shader_free_shader_signature()
should free the "semantic_name" field. It'd be a little ugly, and seems
unlikely to be worth it, but I'd be willing to be convinced.
According to the documentation, if_comp is available from 2_x pixel
and vertex shaders and, unlike "if bool" it doesn't expect a constant
boolean register (from the input signature), so:
if_neq cond -cond
seems like a convenient way to write these, for profiles above 2.0.
We want the base type to stop being a property of all types, and to stop using
the same enumeration for objects and numeric types. The backend should do the
work of translation; we want a more sensible and convenient representation for
the compiler itself.
As the diffstat shows, HLSL_CLASS_OBJECT does not really have much in common.
Resource types (TEXTURE, SAMPLER, UAV) sometimes behave similarly to each other,
but do not generally behave similarly to effect-specific types (string, shader,
state, view). Most consumers of HLSL_CLASS_OBJECT subsequently check the base
type anyway.
Hence we want to replace HLSL_TYPE_* with individual classes for object types.
As a first step, change the last few places that only check HLSL_CLASS_OBJECT.
I realized that it is better to lower casts to int to FLOOR+REINTERPET
instead of appending a FLOOR to all casts to int and assuming that this
is the case for all of them in d3dbc.c.
This in case we introduce new passes in the future that add casts that
we forget to lower, after the lower_casts_to_bool pass.
For temporary registers, SM1-SM3 integer types are internally
represented as floating point, so, in order to perform a cast
from ints to floats we need a mere MOV.
For constant integer registers "iN" there is no operation for casting
from a floating point register to them. For address registers "aN", and
the loop counting register "aL", vertex shaders have the "mova" operation
but we haven't used these registers in any way yet.
We probably would want to introduce these as synthetic variables
allocated in a special register set. In that case we have to remember to
use MOVA instead of MOV in the store operations, but they shouldn't be src
or dst of CAST operations.
Regarding constant integer registers, in some shaders, constants are
expected to be received formatted as an integer, such as:
int m;
float4 main() : sv_target
{
float4 res = {0, 0, 0, 0};
for (int k = 0; k < m; ++k)
res += k;
return res;
}
which compiles as:
// Registers:
//
// Name Reg Size
// ------------ ----- ----
// m i0 1
//
ps_3_0
def c0, 0, 1, 0, 0
mov r0, c0.x
mov r1.x, c0.x
rep i0
add r0, r0, r1.x
add r1.x, r1.x, c0.y
endrep
mov oC0, r0
but this only happens if the integer constant is used directly in an
instruction that needs it, and as I said there is no instruction that
allows converting them to a float representation.
Notice how a more complex shader, that performs operations with this
integer variable "m":
int m;
float4 main() : sv_target
{
float4 res = {0, 0, 0, 0};
for (int k = 0; k < m * m; ++k)
res += k;
return res;
}
gives the following output:
// Registers:
//
// Name Reg Size
// ------------ ----- ----
// m c0 1
//
ps_3_0
def c1, 0, 0, 1, 0
defi i0, 255, 0, 0, 0
mul r0.x, c0.x, c0.x
mov r1, c1.y
mov r0.y, c1.y
rep i0
mov r0.z, r0.x
break_ge r0.y, r0.z
add r1, r0.y, r1
add r0.y, r0.y, c1.z
endrep
mov oC0, r1
Meaning that the uniform "m" is just stored as a floating point in
"c0", the constant integer register "i0" is just set to 255 (hoping
it is a high enough value) using "defi", and the "break_ge"
involving c0 is used to break from the loop.
We could potentially use this approach to implement loops from SM3
without expecting the variables being received as constant integer
registers.
According to the D3D documentation, for SM1-SM3 constant integer
registers are only used by the 'loop' and 'rep' instructions.
These can be disassembled by D3DDisassemble() just fine, and perhaps
more importantly, shader model 1 vertex shaders do not require dcl_
instructions in Direct3D 8.
Currently, HLSL_RESOURCE_SAMPLE_LOD is not implemented for d3dbc,
but we are incorrectly writting a texld instruction to handle it.
This causes SM1 tests with the vulkan backend (in following patches)
to fail if VKD3D_SHADER_CONFIG="force_validation" is enabled.
For now a fixme is emited in these cases.
This was broken by commit e390bc35e2c9b0a2110370f916033eea2366317e; that
commit fixed the source count for these instructions, but didn't adjust
shader_sm1_skip_opcode(). Note that this only affects shader model 1;
later versions have a token count embedded in the initial opcode token.
This should have no effect, since in SM1 the allocation size is the
same as the bind count because there are no texture registers.
It is just done for consistency.
We have to distinguish between the "bind count" and the "allocation size"
of variables.
The "allocation size" affects the starting register id for the resource to
be allocated next, while the "bind count" is determined by the last field
actually used. The former may be larger than the latter.
What we are currently calling hlsl_reg.bind_count is actually the
"allocation size", so a rename is in order.
The real "bind count", which will be introduced in following patches,
is important because it is what should be shown in the RDEF table and
some resource allocation rules depend on it.
For instance, for this shader:
texture2D texs[3];
texture2D tex;
float4 main() : sv_target
{
return texs[0].Load(int3(0, 0, 0)) + tex.Load(int3(0, 0, 0));
}
the variable "texs" has a "bind count" of 1, but an "allocation size" of
3:
// Resource Bindings:
//
// Name Type Format Dim HLSL Bind Count
// ------------------------------ ---------- ------- ----------- -------------- ------
// texs texture float4 2d t0 1
// tex texture float4 2d t3 1
