Default value initializers behave differently than regular initializers
for matrices on SM4 profiles.
While regular initializers assign the rhs elements in reading-order
(completing one row at the time), default initializers assing the rhs
elements in Chinese reading-order (completing one column at the time).
So after lowering a default value to a constant, the index of the
component to which this default value is stored is computed to meet
this expectation. This can be done because the default values.
For reference, compiling this shader:
row_major int2x3 m = {1, 2, 3, 4, 5, 6};
float4 main() : sv_target
{
return float4(m[0][0], 99, 99, 99);
}
gives the following buffer definition:
// cbuffer $Globals
// {
//
// row_major int2x3 m; // Offset: 0 Size: 28
// = 0x00000001 0x00000003 0x00000005 0x00000000
// 0x00000002 0x00000004 0x00000006
//
// }
Given that the matrix is column-major, m's default value is actually
{{1, 3, 5}, {2, 4, 6}}, unlike the {{1, 2, 3}, {4, 5, 6}} one would
expect in a regular initializer.
SM1 profiles assign the elements in regular reading order.
It is hard to initialize default values on add_assignment() and calling
add_assignment() for initializers is not really necessary: the only
thing we need from it the implicit cast.
destroy_block() is called with a NULL block from:
* create_loop, through the loop rules for while and do-while loops.
* The selection_statement rule, in the case $6.else_block is NULL.
* free_parse_initializer.
vkd3d_string_buffer_cleanup() doesn't do the same as
hlsl_release_string_buffer(). The former only frees the char array
inside the string buffer and not the string buffer itself.
The extra argument is not very easy to intuit. Since all we're trying to do here is check whether the type is a struct with object components in it, write that out explicitly.
d3dcompiler and d3dx9 versions before 42 don't emit this error; this will be
necessary to emulate that behaviour.
Other warnings exist that are introduced in different d3dcompiler versions,
although there are not very many distinct HLSL warnings to begin with.
We could of course group all these together under a single compiler option, but
I find that using separate top-level options is unilaterally friendlier to an
API consumer, and simpler to implement as well. It also in some sense maps
conceptually to e.g. "-Wno-implicit-conversion".
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.
Native does not always do this. For example, functions whose parameters are
float and float1 always result in an "ambiguous function call" error.
This does not fix any tests, because the relevant tests previously (incorrectly)
succeeded, and now fail with:
E5017: Aborting due to not yet implemented feature: Prioritize between multiple compatible function overloads.
when they should simply fail.
The choice to store them in an rbtree was made early on. It does not seem likely
that HLSL programs would define many overloads for any of their functions, but I
suspect the idea was rather that intrinsics would be defined as plain
hlsl_ir_function_decl structures [cf. 447463e590]
and that some intrinsics that could operate on any type would therefore need
many overrides.
This is not how we deal with intrinsics, however. When the first intrinsics were
implemented I made the choice disregard this intended design, and instead match
and convert their types manually, in C. Nothing that has happened in the time
since has led me to question that choice, and in fact, the flexibility with
which we must accommodate functions has led me to believe that matching in this
way was definitely the right choice. The main other designs I see would have
been:
* define each intrinsic variant separately using existing HLSL types. Besides
efficiency concerns (i.e. this would take more space in memory, and would take
longer to generate each variant), the normal type-matching rules don't really
apply to intrinsics.
[For example: elementwise intrinsics like abs() return the same type as the
input, including preserving the distinction between float and float1. It is
legal to define separate HLSL overloads taking float and float1, but trying to
invoke these functions yields an "ambiguous function call" error.]
* introduce new (semi-)generic types. This is far more code and ends up acting
like our current scheme (with helpers) in a slightly more complex form.
So I think we can go ahead and rip out this vestige of the original design for
intrinsics.
As for why to change it: rbtrees are simply more complex to deal with, and it
seems unlikely to me that the difference is going to matter. I do not expect any
program to define large quantities of intrinsics; linked list search should be
good enough.
