Hello,
April 22, 2022 3:45 PM, "Zebediah Figura" zfigura@codeweavers.com wrote:
On 4/22/22 09:11, Francisco Casas wrote:
Hello, April 22, 2022 6:51 AM, "Giovanni Mascellani" gmascellani@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.