On Wed Oct 4 16:21:21 2023 +0000, Zebediah Figura wrote:
I don't like this, sorry. I think deref->data_type is pretty definitely going to go away eventually. I'm not heavily opposed to shuffling things around in the meantime (although I don't see it as worthwhile). This does mean that 2/2 feels wrong, however. More importantly, I don't like 1/2. hlsl_deref_compute_data_type() specifically feels wrong, it turns a simple idempotent function into something that now has to be called every time we construct a deref. It's not really clear to me how the code gets simpler either, if it does.
I mean, we don't **need** to get rid of it even if we complete the translation to vsir output.
I think the biggest simplification is being able to just write `deref->data_type` instead of calling a function that also requires the ctx everywhere we need the data type of the deref.
Still, I understand that this field is a derived attribute, and redundancy may lead us to forget we have to change things in two places if we want to do it, even though I can only think of a single scenario were we would change the type of a deref, that being merging separated samplers.
Okay, I will write my rebasing of non-constant offset dereferences assuming that deref->data_type won't extend during the whole deref's lifetime.
I will keep this MR open for a while though, in case there are additional comments.