Interesting Little Bug

[EHeM]

Definitely a developer's issue here. There is at least one (looks like two, possibly a small family of related ones) bug in glRotated() in 71.74. Yeah, I know, 71.84 is out, but I doubt that fixes this bug (known present in some later versions, no changelog entry).

glRotated(0.0, NAN, NAN, NAN) => NANs all over current matrix stack
glRotated(0.0, 0.0, 0.0, MAXFLOAT) => NANs all over current matrix stack (note some headers use HUGE instead of MAXFLOAT)
glRotated(360.0, 1.0, 1.0, 1.0) => not quite a NOP

One can argue about the first case, it is abusing the OpenGL API to some extent. I must argue that there is a well defined behavior for glRotated(0.0, X, Y, Z) for any set of X, Y and Z, mainly it should be a NOP. While setting X, Y and Z to such nasty values is abuse, this does not have a well defined behavior, so I think the former should take precedence. I'll note that Mesa fixed the first case around version 2.6 or so. This is a useful case as a direct conversion from the identity quaternion triggers this.

The second and third are good olde revenge of the floating-point numbers. I'm disturbed about the second case, that isn't abuse of the API by any definition and yet clearly corrupts the current matrix. The third is a minor failure, but a failure nonetheless.

In theory I've attached a simple test program for these cases. The first case is test #124. The second is tests #32, #36, and #56. The third is test #125. (note that these are simply the first ones, these do get touched multiple times) Pretty simple build, `gcc -std=c99 bug2.c -o bug2 -lGL -lglut`, will build on SunOS as well (alas I'm not in front of one, so I don't know whether it worked or if/how it failed); if you get an error about a non-constant initializer for values[4], add -DBROKEN_NAN. bug2.c is designed for fairly straightforward insertion into a QA suite. If you need a license other than GPL or BSD, just ask.

[netllama]

I'm not really clear on what the expected & actual behavior is supposed to be for your test app. Can you please define it?

However, when I build & run your app, it fails immediately with:
ERROR: Function <glutCreateWindow> called without first calling 'glutInit'

Also, does this bug reproduce in 1.0-9625 or 1.0-8774?

And finally, please generate and attach an nvidia-bug-report.log.

Thanks,
Lonni

[EHeM]

Originally Posted by netllama

I'm not really clear on what the expected & actual behavior is supposed to be for your test app. Can you please define it?

Well, ideally it will simply output text summarizing details of success/failure and details of failures. Less ideally, it might momentarily open a window.

Originally Posted by netllama

However, when I build & run your app, it fails immediately with:
ERROR: Function <glutCreateWindow> called without first calling 'glutInit'

Oh, fun. Looks like there may be multiple flavors of the glut library floating around. I suppose the question is, how long until they diverge and someone comes up with a gluttony library that runs on top of the various glut libraries and makes them operate the same? That was mostly about keeping the initialization simpler and trying to avoid having glut actually open a window. Guess it needs the more complete initialization, revised version is attached.

Originally Posted by netllama

Also, does this bug reproduce in 1.0-9625 or 1.0-8774?

And finally, please generate and attach an nvidia-bug-report.log.

Those versions won't work on my current turkey of a playtime machine. Did try it a while ago with somewhere in the 85-87 series on a friend's machine and it showed up. A nvidia-bug-report.log isn't going to provide any additional useful information.

[netllama]

An nvidia-bug-report.log will provide useful information. Please attach one.

Thanks,
Lonni

[EHeM]

Originally Posted by netllama

An nvidia-bug-report.log will provide useful information. Please attach one.

No, it won't. This issue spans multiple hardware and software generations. I've noticed it in a lot of places. All that will do is demonstrate my playpen machine really needs to be replaced. Since you insist, I have provided it. I hope you've looked at the the revised bug2.c? Since it won't have the problem you were mentioning.

I've seen it on a GF7900GTX512 with somewhere in the 85-87 range driver. I'm unsure whether I tested it on SunOS^WSolaris. I've also seen in in Apple's OpenGL implementation. I fear the Mesa library is about the only implementation that deals with this situation in the manner I view as "correct".

One can argue that this is trivial to work around (it is) and therefore too trivial to fix. One can also argue that the vector being invalid takes precedence over the angle being zero. I've yet to find a definitive answer as to which view is correct. I'm inclined to be ivory tower and say that with a zero angle (or multiples of 360 for that matter), no matter the vector glRotate*() should be a NOP.