[PATCH vkd3d v3 09/11] vkd3d-shader/hlsl: Support all complex initalizers.

[Francisco Casas]

Hello,

April 22, 2022 3:45 PM, "Zebediah Figura" <zfigura at codeweavers.com> wrote:

> On 4/22/22 09:11, Francisco Casas wrote:
> 
>> Hello,
>> April 22, 2022 6:51 AM, "Giovanni Mascellani" <gmascellani at codeweavers.com> wrote:
>> Hi,
>>> I am not completely in love with the additional runtime complexity of this solution, but it's true
>>> that it's quite clean.
>> 
>> I have a couple of ideas for lowering the complexity:
>> a) Add a "component_count" field to hlsl_type in order to store/cache the result of
>> hlsl_type_component_count().
>> Which would also speed up other parts of the compiler.
>> b) Add a "comp_offsets" array to "hlsl_type.e" so that the right field that has a given component
>> can be selected in hlsl_compute_component_reg_offset() using a binary search.
>> I can make new patches for these.
> 
> I guess you mean time complexity? I don't think there's any reason to worry about that, especially
> not with initializers.
> 

Yes, I meant time complexity, sorry.

I only see an O(n^2) worst-case scenario, for the initialization of a struct n components.
So yes, it is probably not worth worrying about it.

>> +{
>> + switch (type->type)
>> + {
>> + case HLSL_CLASS_SCALAR:
>> + case HLSL_CLASS_VECTOR:
>> + {
>> + assert(idx < type->dimx * type->dimy);
>> +
>> + if (comp_type)
>> + *comp_type = hlsl_get_scalar_type(ctx, type->base_type);
>>> I think you can assume that comp_type will always be valid and skip this check.
>> 
>> I think hlsl_compute_component_reg_offset() can be used to simplify other functions,
>> like compute_offset_from_index(), and in those cases it could be much cleaner to call
>> it passing a NULL comp_type.
> 
> I'm not sure we want to use hlsl_compute_component_reg_offset() in compute_offset_from_index(). In
> general I'd remove the NULL handling until a patch that actually needs it.

Okay.