`spec@!opengl 3.2@gl-3.2-adj-prims` expects vertex order that doesn't seem to match the spec
I've been looking at this test on the v3d driver and noticed that failure is specifically caused the test expecting the vertex order to differ when the provoking vertex is changed. As far as I can tell from the spec the vertex order must always remain the same
Section 2.12 in the GL 3.2 spec (or section 11.3.1 in the GL 4.5 spec)
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.
Geometry shaders that operate on triangles with adjacent vertices are valid for the TRIANGLES_ADJACENCY and TRIANGLE_STRIP_ADJACENCY primitive types. There are six vertices available for each program invocation. The first, third and fifth vertices refer to attributes of the first, second and third vertex of the tri- angle, respectively. The second, fourth and sixth vertices refer to attributes of the vertices adjacent to the edges from the first to the second vertex, from the second to the third vertex, and from the third to the first vertex, respectively
and section 2.6 in GL 3.2 spec (or section 10.1.18 in the GL 4.5 spec)
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.
A triangle strip is a series of triangles connected along shared edges, and may be specified with mode TRIANGLE_STRIP. In this case, the first three vertices define the first triangle (and their order is significant). Each subsequent vertex defines a new triangle using that point along with two vertices from the previous triangle. If fewer than three vertices are specified, no primitive is produced. See figure 2.3. The required state consists of a flag indicating if the first triangle has been completed, two stored processed vertices, (called vertex A and vertex B), and a one bit pointer indicating which stored vertex will be replaced with the next vertex. The pointer is initialized to point to vertex A. Each successive vertex toggles the pointer. Therefore, the first vertex is stored as vertex A, the second stored as vertex B, the third stored as vertex A, and so on. Any vertex after the second one sent forms a triangle from vertex A, vertex B, and the current vertex (in that order)
Which seems to suggest the vertices passed to the geometry shader should always be passed in the order. That being said it doesn't seem that many drivers obey this order. Doing a git blame on the probe_xfb
functions there were two commits to update the function (0d43c23a & 644d70e9), that were made to make the test match what radeonsi & nvidia hardware were doing, but this behavior seems to violate the ordering defined in the spec as it changes based on the provoking vertex.