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: 2014-10-07 22:27 PDT (History)
2 users (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.
Comment 3 Stephen Huang 2014-10-07 22:27:22 PDT
From OPENGL ES3.1 + AEP point of view

Summary of the following findings:
1.	OPENGL ES3.1 GLSL: no PrimitiveID
2.	(AEP) Tessellation without GS: draw command generates primitiveID
3.	(AEP) Tessellation with GS: GS needs to generates new primitiveID, otherwise undefined.
4.	No tessellation and no GS: we don’t need to support primitiveID in FS. (because ES3.1 GLSL has no PrimitiveID) 
5.      I don't see that primitiveID can be generated by TCS or TES.



From AEP point of view:

EXT_geometry_shader:


gl_PrimitiveIDIn, which is not an array and has no vertex shader
    equivalent. It is filled with the number of primitives processed 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 triangle
    primitive is processed. For triangles drawn in point or line mode, the
    primitive ID counter is incremented only once, even though multiple
    points or lines may be drawn. Restarting a primitive topology using the
   primitive restart index has no effect on the primitive ID counter.

gl_PrimitiveID is filled with a single integer that serves as a
    primitive identifier to the fragment shader. This is then available to
    fragment shaders, which will select the written primitive ID from the
    provoking vertex of the primitive being shaded. If a fragment shader
    using gl_PrimitiveID is active and a geometry shader is also active, the
    geometry shader must write to gl_PrimitiveID or the fragment shader
    input gl_PrimitiveID is undefined. See section 11.1gs.4 "Geometry Shader

The built-in output gl_PrimitiveID holds the primitive ID counter read
    by the fragment shader, replacing the value of gl_PrimitiveID generated
    by drawing commands when no geometry shader is active. The geometry
    shader must write to gl_PrimitiveID for the provoking vertex (see
    section 12.3) of a primitive being generated, or the primitive ID
    counter read by the fragment shader for that primitive is undefined.


    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.

    Restarting a primitive using the primitive restart index (see section
    10.3.4) has no effect on the primitive ID counter.

    gl_PrimitiveID is only defined under the same conditions that
    gl_VertexID is defined, as described under "Shader Inputs" in section
    11.1.3.9.


EXT_tessellation_shader:


The variable gl_PrimitiveID is filled with the number of primitives
        processed 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 triangle primitive is processed. Restarting a
        primitive topology using the primitive restart index has no effect
        on the primitive ID counter.

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 tessellation control shaders.

gl_PrimitiveID contains the number of primitives processed by the
    shader since the current set of rendering primitives was started.

gl_PatchVerticesIn and gl_PrimitiveID are defined in the same fashion as
    the corresponding input variables in the tessellation control shader.

Stephen Huang