On Mon Apr 17 09:07:40 2023 +0000, Giovanni Mascellani wrote:
I tried a few examples:
bool4 main(int4 x : color) : SV_TARGET { return x; }compiles to
ps_4_0 dcl_input_ps constant v0.xyzw dcl_output o0.xyzw ine o0.xyzw, v0.xyzw, l(0, 0, 0, 0) ret(https://shader-playground.timjones.io/63ec9c244edae1d822a1daf5fbc79d40) So it seems that the native compiler feels an obligation to generate an actual 0xffffffff for a true, otherwise it could have just moved v0 to o0.
bool4 main(bool4 x : color) : SV_TARGET { return x; }compiles to
ps_4_0 dcl_input_ps constant v0.xyzw dcl_output o0.xyzw mov o0.xyzw, v0.xyzw ret(https://shader-playground.timjones.io/1647c611f02ea54b06828cae9a668fac) It seems that the native compiler trusts that a true bool is represented as 0xffffffff, otherwise it couldn't satisfy the obligation it seems to have from the test above.
int4 main(bool4 x : color) : SV_TARGET { return x; }compiles to
ps_4_0 dcl_input_ps constant v0.xyzw dcl_output o0.xyzw and o0.xyzw, v0.xyzw, l(1, 1, 1, 1) ret(https://shader-playground.timjones.io/c9b0ea8dd59ebb5bfe44b326816f527c) This is possibly the most convincing test: if the compiler didn't have the guarantee that true's are always 0xffffffff this would be miscompiled. So it seems that representing true as 0xffffffff is a requirement at the boundary of the shader, in both directions.
That's a semantic, though. If you use a uniform instead, the code seems to change, to stop assuming that true is ~0. The same result happens for vs input semantics. This makes sense, given that a ps semantic would have been generated not by the user but by the vs.