Khronos Public Bugzilla
Bug 754 - Meaning of gl_PrimitiveID in TES
Meaning of gl_PrimitiveID in TES
Status: NEW
Product: OpenGL
Classification: Unclassified
Component: API Specification
4.4
All All
: P3 normal
: ---
Assigned To: Pat Brown
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-11-21 21:07 PST by Alfonse
Modified: 2013-08-08 12:52 PDT (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Alfonse 2012-11-21 21:07:02 PST
In the Tessellation Evaluation Shader, it is unclear what gl_PrimitiveID refers to. The 4.3 specification says:

> The variables gl_PatchVerticesIn and gl_PrimitiveID are filled
with the number of the vertices in the input patch and a primitive number,
respectively. They behave exactly as the identically named inputs for tessel-lation control shaders.

In the TCS section, it says:

> The variable gl_PrimitiveID is filled with the number of primitives pro-cessed by the drawing command which generated the input vertices. The
first primitive generated by a drawing command is numbered zero, and the
primitive ID counter is incremented after every individual point, line, or tri-angle primitive is processed. Restarting a primitive topology using the prim-itive restart index has no effect on the primitive ID counter.

This makes sense in the context of a TCS. This makes much less sense in the context of a TES, because patches can be discarded by the tessellation primitive generator. Are discarded patches counted by the gl_PrimitiveID or not?
Comment 1 Alfonse 2013-07-25 16:54:03 PDT
The 4.4 specification did not seem to clear this up. Does "primitive is processed" mean processed by the TCS or processed by the TES?
Comment 2 Pat Brown 2013-08-08 12:52:19 PDT
The intent is that the primitive ID in TES is the number of the patch from which the primitive was produced.  When TCS is present, it will take an input patch (from the API) and produce a new output path -- that output patch should be considered to have the same primitive ID number as the input patch for the purposes of this test.  If a patch is consumed by the tessellation primitive generator, it should still be counted.

This is definitely worth clarifying.