[Bug 60024] New: build-time test failure in d3d12 sat,min_max on ppc64el, Debian unstable, Mesa 26.1.4, lavapipe
http://bugs.winehq.org/show_bug.cgi?id=60024 Bug ID: 60024 Summary: build-time test failure in d3d12 sat,min_max on ppc64el, Debian unstable, Mesa 26.1.4, lavapipe Product: vkd3d Version: 2.0 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: vkd3d Assignee: wine-bugs@list.winehq.org Reporter: smcv@collabora.com Target Milestone: --- Distribution: --- vkd3d 2.0 runs build-time tests successfully on most Debian architectures where it has been tried (x86_64, arm64, i386), but on ppc64el (64-bit little-endian PowerPC) the d3d12 test failed with: d3d12.c:11416: 84:sat: Test failed: Got {1.00000000e+00, 1.00000000e+00, 1.00000000e+00, 0.00000000e+00}, expected {0.00000000e+00, 0.00000000e+00, 1.00000000e+00, 0.00000000e+00} at (0, 0). d3d12.c:11416: 87:min_max: Test failed: Got {1.00000000e+00, nan, 0.00000000e+00, 0.00000000e+00}, expected {1.00000000e+00, 1.00000000e+00, 0.00000000e+00, 0.00000000e+00} at (0, 0). d3d12.c:11416: 88:min_max: Test failed: Got {0.00000000e+00, nan, 0.00000000e+00, 0.00000000e+00}, expected {0.00000000e+00, 0.00000000e+00, 0.00000000e+00, 0.00000000e+00} at (0, 0). These seem to be the only three unexpected failures. Does this seem familiar to anyone? This is in a controlled environment (a container with a limited set of Debian packages, and no access to real hardware), so it might be more reproducible than problems with actual GPUs. Debian bug report: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1142192 Full build log: https://buildd.debian.org/status/fetch.php?pkg=vkd3d&arch=ppc64el&ver=2.0%2B... I've cc'd Debian's PowerPC porting team on the Debian bug report, perhaps they can help. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=60024 Simon McVittie <smcv@collabora.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Hardware|x86-64 |Other -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=60024 --- Comment #1 from Henri Verbeet <hverbeet@gmail.com> --- (In reply to Simon McVittie from comment #0)
vkd3d 2.0 runs build-time tests successfully on most Debian architectures where it has been tried (x86_64, arm64, i386), but on ppc64el (64-bit little-endian PowerPC) the d3d12 test failed with:
d3d12.c:11416: 84:sat: Test failed: Got {1.00000000e+00, 1.00000000e+00, 1.00000000e+00, 0.00000000e+00}, expected {0.00000000e+00, 0.00000000e+00, 1.00000000e+00, 0.00000000e+00} at (0, 0). d3d12.c:11416: 87:min_max: Test failed: Got {1.00000000e+00, nan, 0.00000000e+00, 0.00000000e+00}, expected {1.00000000e+00, 1.00000000e+00, 0.00000000e+00, 0.00000000e+00} at (0, 0). d3d12.c:11416: 88:min_max: Test failed: Got {0.00000000e+00, nan, 0.00000000e+00, 0.00000000e+00}, expected {0.00000000e+00, 0.00000000e+00, 0.00000000e+00, 0.00000000e+00} at (0, 0).
These seem to be the only three unexpected failures. Does this seem familiar to anyone?
I can't say it looks familiar to me, but these results seem to suggest an issue with the ppc64el implementation of the GLSLstd450NMax SPIR-V instruction in lavapipe/llvmpipe. Specifically, the values that differ above are calculated like this in the shader: 84:sat: GLSLstd450NClamp(NAN, 0.0, 1.0) GLSLstd450NClamp(-NAN, 0.0, 1.0) 87:min_max: GLSLstd450NMax(NAN, 1.0) 88:min_max: GLSLstd450NMax(0.0, NAN) https://registry.khronos.org/SPIR-V/specs/unified1/GLSL.std.450.html says about NMax: "If one operand is a NaN, the other operand is the result. If both operands are NaN, the result is a NaN.", and about NClamp: "Result is min(max(x, minVal), maxVal)." What seems to be happening here is that NMax is returning NANs, and the NClamp results seem to follow from that. Notably, NMin does appear to behave as expected. It would take me a bit of effort to verify whether that's indeed what's happening though. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=60024 --- Comment #2 from Simon McVittie <smcv@collabora.com> --- On the Debian bug, Elizabeth Figura wrote:
Interesting that it fails with llvmpipe on a specific architecture, but for floating point corner cases it makes sense
and we both wondered whether it would make sense to skip these three corner-cases as "probably never worked, probably not a regression" on ppc64el. Unfortunately, vkd3d wasn't updated in Debian for a long time (we had 1.2, then a long gap, then 2.0 with better test coverage) so it isn't straightforward to see whether/when this regressed. (I did package intermediate versions of vkd3d for a Debian derivative, but we only built those on x86_64, i386 and aarch64, so any ppc64el-specific problems weren't visible.) -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=60024 --- Comment #3 from Henri Verbeet <hverbeet@gmail.com> --- (In reply to Simon McVittie from comment #2)
On the Debian bug, Elizabeth Figura wrote:
Interesting that it fails with llvmpipe on a specific architecture, but for floating point corner cases it makes sense
and we both wondered whether it would make sense to skip these three corner-cases as "probably never worked, probably not a regression" on ppc64el.
Unfortunately, vkd3d wasn't updated in Debian for a long time (we had 1.2, then a long gap, then 2.0 with better test coverage) so it isn't straightforward to see whether/when this regressed.
(I did package intermediate versions of vkd3d for a Debian derivative, but we only built those on x86_64, i386 and aarch64, so any ppc64el-specific problems weren't visible.)
Well, if my guess is right, this is a llvmpipe on ppc64el bug. It may or may not be a regression, but it wouldn't be vkd3d's regression. As far as vkd3d is concerned, we'd then deal with that by adding a bug_if() with an appropriate condition to the test. Ideally we'd get the llvmpipe issue addressed though. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=60024 --- Comment #4 from Simon McVittie <smcv@collabora.com> --- On the Debian bug, I previously wrote:
Before 2.0, in practice the test suite probably wasn't run at all, because Mesa GL/Vulkan drivers weren't installed - so this test failure might not actually be a regression.
Trying vkd3d 1.2 on the same build machine, I can confirm that in the configuration Debian historically used to build it (but with a current snapshot of Debian unstable, with Mesa 26.1.5), the tests were all skipped due to lack of a working Vulkan driver: they show up as "passed" in the concise build log, but if you look into the detailed .log files, really they were skipped. In the same chroot, if I add Mesa drivers (mesa-vulkan-drivers, libegl-mesa0, libglx-mesa0), then tests/d3d12 fails. It's a different failure mode (a segfault, rather than the more graceful test failure I reported here) but this does at least indicate that 2.0 is not any worse on ppc64el than the version that was previously in Debian. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=60024 --- Comment #5 from Simon McVittie <smcv@collabora.com> --- On the same ppc64el machine, tests/d3d12 in versions 1.7, 1.9, 1.10, 1.11 also segfaults, and 1.12 appears to be the first version to have these three test-cases failing gracefully (same behaviour as 2.0). So this is very much not a recent thing, at least in vkd3d (possibly a more recent regression in Mesa or LLVM of course). In 1.12, some other test-cases in tests/d3d12 are also failing, presumably vkd3d issues that were subsequently fixed. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=60024 --- Comment #6 from Simon McVittie <smcv@collabora.com> --- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/2139 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=60024 --- Comment #7 from Henri Verbeet <hverbeet@gmail.com> --- I ended up changing the patch a little, but should be fixed by commit e912906844564ed8731c50db03af5645ee0c114f. For what it's worth, I did also look a bit into the Mesa source, and I think the issue may in lp_build_max_simple() here: https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/auxiliary/gallivm/lp... I think if the code in question didn't set "intrinsic" in the "nan_behavior == GALLIVM_NAN_RETURN_NAN_FIRST_NONNAN" case, the generic fallback at the end of lp_build_max_simple() would do the right thing. That's just from looking through the code though, I don't currently have any ppc64el setup to actually debug this. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (1)
-
WineHQ Bugzilla