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.
