On Thu, Dec 06, 2012 at 01:35:22PM -0500, Alex Deucher wrote: > On Thu, Dec 6, 2012 at 1:27 PM, Alex Deucher <alexdeuc...@gmail.com> wrote: > > On Thu, Dec 6, 2012 at 1:21 PM, Vincent Lejeune <v...@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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
