I find myself researching tessellation again and really don’t understand the following statement in the specs regarding the gl_PrimitiveID input of the tessellation control stage:
This would be fine, if draw calls were actually allowed to specify the primitive types POINTS, LINES or TRIANGLES when tessellation is active. How does the above statement bare any correctness when there are only patches used as tess control inputs? Is gl_PrimitiveID simply the patch number then?
Furthermore the GLSL spec states:
This also looks like the variable simply refers to the current patch being processed. Correct?
I’m confused. What am I missing? Have I found a spec bug?
It does sound like a spec bug. Based on the current language, I would assume that gl_PrimitiveID contains the primitive index submitted from the draw command, but in that case patches should be listed as one of the primitives that increment the counter.
Just tried it with a single patch consisting of 4 vertices. In the TES, gl_PrimitiveID is always 0 - so I guess my suspicion was correct.
BTW, aqnuep, I got some hideous system freezes and SEGFAULTs with the current Linux beta Catalyst. The bug tracker, however, seems to be abandoned as 71/72 bugs have not even been assigned to a maintainer yet. Do you have some advice?
A GL_PATCH is a primitive type. It is, in terms of gl_PrimitiveID, no different from points, lines, or triangles. So the language seems fine. A patch is a primitive. So gl_PrimitiveID is the 0-based index of the primitive currently being processed.
Yes, it’s a primitive type and as I stated above, I already suspected that the ID counted against the current patch. But I suggest that lines, points and triangles should not be mentioned in a section about tessellation control shaders, where no such primitive type is allowed as input.
The bug tracker, however, seems to be abandoned as 71/72 bugs have not even been assigned to a maintainer yet. Do you have some advice?