CatAtWork

07-16-2004, 08:28 AM

*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.

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.