Yeah, that’s another factor. I got the impression that ATI/AMD is more tolerant. And it usually ends up with the ‘right’ results, which was my point about the usefulness of things. Kinda puts a damper on “Beware of bugs in the above code; I have only proved it correct, not tried it.” (Donald Knuth)

I can’t say that all GPUs have this problem – just at least one I have tested. I definitely see different results when I write crappy shaders – the annoying case is when the hardware I happen to be using accepts my bad code and I find out later.

I had a look at some specs. OpenGL specifically doesn’t care about NaNs. An implementation can do whatever it wants with them, as long as it doesn’t crash. It appears Direct3D does care, probably in the blender as well. Also, the uniformity across the GPU must be a good thing (even if 0 * NaN is 0 most of the time anyway, mathematically speaking). I just didn’t really expect this.

The floating point rules say that NaNs have to be treated as standard IEEE NaNs, that is, NaN * anything = NaN. Soo…once you burn a NaN into the framebuffer, I think the GPU is required to do the annoying thing, e.g. preserve the NaN.

In this case there’s often no accum; some hardware may optimize out alpha=1 in the blender, but you’ll still end up with some hosed bits. The _shaders_ have to follow IEEE so no math optimization there.

I wonder. Wouldn’t hardware optimize optimize cases like alpha=1? Or does it also know there are NaNs in the framebuffer? Even though it wouldn’t make much sense most of the time, as you can see here. Well, at least it might not bleed through any and all geometry.