[Mesa-dev] Mesa (master): r600g: Use default mul/mad function for tgsi-to-llvm

[Tom Stellard]

On Thu, Dec 06, 2012 at 01:35:22PM -0500, Alex Deucher wrote:
> On Thu, Dec 6, 2012 at 1:27 PM, Alex Deucher <alexdeucher at gmail.com> wrote:
> > On Thu, Dec 6, 2012 at 1:21 PM, Vincent Lejeune <vljn at ovi.com> wrote:
> >> Sorry for the inconvenience.
> >> I think the r600g backend work because of this patch, which switch MUL and MUL_IEEE definition :
> >> http://lists.freedesktop.org/archives/mesa-dev/2012-November/030748.html
> >>
> >> The rationale behind the patch is use the fmul instead of a custom intrinsic for OpenGL path.
> >> Glsl-to-llvm generates as "vanilla" instructions as possible and uses fmul, this consolidates behaviour
> >> between tgsi-to-llvm and glsl-to-llvm.
> >> IMHO emitting MUL and MUL_IEEE should be decided with the presence of some "fast-math" arg to the backend,
> >> or some context variable telling if we have a glsl or an opencl shader.
> >
> > MUL and MUL_IEEE are not related to performance, rather to behavior:
> >
> > MUL            Floating-point multiply. 0*anything = 0.
> > MUL_IEEE  IEEE Floating-point multiply. Uses IEEE rules for 0*anything.
>

I asked idr about this on IRC and he said that IEEE rules are required for
GLSL >= 1.30 and they are compliant, but not required for GLSL < 1.30.
stringfellow added that the d3d9 spec required 0*anything = 0, which is
probably why the hardware has those instructions.

 
> IIRC, we want the MUL behavior in GL.  In the pre-LLVM days we used
> MUL_IEEE and switching to MUL fixed a bunch of piglit tests.
> 

I just ran tests on r600g with the normal compiler and using MUL_IEEE results
in +6 piglit passes (All of theses tests are glsl-1.30 isnan tests).  I'm
guessing that the tests that used to fail with MUL_IEEE were either fixed or
removed during the glsl 1.30 implementation.  So, it seems like MUL_IEEE is safe
to use.

-Tom