On Tue Jan 31 23:03:22 2023 +0000, Francisco Casas wrote:
In the same example above, the `uniform struct apple ap` is allocated from `t0` to `t5` and from `s0` to `s2`, even though only `ap.sam2[0]` and `ap.texs2[1]` are used. Which means that all the registers for `ap.texs1[]` and `ap.sam1[]` were allocated even if they are not used. The rules are that for each variable, all texture registers are allocated if only one is used, and sampler registers are allocated from the first one to the last one that is actually used. These rules work at the variable-level, without considering how the variable is subdivided into components.
Oh. Right. I think I knew that at some point but forgot. Sorry for the runaround.
I do think that hlsl_type_get_regset() feels conceptually broken, though, and HLSL_REGSET_VOID as well. The function signature implies to the reader that a type can only have one register set, which simply isn't true. If we were to assert that it was never called with a struct type, that would probably be fine. As far as I can tell that's true of all of its callers right now anyway, except for:
* write_sm4_rdef() and write_sm4_shdr(), which can just move it after the check for HLSL_CLASS_OBJECT;
* write_sm1_uniforms() should I think validate that structs never contain objects and then just assume that any struct is numeric;
* sm4_compare_externs() - why did this need to be changed? (And if this actually does change sorting order it deserves its own patch.)