I may be barking up the wrong tree here, but I'm trying to debug the
cause of a 502 error ( GL_INVALID_OPERATION ) from glDrawElements() in
drawprim.c (line 1251).  This is for Civilization 4 using both
hardware vertex & pixel shaders.  I've only noticed this error when it
is passed GL_TRIANGLES with a large number of vertices.

Here's a sample output with a little extra debugging info, and cleaned
up a little:

trace:d3d_draw:primitiveToGl TRIANGLES
trace:d3d_draw:drawPrimitiveDrawStrided begin number of indices6144,
number of vertices1156
trace:d3d_draw:drawPrimitiveDrawStrided end number of indices6144,
number of vertices1156
...
trace:d3d_draw:drawPrimitiveDrawStrided Using pixel shader
trace:d3d_draw:drawPrimitiveDrawStrided
glBindProgramARB(GL_FRAGMENT_PROGRAM_ARB, pixelShader->prgId); call ok
drawprim.c / 1846
trace:d3d_draw:drawPrimitiveDrawStrided
glEnable(GL_FRAGMENT_PROGRAM_ARB); call ok drawprim.c / 1850
trace:d3d_draw:drawStridedFast (0x7fd98890) : glElements(4, 6144, 0, ...)
fixme:d3d_draw:drawStridedFast >>>>>>>>>>>>>>>>> 502 from
glDrawRangeElements @ drawprim.c / 1251

Often, a series of these errors will result in an unhandled exception
in libglcore.so.1 (nvidia binary 8178 driver for a 6600GT, 2.6.16.1
kernel).

I read up on the glDrawElements() function and it refered to the
GetIntegerv() function for GL_MAX_ELEMENTS_VERTICES.   When I call
that function, it returns 4096, and the number of vertices that it's
trying to pass is larger than that.  I've tried doing a min() of the
max and the actual # of vertices, but the results are the same.

So, the question is:  Could this be one of the causes of the graphical
glitches I'm seeing?  I can toy around with these functions all day,
but I don't really understand them all that well.  Does that routine
need to be reworked to split up a D3DPT_TRIANGLELIST into multiple
calls if the calculated number of vertices/indices is too high for the
user's graphics card?  Or, am I way off base thinking this has any
bearing on my real issues?

Thanks,
Jason