Does OpenGL guarantee that primitives in the vertex buffer will be drawn in order?

Question

I read the openGL specification, trying to find the answer to this question, with no luck. I am trying to find out if OpenGL guarantees that drawing calls, such as GLDrawElements or GLDrawArrays, will draw elements in exactly the order in which they appear in VBO, or if they are free to process fragments of these primitives in any order.

For example, if I have a vertex buffer with 30 vertices representing 10 triangles, each with the same coordinates. Will it always be that the triangle corresponding to the vertices 0, 1 and 2 will be displayed first (and, therefore, below); and the triangle corresponding to the vertices 28, 29, 30 should always be the last (and, therefore, from above)?

Answer 1

The specification very carefully defines the order for rendering everything. Arrays of vertex data are processed in order, which leads to the generation of primitives in a certain order. It is said that each primitive is rasterized in order, and then the primitives cannot be rasterized until the previous ones end.

Of course, that’s all, as OpenGL says it should behave. Implementations can (and do) deceive, rasterizing and processing several primitives at once. However, they will still abide by the “as if” rule. Therefore, they are cheating internally, but will still record the results , as if they were all performed sequentially.

So there is a specific order you can rely on. If you do not use shaders that perform incoherent memory accesses ; then all bets are disabled for recording shaders.

Answer 2

Despite the fact that they can be drawn in a different order and completed at different times, at the stage of the last stage of the raster operation, any mixing (or depth / stencil / alpha test, for that matter) will be performed in the order in which triangles have been released.

You can confirm this by editing some object using a mixing equation that does not commute, for example:

glBlendFunc(GL_ONE, GL_DST_COLOR); 

If the final contents of the framebuffer were written in the same random order as the primitives, then in this example you will see an effect similar to a Z-battle.

That's why he called the fragment shader (as opposed to the pixel shader), because it is not a pixel, but since after the fragment stage it has not yet been written to the framebuffer; only after the stage of the raster operation.