[[N.B.:  the problem below seems to be fixed in the NVidia 0.9-6 drivers. ]]
From slevy Fri Oct  6 21:03:49 2000
To: Greg Humphreys <humper@Graphics.Stanford.EDU>
Subject: Re: wiregl 1.1 :-) :-(
Cc: rstein@ncsa.uiuc.edu, wiregl@Graphics.Stanford.EDU

Greg Humphreys wrote:

> Recently overheard from Stuart Levy:
> > 
> > There were 262 glVertex3f's in the block -- not a multiple of 3! --
> > and of course there's this dangling glNormal3f().
> 
> Yes, this is how begin/end pinching works in WireGL.  According to the OpenGL
> spec and man pages, "trailing" vertices like this are simply not drawn and
> discarded.  I could certainly believe that some implementations of OpenGL
> didn't quite get this corner case right.
> 
> Have you been able to reproduce the breakage with a simple OpenGL program
> that specifies a 'wrong' number of vertices after a glBegin(GL_TRIANGLES)?
> We could send that to our contacts at NVIDIA and get it cleared up tout
> de suite.

I tried a simple test case in another app that wrote a pile of GL_TRIANGLES,
adding various combinations of glVertex3f() and glNormal3f()s, and
couldn't make it fail, no matter whether sent locally nor via wireGL.
But I'm sure the GL state wasn't the same.  OK, I can enable GL_LIGHTING,
but how to get all the other state bits, material/lighting values,
etc. to match??

I could catch the bad state in the debugger and give some
machine-instruction sequences in the loop that it gets into.  Do you
suppose that'd help the NVidia authors?  The GL library/X server doesn't
crash, it just gets into an infinite loop, a few levels down from
the glEnd() call.  E.g. the stack trace reads:

#0  0x4043b83e in __glNVCpuClear () from /usr/lib/libGLcore.so.1
#1  0x4043f55d in __glNVCpuClear () from /usr/lib/libGLcore.so.1
#2  0x4043f9e4 in __glNVCpuClear () from /usr/lib/libGLcore.so.1
#3  0x4043d674 in __glNVCpuClear () from /usr/lib/libGLcore.so.1
#4  0x40442c1d in __glNVCpuClear () from /usr/lib/libGLcore.so.1
#5  0x804d763 in __decodeEnd () at current.c:44
#6  0x8052212 in wireGLRenderRemoteStreams () at stream.c:511
 ...

The function at __glNVCpuClear+368664 (0x4043b81c for me)
is one that it seems to keep re-calling, via some jump table,
in the inner loop.  I also catch it in __glNVModeSwitchTestForComplete.
And this is using the 0.9-5 libGL bundle.

   Stuart