Disposition of fragment shader gl_PrimitiveID in unusual circumstances

[NicolBolas]

The fragment shader definition for gl_PrimitiveID is as follows:

GLSL 4.6:

The input variable gl_PrimitiveID is filled with the value written to the gl_PrimitiveID geometry
shader output, if a geometry shader is present. Otherwise, it is filled with the number of primitives
processed by the shader since the current set of rendering primitives was started.

OpenGL 4.6 is a bit more specific:

If a geometry shader is active, the built-in variable gl_PrimitiveID contains the ID value emitted by the geometry shader for the provoking vertex. If no geometry shader is active, gl_PrimitiveID contains the number of primitives processed by the rasterizer since the last drawing command was called. The first primitive generated by a drawing command is numbered zero, and the primitive ID counter is incremented after every individual point, line, or polygon primitive is processed. For polygons drawn in point or line mode, the primitive ID counter i incremented only once, even though multiple points or lines may be drawn.

Let's assume that there is no GS present. The above says "the primitive ID counter is incremented after every individual point, line, or polygon primitive is processed". But "processed" by what exactly? The sentence starts by talking about the "drawing command" being the first primitive. But the previous sentence talked about primitives processed by the rasterizer. Which one is being looked at here? Tessellation generates more primitives than are being input, so it matters.

Also, there is a question of how this behaves with instancing and multi-draw. Does starting a new instance count as a "drawing command" for this purpose? In Vulkan, it explicitly says that it does (starting an instance resets the counter).

[NicolBolas]

It should also be noted that the Vulkan definition does not include any mention of the rasterizer. So when it says "is processed", that can only refer to what gets read into the system.

[pdaniell-nv]

This issue looks just like an issue that was reported internally: https://gitlab.khronos.org/opengl/API/issues/105.

I'm sure the "processed by the rasterizer" part is wrong. We're discussing internally and I'll report back when we have a conclusion.