This MR replaces `vkd3d_shader_register.immconst_type` with `vkd3d_shader_register.dimension` which is intended for all register types and not just immconsts.
This dimension is parsed in tpf.c, and initialized according to the register type in d3dbc.c.
Having this field in vkd3d_shader_register allows us to avoid hardcoding special cases for the register dimensions when writing sm4 bytecode (e.g. for the sampler src register in gather instructions). Also, it allows for some fixes to d3d_asm.c, which are introduced in part 2 (https://gitlab.winehq.org/fcasas/vkd3d/-/commits/add_vkd3d_reg_dim).
--
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/319
> This is hardly the only place that does something like this, but could we please start using shader_register_init() or helpers built on top of that? Mainly to make life slightly easier for people touching struct vkd3d_shader_register in the future, of course.
Sure, will do in the future. I was not particularly aware of those helpers.
In this case we may want to not be passing vkd3d_shader_register down at all, but I'm not sure. It's not quite clear how to avoid it, anyway.
--
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/312#note_43788
On Tue Aug 29 20:38:35 2023 +0000, Alexandre Julliard wrote:
> Please try to fix this properly. It looks like all it needs is a simple realloc().
This is not something I have the ability to do as I have absolutely no knowledge about the inner workings of wine.
If this is something you think can be easily fixed then please go ahead and implement the proper solution!
Increasing the (arbitrary) limit is what unblocked me from being able to use wine for my setup, but I agree that it's not the complete fix.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1893#note_43759