Okay, it is not as bad as I imagine. Perhaps I should do the cost assessments when I am fresh in the morning and not when I tired.
Still, there are 5 places where it would be better to iterate over a regset: track_object_components_usage(), calculate_resource_register_counts(), write_sm1_sampler_dcls(), write_sm4_dcl_samplers(), and write_sm4_dcl_textures(); but iteration per-component it is useful for promoting resource components into separate variables for SM 5.1.
Hrm, I didn't quite think this through completely, I forgot that register allocation is still only done per-variable. Yeah, so it would require that for every time we're declaring a texture.
If we need to track anything per-component, it still may be best to do it that way, though.
I probably didn't understood this the first time, I thought you were referring to the register range that's allocated, which goes from 0 to the maximum used component (which can be stored in var->regs[HLSL_REGSET_NUMERIC].count).
If I understand correctly, you are saying that in SM1 there are cases where a uniform variable (or field) can require the size of a bool or a int according to how it is used. I am not familiarized with this behavior. Can you provide an example?
Most of sm1 uses float uniforms, even where they're declared with non-float type. SM 3.0 introduces the first flow control, and its flow control instructions—and *only* those instructions—take non-float types. Specifically "if" takes a bool type, and "loop" takes an integer type. Consider the following shader:
``` uniform struct { float f; bool b; int i; } a;
float4 main() : sv_target { float x = a.f + a.i + a.b; if (a.b) x += 2; return x; } ```
Ultimately "a.b" is allocated to *both* the float and bool register sets. (You can get a similar effect for ints by declaring a loop that executes for i iterations, but I didn't bother with that.)
This is true without the struct too, of course, but the struct shows that there are interesting consequences wrt allocation.
Granted, I suppose we don't really need to do this tracking per-component—we can just do it the same way as we do textures...