Otherwise we may get a failing
"hlsl_types_are_equal(arg1->data_type, arg2->data_type)"
assertion on hlsl_new_binary_expr() when creating the MUL.
This happens in the test introducing in the following patch:
int a, b, c;
void main(out float4 res : COLOR1, in float4 pos : position, out float4 out_pos : sv_position)
{
out_pos = pos;
res = a ? b/1000.0 : c/1000.0;
}
They are substantially different from any other register type, so
it makes sense to have them stand out. Also, they help segmenting
visually the code into blocks, because labels are usually found
either at the beginning or at the end of a block.
The other cases are similar and common code can be refactored.
Ideally the HLSL parser will eventually fit the same model, but that
will require more extensive work.
There is no way to tell in spirv_compiler_emit_load_reg() if the write
mask is 64-bit. All loads are 32-bit except for IMMCONST64 and SSA, and
the latter ignores the mask, so the only issue lies with IMMCONST64.
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.
libs/vkd3d-shader/hlsl.c: In function ‘declare_predefined_types’:
libs/vkd3d-shader/hlsl.c:3408:10: warning: initialization discards ‘const’ qualifier from pointer target type [-Wdiscarded-qualifiers]
{"technique", 9},
^~~~~~~~~~~
...
programs/vkd3d-compiler/main.c: In function ‘parse_formatting’:
programs/vkd3d-compiler/main.c:303:10: warning: initialization discards ‘const’ qualifier from pointer target type [-Wdiscarded-qualifiers]
{"colour", VKD3D_SHADER_COMPILE_OPTION_FORMATTING_COLOUR},
^~~~~~~~
...
macOS tigetstr() takes a non-const char *, so account for that as well.
Tests have already been implemented in 92044d5e; this commit also reduces
the scope of some of the todos (because now they're implemented!).
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=55154
Co-authored-by: Giovanni Mascellani <gmascellani@codeweavers.com>
These may happen when storing to structured buffers, and we are not
handling them properly yet. The included test reaches unreacheable code
before this patch.
Storing to buffers is complicated since we need to split the index
chain in two paths:
- The path within the variable where the resource is.
- The subpath to the part of the resource element that is being stored
to.
For now, we will emit a fixme when the index chain in the lhs is not a
direct resource access.
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.
