On Tue Jan 31 23:39:32 2023 +0000, Zebediah Figura wrote:
We shouldn't even have sampler variables left over by the time we
get to sm1.
I am not sure if you meant to say "textures" instead of "samplers",
but combined samplers appear like "Texture2D" in the CTAB, and `register(s·)` can be used in textures so that they reserve a particular sampler register: I mean we shouldn't have HLSL_TYPE_SAMPLER variables left over. That's what my (out-of-tree) patches accomplish by lowering "separate" HLSL_IR_RESOURCE_LOAD to "combined" HLSL_IR_RESOURCE_LOAD instructions. I.e. removing the "sampler" variable from the instruction. Arguably it's a bit awkward naming-wise to map HLSL_TYPE_TEXTURE to what sm1 (or GLSL, for that matter) calls a "sampler", but in terms of functionality I think it makes the most sense (e.g. HLSL_TYPE_TEXTURE has a dimension, as do sm1 samplers; HLSL_TYPE_SAMPLER does not.)
But we need an intermediate mapping from HLSL_REGSET_* to
backend-specific register type enums anyway. Why does it matter how we map hlsl types to regsets?
I think that what I care about, rather than the name change, is that
regsets can be used directly in the passes for allocating objects and for calculating deref offsets, both of which are backend-specific but have to be done before writing the actual bytecode. I don't quite see how the mapping affects that, though?
I realize, by the way, the current code doesn't really work like this (cf. the object_types global array), but I think the current code is broken for sm1 anyway.