Relax requirements for gl_VertexID and gl_PrimitiveID with immediate-mode drawing

[ianromanick]

When an application uses immediate-mode drawing commands, the OpenGL implementation must buffer vertices submitted. The OpenGL specification does not place limits on the number of vertices that may be submitted between glBegin and glEnd, but the buffers used to store that data will have finite size. When the buffer becomes full, the implementation may need to split the primitive. On some implementations, this buffer may be relatively "small" only allowing a thousand or so vertices per batch.

Splitting the primitive will cause gl_VertexID and gl_PrimitiveID to have observably incorrect values, but the specification does not strictly allow this. The alternative, which is allowed by the specification, is to generate GL_OUT_OF_MEMORY. That seems... rude.

Instead, we propose two alternatives:

1. Simply make gl_VertexID and gl_PrimitiveID (and gl_PrimitiveIDIn for geometry shaders) undefined with immediate-mode drawing.
2. Add some language that says something to the effect, "after some implementation defined limit (which may be arbitrarily small), gl_VertexID and gl_PrimitiveID may reset to zero."

This first is cleaner, but it is more broad than necessary. The second introduces (effectively untestable) implementation-dependent behavior.

[ianromanick]

There's probably a similar issue on many implementations for GL_LINE_STRIP and the line stipple pattern.

[marekolsak]

Also consider this:

for (...) {
   glBegin(GL_LINES);
   glVertex3f(...);
   glVertex3f(...);
   glEnd();
}

We can't have correct gl_VertexID and gl_PrimitiveID even without display lists if we want drivers to process that loop and generate 1 big draw where those variables don't reset to zero. (that's for performance; separate draws would be abysmally slow)

[marekolsak]

I think we can support gl_VertexID and gl_PrimitiveID with immediate mode glBegin/End if we disable draw merging when those variables are being used.