Re: [Haskell-cafe] Glome raytracer bug: bad output with -O2 -fasm

Luke Palmer wrote:

On Fri, Mar 28, 2008 at 6:28 AM, Jim Snow wrote:

...

I was trying to get Blinn highlights working with my raytracer, and kept getting ugly artifacts. After trying a bunch of things, I finally compiled without -O2, and the artifacts went away.

Here's what I mean: http://syn.cs.pdx.edu/~jsnow/glome/Glome.hs-noartifact.png http://syn.cs.pdx.edu/~jsnow/glome/Glome.hs-artifact.png

Here's the offending code, run "./make" and "./run" and you should see the artifacts if your setup is the same as mine. (Requires OpenGL.) http://syn.cs.pdx.edu/~jsnow/glome/glome.hs-0.2-bug.tar.gz

The artifacts also go away if I use -fvia-C. It doesn't seem to matter whether I use Floats or Doubles in the rendering code. The artifacts also show up with -O1. Have I stumbled across a known compiler bug? Or perhaps an OpenGL bug? (The bug could, of course, be in my code, but then one might expect to get the same erroneous output every time regardless of compiler flags.)

To reiterate, I'm using ghc 8.6.2.

You probably mean 6.8.2.

Yes, my mistake. 6.8.2.

Works for me in all cases.

% uname -a Linux madhatter 2.6.22-gentoo-r8 #6 PREEMPT Sat Oct 20 04:19:22 GMT 2007 i686 AMD Turion(tm) 64 Mobile Technology ML-40 AuthenticAMD GNU/Linux % ghc --version The Glorious Glasgow Haskell Compilation System, version 6.8.2

Looks to me like Glome is depending on some very fine details of floating point arithmetic.

Luke

After looking into this for awhile, I found that the problem was that in computing my Blinn factor: blinn = fmax 0 $ (vdot halfangle n) ** shine the (vdot halfangle n) was sometimes negative, resulting in blinn being "NaN". OpenGL apparently interprets "NaN" as "1.0" for the purposes of color*, so those patches were rendered bright white. It's still a bit mysterious why the case where (vdot halfangle n) is negative only occurs if I compile with "-fasm", but I can work around it for now. -jim * I'm using the binary-only nvidia drivers; different OpenGL implementations may behave differently.