It's either the handling of zero times +infty or the handling of NaN
(how is NaN mapped to a RGBA vector?). OpenGL and D3D do seems to have
different opinions on how this should be done.
On OpenGL there is no word in the standard how it should be done, so
it's essentially undefined behaviour. The nvidia-drivers implement a
non-windows conformant behaviour, while the ati-drivers implement the
handling that is also happening in the Windows drivers. This is both
fine (however not for us).
D3D seems to have a uniform way of handling this, otherwise someone
would have noticed that lighting bugs on native Windows before. That's
not the case, so NaN handling (or the zero * infty thing) is defined
behaviour there (perhaps not covered in the MSDN, but you can't trust
the MSDN anyway..)
I still don't know what Chris wanted to prove in the bugreport.
Let's repeat this once again: The ERRs he mentions have nothing to do
with the initial problem described in the report (the MP2 one). The
visual errors don't trigger any WARNs, ERRs, FIXMEs or whatever. It's
simply that our translation of D3D asm to OpenGL asm or GLSL isn't fully
correct. The resulting shader code is fully valid, however it's not
doing exactly what the original D3D shader code does. And obviously this
doesn't trigger any errors apart from testcases (which we currently
don't have in git master).
Greets,
Tobias