2

For instance, if a glDraw* call drawing GL_TRIANGLES reads a set of VBOs that specify vertices A, B, C, D, E, and F in that order, then one would expect that in one invocation of the geometry shader, the following would be true:

  • gl_in[0] describes A
  • gl_in[1] describes B
  • gl_in[2] describes C

And one would expect that in the other invocation, the following would be true:

  • gl_in[0] describes D
  • gl_in[1] describes E
  • gl_in[2] describes F

And so forth.

But I don't see that being clearly guaranteed in any documentation I'm finding. I suppose that if the vertices were arbitrarily reordered by OpenGL in a way that changed their CW/CCW ordering, then a lot of people's normal-finding code (and other such things) would probably be failing. But maybe something like this would be allowed, for instance:

  • gl_in[0] describes B
  • gl_in[1] describes C
  • gl_in[2] describes A

Can OpenGL do that reordering, or is it guaranteed not to?

mjwach
  • 1,174
  • 2
  • 9
  • 25

1 Answers1

3

I'm using the OpenGL 4.5 core profile specification here, but what I say is basically true also for earlier versions. The exact wording (and the locations of the statements) might be different for earlier versions (especially before 4.3, as the spec was totally reorganised in that version).

From section 2.1 "Execution Model" (my emphasis):

Primitives are defined by a group of one or more vertices. A vertex defines a point, an endpoint of a line segment, or a corner of a polygon where two edges meet. Data such as positional coordinates, colors, normals, texture coordinates, etc. are associated with a vertex and each vertex is processed independently, in order, and in the same way. The only exception to this rule is if the group of vertices must be clipped so that the indicated primitive fits within a specified region; in this case vertex data may be modified and new vertices created. The type of clipping

This basically already guarantees that it can not re-order the vertices. However, we can find more specific language for that. Let's concentrate on the example case of triangles for now. Section 10.1.8 "Separate Triangles" states

Separate triangles are specified with mode TRIANGLES. In this case, the 3i + 1st, 3i + 2nd, and 3i + 3rd vertices (in that order) determine a triangle for each i = 0; 1;...; n - 1, where there are 3n + k vertices drawn. k is either 0, 1, or 2; if k is not zero, the final k vertices are ignored. For each triangle, vertex A is vertex 3i and vertex B is vertex 3i + 1. Otherwise, separate triangles are the same as a triangle strip.

So it is absoultely clear what order the vertices of a triangle are. So let's get to geomerty shaders in section 11.3:

After vertices are processed, they are arranged into primitives, as described in section 10.1.

The order defined above is completely relevant here. Now the part about triangles from section 11.3.1 "Geometry Shader Input Primitives":

Triangles (triangles)

Geometry shaders that operate on triangles are valid for the TRIANGLES, TRIANGLE_STRIP and TRIANGLE_FAN primitive types. There are three vertices available for each program invocation. The first, second and third vertices refer to attributes of the first, second and third vertex of the triangle, respectively.

This together with the quote from section 10.1.8 makes it pefrectly clear that the exact order from the draw call is gauranteed to appear in each geometry shader invocattion.

However, the order of different geometry shader invocations is of course undefined, as stated in section 7.12.1 "Shader Memory Access Ordering":

The relative order of invocations of the same shader type are undefined. A store issued by a shader when working on primitive B might complete prior to a store for primitive A, even if primitive A is specified prior to primitive B. This applies even to fragment shaders; while fragment shader outputs are always written to the framebuffer in primitive order, stores executed by fragment shader invocations are not.

But this is what's to be expected from a parallel architecture anyway, so no surprises here.

derhass
  • 43,833
  • 2
  • 57
  • 78