Hi,
On 22/12/21 19:03, Zebediah Figura (she/her) wrote:
To expand, what I mean is that the alternative—where we use hlsl_src—means we'd need to have a separate HLSL_IR_LOAD instruction, and then at codegen time we reach through it and retrieve the variable from that. That works—objects can only be returned by LOAD instructions—but the problem is that you can get something like:
Texture2D | 2: t1 | 3: t1 = t2 float4 | 4: sample(@2, ...)
I guess we could validate at codegen time that t1 isn't written to (after all, if it is, we have a problem anyway)...
Ah, yes, I see what you mean.
I wrote and erased this email a few times changing my point of view every time, and in the end I think I just came to your conclusion, which I see with two different layers (well, at least two).
The upper layer is that what we call "texture variable" behave rather as references, point to underlying immutable texture entities (after all, if this wasn't the case you couldn't even assign one to another). Expression "@2" really means "the entity that t1 was pointing to at line 2", not "the variable t1 itself". In much the same way as, if you had
float | 2: x
the expression "@2" would mean "the value variable x had a line 2", not "the variable x" or "the value variable x has now".
We can treat objects this way and we should be able to manipulate it in much the same ways as we do for numbers.
In practice (the second layer), all object parameters must be completely known at compilation time, because you cannot represent object references in DXBC, only entities (by mean of their "register"). So after all copy propagation, dead code elimination and possibly other optimizations have run, no stores to objects must remain. Not just between a load and the corresponding usage: no stores at all. Once that is true, the confusion between entities and references doesn't happen anymore and you can identify variables with their loads. Which is, as I get it, what you were saying.
All of this doesn't say much between whether resource loads should use hlsl_src or hlsl_deref, though I guess that it says that hlsl_src should not be a problem in itself.
Giovanni.