On Fri Jul 21 00:52:11 2023 +0000, Henri Verbeet wrote:
+static const struct vkd3d_sm4_register_type_info *get_register_type_info( + enum vkd3d_sm4_register_type type) +{ + unsigned int i; + + for (i = 0; i < ARRAY_SIZE(register_type_table); ++i) + { + if (type == register_type_table[i].type) return ®ister_type_table[i]; + } + + return NULL; +} + +static const struct vkd3d_sm4_register_type_info *get_register_type_info_from_handler( + enum vkd3d_shader_register_type handler) +{ + unsigned int i; + + for (i = 0; i < ARRAY_SIZE(register_type_table); ++i) + { + if (handler == register_type_table[i].handler_type) return ®ister_type_table[i]; + } + + return NULL; +}We care about parser speed at least somewhat, and looping over the table like that is probably going to make it worse. (On that note, get_opcode_info() is one of the current offenders, and we should probably just index opcode_table[] by the opcode id.) We probably care slightly less about HLSL compilation time, but I'd probably feel better about simply having separate tables for vkd3d->sm4 and sm4->vkd3d. There may be different ways to get there, of course. The most straightforward approach would be to simply put two separate tables in tpf.c, and I think that would be fine. We could also generate those lookup tables from a single table like you have here though, either at runtime (for example, the first time get_register_type_info()/get_register_type_info_from_handler() is called) or at compile time. I don't love the names "type" and "handler_type"; I'd probably prefer some variant of "tpf_type"/"vkd3d_type", "sm4_type"/"ir_type", or something along those lines.
The `'s'` trick doesn't really thrill me, but right now I can't think
of anything better and I prefer to see this moving forward rather than bikeshedding that bit (which can always be improved later, if a better solution arise at some point). Likewise; I don't think it's great, but I can live with it. Does this series strictly depend on the first two patches by Conor?
I see, I modified get_register_type_info() and get_register_type_info_from_handler() to have static lookup arrays, initialized on the first call. If you think this solutions is fine, I can send a similar solution for get_opcode_info() as another MR.
Also, I renamed the functions to get_info_from_sm4_register_type() and get_info_from_vkd3d_register_type().
I also renamed the vkd3d_sm4_register_type_info fields as sm4_type and vkd3d_type.
Does this series strictly depend on the first two patches by Conor?
I see now that it is not as dependent as !269 was. I removed the first two patches and just replaced it with a patch that renames `VKD3D_SM4_SWIZZLE_NONE` to `VKD3D_SM4_SWIZZLE_MASK4`.