NVidia (6800GT?) ARB_vertex_program state.matrix inverse bug

*note, since this is early in this card’s life, I suppose lots of these bugs will pop up. If any of you object to these bug reports being posted here, please let me know. I’m not a registered developer, so I don’t have many options.

I’ve found another bug on the 6800 with all the driver sets that I could get my hands on.

In ARB_vertex_program:

state.matrix.texture[n].inverse, where n > 0
(all but the first, haven’t tested 0)

and state.matrix.program[n].inverse, where n is >= 0
(all of them)

are not computed when the non-inverted matrix is the identity matrix. The last computed inverse is kept in these state variables, rather than being filled with the identity.

Here’s my reasoning:
In my multipass lighting, I set these per-light. I have an optional ‘flashlight’ that is always the first pass, and when subsequent passes are run (more than the flashlight in the scene,) the flashlight’s inverse matrix state variables are pulled from a different light. If I give thie flashlight’s rotation matrix something other than identity, the problem disappears.

None of this happens on my ATi cards.

I guess what’s happening is that these inverses are being computed for the all but the flashlight, and are flowing into the next frame. It could be because the flashlight’s rotation matrix is the identity matrix, and there’s some optimization in the driver that sees no need to compute the inverse, and leaves last computed inverse there.

Interesting. Definitely sounds like a bug. How are you giving it the identity matrix? Are you using glLoadIdentity or glLoadMatrix? If it’s the former, does the bug appear with the latter?

Does it matter how close to identity you are? What if you add some epsilon to the rotation or translation?

As with any driver bug, it’s best to report it to the IVH (nothing wrong with posting it on the boards though, others may have similar problems, or have found a workaround).

In this case, I think simply loading a matrix like this will work around the problem for the time being:
[1.0000001, 0, 0, 0]
[0, 1, 0, 0]
[0, 0, 1, 0]
[0, 0, 0, 1]

Yes, this is indeed a driver bug. Thanks for reporting it! We’ll get it fixed ASAP.

In the mean time, you can work around by using
LoadMatrix() with an identity matrix instead of LoadIdentity(). You might also be able to apply a Scale(1,1,1) or Translate(0,0,0) after LoadIdentity() to work around the problem.

My personal preference is to see suspected bugs reported on public forums. That way others can help (if it turns out to not be a bug).

Thanks -

Thanks for the quick response, and workarounds.