[Mesa-dev] SpvOpSelect w/ float operands

[Brian Paul]

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 at 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
>