On 9/9/18 9:40 PM, Ilia Mirkin wrote:
On Sun, Sep 9, 2018 at 3:19 PM, Axel Davy <davyax...@gmail.com> wrote:
Tests showed Intel on windows does always clamp
RCP, RSQ and LOG (thus preventing inf/nan generation),
for all shader versions (some vendor behaviours vary
with shader versions).
By the way, this happens because on Intel, the ALU is put into a
special mode where it just doesn't generate NaN's at all under any
conditions. I don't think that other vendors operate this way.
Yes exactly, though the documentation, if I remember correctly,
says the flag is for shaders version <= 2.0, but tests showed the clamping
was also used for version 3.0.
The point is that games work properly on all vendors. Thus picking intel
behaviour is safe,
even if we use a card from another vendor.
I think the inf/nan behaviour on AMD and NVidia was with compute
applications in mind (there was no
other way to do compute back then), but games weren't interested in Infs
and NaN.
Also our tests showed that all vendors have 0*inf = 0 and 0*NaN = 0,
even if rcp, log and rsq are clamped.
(inf and NaN can be passed via constants or inputs for such tests).
Axel
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
