7 Jun
2023
7 Jun
'23
4:59 p.m.
- Seems that the allocation order of the texture part and the sampler part is not bonded together in the native compiler:
That doesn't seem like a blocker, though. We already do allocation in multiple passes; we could do a separate pass for combined samplers where necessary.
- The var->objects_usage[] array is created on hlsl_new_var() from the type->regsize[]. So we would either have to allocate memory for it once we discover that var is used as a combined sampler or we would have to preemptively set type->regsize[HLSL_REGSET_TEXTURES] the same as type->regsize[HLSL_REGSET_SAMPLERS] for all samplers in SM4.
Or we mark internally that the variable is used as a combined sampler before RA (i.e. the same time when we're running lower_combined_samples, probably) and then set objects_usage based on that.
- We are currently assuming that all resources belong to a single regset, so we would have to add additional checks in many places where hlsl_type_get_regset() is called, to know if we are interested in the texture or sampler part.
See, and this is where I have to once again state that hlsl_type_get_regset() has always seemed like a fundamentally broken function to me. It never had a clear boolean answer for structs, and I'm not convinced it can have a clear boolean answer for individual variables either.
I'm not married to this idea of reusing variables, but I'm still not quite convinced it's the wrong idea either.