On Mon Dec 5 21:52:51 2022 +0000, Zebediah Figura wrote:
Hmm, is this the right condition, though? Should we be checking for !HLSL_STORAGE_UNIFORM instead? Since we want to fail in almost exactly the same way for uninitialized function-scoped variables. It's perhaps worth mentioning that as written, this will also catch static (or function-scoped) variables that have a non-uniform initialization. IIRC that's forbidden in native too, but it maybe means the compiler message should be adjusted? Like "loads from resource objects must have a single uniform source"? Or maybe we should run liveness analysis before this and check var->last_write.
Hmm, is this the right condition, though? Should we be checking for !HLSL_STORAGE_UNIFORM instead? Since we want to fail in almost exactly the same way for uninitialized function-scoped variables.
I think this is a nice idea. We already have checks for these cases in hlsl_sm4.c: ``` hlsl_fixme(ctx, &load->node.loc, "Load from non-uniform resource variable."); ``` and ```c hlsl_fixme(ctx, &instr->loc, "Object copy."); ``` but those are FIXME·s instead of proper hlsl_error·s.
It's perhaps worth mentioning that as written, this will also catch static (or function-scoped) variables that have a non-uniform initialization. IIRC that's forbidden in native too, but it maybe means the compiler message should be adjusted? Like "loads from resource objects must have a single uniform source"?
Oh, I see. I will change the error messages too.
Or maybe we should run liveness analysis before this and check var->last_write.
I mentioned that it is a TODO to perform this validation after compute_liveness/dce in the message of the second commit.