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.
-Brian
I'm wondering if "SpvOpSelect x, a, b" for floats is being implemented
with something like "a*x + b*(1-x)" ? That might explain where the
negative zeros are coming from.
Our work-around is to implement selection with bitwise operations: (a &
x) | (b & ~x)
It seems to me that SpvOpSelect shouldn't interpret the bits and just
return an exact copy of the argument.
-Brian
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fmesa-dev&data=04%7C01%7Cbrianp%40vmware.com%7C5e1ffabf0f7c47a2f48308d88b298304%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C1%7C637412357691565798%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=SdzrOYvGGFraVg61OGvIQ6NJrT2i7fye%2Fy03XoZOi7E%3D&reserved=0
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
