On 1/3/22 11:00, Francisco Casas wrote:
December 30, 2021 2:55 PM, "Zebediah Figura (she/her)" zfigura@codeweavers.com wrote:
On 12/29/21 08:51, Francisco Casas wrote:
The new function initialize_var_recursive() "pops" arguments from the parse_variable_def initializer to initialize the members of var for both struct and array initialization recursively. initializer_i is used to keep track of the index of the next input parameter to read. This approach should scale well for nested arrays and structs.
I don't think recursion should be necessary at all.
Rather, since the "offset" in hlsl_deref is designed not to care about the underlying division of the HLSL struct or array type, we should be able to do something as simple as iterating over initializer elements and sequentially storing them to the variable. In that case we don't even need to care about the type class, and can even use this code for numeric types.
I understand that hlsl_deref doesn't care about the division of the struct, however, I still think recursion is necessary.
So far, an hlsl_type is a recursive data type: It could be an HLSL_CLASS_STRUCT that contains a HLSL_CLASS_ARRAY field, that contains HLSL_CLASS_STRUCT elements, and so on (not necessarily switching between arrays and structs). As in:
struct aaa { struct { int2 ccc; float4 ddd; } bbbs[3]; };
float4 PSMain() : SV_TARGET { struct aaa foo = {11,12,13,14,15,16,21,22,23,24,25,26,31,32,33,34,35,36}; return foo.bbbs[1].ddd; // 23.0, 24.0, 25.0, 26.0 }
Hrm, I see the problem; I was forgetting about padding between struct members (and array elements). I guess recursion is the best solution in that case, then.
I would like to see this patch be more split up, though. At the moment it doesn't just support array initializers, it also supports nested structs, and flat initializers for non-scalars. All of that should be split into separate patches.