On Fri Apr 14 19:02:09 2023 +0000, Zebediah Figura wrote:
Yes. I'll see if I can write something for this. If nothing else I suspect it'll prove we're doing something wrong.
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.