From: "Zebediah Figura (she/her)" <zfigura@codeweavers.com>
Subject: Re: [PATCH vkd3d] vkd3d-shader/hlsl: Support array initializers.
Message-Id: <983dad64-ce28-66fb-c18f-e0e618d02f7f@codeweavers.com>
Date: Tue, 4 Jan 2022 12:07:39 -0600
In-Reply-To: <e9d68a7096fb0bd71900b3c12cb2b600@codeweavers.com>
References: <4b188ac9-69d2-eaac-7984-881aec4ac55f@codeweavers.com> <20211229145135.123336-1-fcasas@codeweavers.com> <e9d68a7096fb0bd71900b3c12cb2b600@codeweavers.com>

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.