[Mesa-dev] SpvOpSelect w/ float operands

Brian Paul brianp at vmware.com
Wed Nov 18 13:28:31 UTC 2020

On 11/18/2020 02:49 AM, Connor Abbott wrote:
> On Tue, Nov 17, 2020 at 9:56 PM Brian Paul <brianp at 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.


More information about the mesa-dev mailing list