On 11/18/2020 02:49 AM, Connor Abbott wrote:
On Tue, Nov 17, 2020 at 9:56 PM Brian Paul <bri...@vmware.com> wrote:
On 11/17/2020 11:49 AM, Ian Romanick wrote:
On 11/17/20 9:25 AM, Brian Paul wrote:
Using the Intel Vulkan driver, we've found some cases where SpvOpSelect
is returning -0.0 (negative zeros) instead of normal 0.0 depending on
the arguments.
Do you have a specific test case that fails?
Yeah, but as with the NMin/NMax issue it's not a simple test case. It
comes from a Windows WHCK test suite.
It seems like on some platforms there was an errata about the version of
the SEL instruction that is used for min or max that can return the
wrong signed zero in some cases.
It's also possible that some optimizations are causing problems. I
don't remember exactly how it works in SPIR-V, but does marking those
SPIR-V instructions as precise (that's what it was in GLSL) make a
difference?
AFAIK, there's only a SPIR-V decoration for tagging things for relaxed
precision.
The SPIR-V equivalent of "precise" is NoContract. But for emulating DX
stuff you're supposed to use KHR_shader_float_controls which was
specifically designed for emulating DX floating-point requirements. In
NIR that just marks everything as "exact" if you force correct
NaN/signed zero/Inf handling.
Thanks for the tip! I'll take a look at that.
-Brian
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
