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.
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.
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.
After compiling and linking with '-fsanitize=undefined' the following
error pops up in many tests:
vkd3d_shader_main.c:2024:12: runtime error: member access within null pointer of type 'struct vkd3d_shader_param_node'
This happens in the scenario where shader_param_allocator_get() gets
called with 'count = 0' but no allocation has been made yet, so
allocator->current is NULL.
In this case the result of the function, given by:
params = &allocator->current->param[allocator->index * allocator->stride];
is an invalid non-NULL pointer.
Functions like shader_sm4_read_instruction() may call
vsir_program_get_src_params() or vsir_program_get_dst_params() with 0
counts for various DCL_ instructions, as well as things like NOP,
ELSE, and SYNC.
We could avoid calling the functions in question with 0 counts, but it
doesn't seem worth the effort.
Alternatively, we could just return NULL on 'count == 0', but this is
also complicated because NULL is interpreted as a memory allocation
failure on the callers.
So we force allocation of the next node even if 'count = 0' when
allocator->current is NULL.
track_object_components_usage() had to be improved to also
register derefs on resource stores.
It was not doing it because it assumed that for every resource store
there was a resource load already, which was true, before calling DCE.
