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