[PATCH vkd3d 04/13] vkd3d-shader/hlsl: Propagate copies for resource load instructions.

[Giovanni Mascellani]

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.