On Fri Apr 14 00:45:46 2023 +0000, Zebediah Figura wrote:
Why do we need to check "allocated" here? Even with the hacks in 1/8 I don't think it should be necessary, should it?
Now that you mention it... I really don't remember at this point ;_;
This code path only matters for variables within constant buffers, that have object components, but that also have their numeric components used (otherwise they don't show). We don't support these yet.
For instance, in this test:
``` cbuffer buff { struct { Texture2D tex[4]; float4 a; } st; }
float4 main() : sv_target { return st.a + st.tex[1].Load(int3(0, 0, 0)); } ``` the native compiler gives the following bits for the definition of st (look in particular to the last 4 words of the Variable definition): ``` ... 164 > Variable └─ 00000000000000000000000011001100[offset_name:204] └─ 00000000000000000000000000000000[offset_from_start_of_cbuffer:0] └─ 00000000000000000000000000010000[size:16] └─ 00000000000000000000000000000010[flags:2] └─ 00000000000000000000000100010100[var_type_offset:276] └─ 00000000000000000000000000000000[default_val_offset:0] └─ 00000000000000000000000000000000[tex_start:0] └─ 00000000000000000000000000000010[tex_count:2] └─ 11111111111111111111111111111111[sam_start:4294967295] └─ 00000000000000000000000000000000[sam_count:0] 204 > Name └─ 01110011 01110100 00000000 "st" ... ```
I also noticed that the here called `tex_start` and `sam_start` words should be -1 (rather than 0) when the registers are not allocated, as `sam_start` in this example.
Anyways, I think it is better if I move this patch to another MR, once I have inspected and tested this further.