Peter McGuinness (peter.mcguinness.delete@this.gobrach.com) on August 2, 2016 9:41 pm wrote:
> [...] It only looks like regular tiling because all the triangles are huge
> and are all directly on top of each other; scatter randomly sized triangles around the screen in random locations
> and you will soon see the apparent order break down. In fact, you only need to shift each triangle by one pixel
> to see this start to happen. The point is that the 'tiling' is relative to the triangles, not to the screen
> and the term 'tile based' is universally accepted to refer to a tiled screen.

That's not what I see. I changed the test code to say:

if (VertexID % 3 == 0)
  output.Position = float4(-1, 1, 0, 1);
else if (VertexID % 3 == 1)
  output.Position = float4(-0.9, 1, 0, 1);
else if (VertexID % 3 == 2)
  output.Position = float4(-1, 0.9, 0, 1);

output.Position.x += 0.05 * ((VertexID / 3) % 32);
output.Position.y -= 0.05 * ((VertexID / 3) / 32);

so it's drawing lots of small triangles across the screen, ordered from left to right, top to bottom. I scaled MaxNumPixels appropriately and set "number of triangles" to 1000.

On a GTX 970 (Maxwell), it first pixel-shades all the triangles in the top-left 256x512 pixel region of the screen (clipped to that region). Once those are finished, it moves right to the next 256x512 region. Then it carries on until it wraps around to the second row of regions.

That means it's rasterising in a very different order to how the triangles were submitted. And it's reordering them to keep all its framebuffer accesses within a ~0.5MB region, suggesting it wants to fit in a cache of that size.

If I increase "num floats per vertex" to 32, and also change the vertex shader to set "output.ExtraFloats[i] = VertexID * NUM_EXTRA_FLOATs + i;" (the +i is to avoid compression of identical values), the behaviour is very different - that's much closer to (though not exactly the same as) the original submission order (i.e. left-to-right for a single whole row of triangles (or sometimes ~3 rows at once), then down to the next row). That indicates the reordering only works within a smallish buffer of primitive data - exceeding that limit means it has to flush out the earlier-submitted triangles first to make space, instead of collecting enough to fill the whole 0.5MB region, so it loses some efficiency.

> In any case, OpenGL and DX rules forbid the re-ordering of triangles and it is up to the application
> to group geometry to be cache friendly.

I'm not sure how GL/DX phrase it, but Vulkan explicitly only requires the implementation to follow API order between the framebuffer operations for a given sample position. There's nothing to stop it processing two different triangles at two different sample positions in any arbitrary order, since that will have no observable effect on the rendering (at least until the pixel shaders start doing weird things with atomics to demonstrate that order).

If there was a restriction that triangles must be processed completely sequentially, so you couldn't start pixel shaders for one until the previous one had been completely shaded, that'd also prevent any concurrent shading of two non-overlapping triangles, so there's no way they can realistically have that restriction.