Bug 104905 - SpvOpFOrdEqual doesn't return correct results for NaNs
Summary: SpvOpFOrdEqual doesn't return correct results for NaNs
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/Vulkan/radeon (show other bugs)
Version: git
Hardware: All All
: medium normal
Assignee: mesa-dev
QA Contact: mesa-dev
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-02-01 15:02 UTC by Józef Kucia
Modified: 2018-02-26 14:43 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Józef Kucia 2018-02-01 15:02:12 UTC
SpvOpFOrdEqual doesn't seem to perform ordered comparison, e.g. NaN and 1.0 gives true. I expect this to also be a problem for other ordered comparison SPIR-V opcodes.

Mesa SPIR-V to NIR translator inserts additional nir_feq instructions in order to detect NaNs, but those instructions are probably optimized out by LLVM.

The problem can be reproduced by running VKD3D tests: https://source.winehq.org/git/vkd3d.git/blob/HEAD:/tests/d3d12.c#l6640

I can write a standalone test case, if needed.
Comment 1 Samuel Pitoiset 2018-02-09 09:09:22 UTC
Hi Jozef,

Yeah, would be nice to have a standalone case.
Comment 2 Samuel Pitoiset 2018-02-26 13:10:26 UTC
This should fix the issue https://cgit.freedesktop.org/mesa/mesa/commit/?id=e05507a427b79e481eb8e45d7aa3c9b4b78376bf 

Can you confirm and close the bug, please?

Thanks!
Comment 3 Józef Kucia 2018-02-26 14:43:08 UTC
e05507a427b79e481eb8e45d7aa3c9b4b78376bf fixes the issue. Thanks!


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.