vkd3d-shader/hlsl: Add support for any() intrinsic.
For now, this is limited to float and bool, scalar and vector. All other types are unsupported.
Merge request reports
Activity
added 21 commits
-
e910c0fa...8ed74377 - 19 commits from branch
wine:master
- 14da4748 - vkd3d-shader/hlsl: Add support for any() intrinsic.
- 48e55be9 - tests: Add tests for any() intrinsic.
-
e910c0fa...8ed74377 - 19 commits from branch
- Resolved by Ethan Lee
- Resolved by Ethan Lee
- tests/any.shader_test 0 → 100644
48 draw quad 49 probe all rgba (1.0, 1.0, 1.0, 1.0) 50 51 [require] 52 shader model >= 4.0 53 54 [pixel shader] 55 uniform bool4 b; 56 57 float4 main() : sv_target 58 { 59 return any(b); 60 } 61 62 [test] 63 uniform 0 uint4 1 1 1 1 This is technically an ABI violation, because
true
is represented in SM4 as0xffffffff
, not1
. In practice it shouldn't matter, but given that it's not that hard could you change the shader touniform uint4 b; float4 main() : sv_target { return any((bool4)b); }
and similar for the scalar case?
This is technically an ABI violation, because
true
is represented in SM4 as0xffffffff
, not1
.Is that actually the case? True is ~0u internally while in the shader, but do we know that it's required to pass it that way to the shader, or does the shader normalize it? It's hard to find any documentation for this...
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.
added 16 commits
-
d987f600...0ce55e8b - 14 commits from branch
wine:master
- e517f996 - vkd3d-shader/hlsl: Add support for any() intrinsic.
- 12d04f1c - tests: Add tests for any() intrinsic.
-
d987f600...0ce55e8b - 14 commits from branch