vkd3d-shader/spirv: Correctly implement DTOF.
Merge request reports
Activity
I'm not sure I understand, if it's a problem in vkd3d-shader and you're not touching the tests, how did you find it using the d3dcompiler? Independently of that, would it be possible to have a test for this, and maybe a comment about what was broken in the commit message or in the code? The code before and after looks very similar to me and I'm not understanding what's the real change.
I built the crosstests and ran them with native d3dcompiler. This was for the purposes of more easily testing 1318, but I also noticed a couple of missing pieces in the spirv compilation path.
The unique thing about this and the other cases is that our HLSL compiler doesn't handle them yet. In order to have a test we'd need to either duplicate these tests into d3d12.c, or implement double support in the HLSL compiler. The latter is of course desirable anyway, and if it needs to block this patch I'll spend time workign on that.
In theory we already have a DTOF test in
d3d12.c
, how hard would it be to change it so that it exposes whatever is broken now?I adjusted the dtof test in d3d12.c. Unfortunately the new version crashes without this commit, so I couldn't order it before the fix.
Otherwise, it is possible to trigger the failure using DXC, so you can have a test without adding double support to our HLSL compiler?
I'm not familiar with sm6, but IIRC it isn't vectored in the same way, so we can't really construct a similar test.
I adjusted the dtof test in d3d12.c. Unfortunately the new version crashes without this commit, so I couldn't order it before the fix.
Thanks! Mmh, interesting indeed.
dtof o0.xz, cb0[0].zwxy
Here
.xz
is interpreted as a sort of write swizzle, not a write mask. This seems confirmed by MSDN. Ugh, I think I hate this, though it doesn't seem there are many alternatives for that in VSIR other than following suit to Microsoft.I'm not familiar with sm6, but IIRC it isn't vectored in the same way, so we can't really construct a similar test.
Right, with that being the problem it's probably a problem just in SM4.
It seems that the problem also happens for DTOU and DTOI. It would be great if you could provide tests and fixes for those too.
Here
.xz
is interpreted as a sort of write swizzle, not a write mask. This seems confirmed by MSDN. Ugh, I think I hate this, though it doesn't seem there are many alternatives for that in VSIR other than following suit to Microsoft.Yep :x
If only we didn't need to use vsir for disassembly...
added 1 commit
- bfc877b1 - tests/d3d12: Make the dtof test a bit more interesting.
added 36 commits
-
6cf23291...82578432 - 32 commits from branch
wine:master
- f4167136 - vkd3d-shader/spirv: Correctly implement DTOF.
- 4130ce5b - vkd3d-shader/spirv: Correctly implement DTOI.
- efe68610 - vkd3d-shader/spirv: Correctly implement DTOU.
- dd450c52 - tests/d3d12: Make the dtof test a bit more interesting.
Toggle commit list-
6cf23291...82578432 - 32 commits from branch