Ideas for later
Not built yet. Each one would reuse the same count, start and output rows, so they can slot in next to the examples.
Why the output must be compactoutline point
A "no compaction" toggle on any example: every thread writes to out[i], so culled items leave holes. A row of waves below shows the next step launching threads for the holes, which sit idle, and the draw count can't skip them. Switching back to compact removes the dead lanes.
Push vs pulloutline point
On LOD or Curves. Push: a 4-lane wave as a timeline, one lane loops 7 times while three go gray. Pull: one thread per output slot, each finding its object with a binary search on the start row, shown as a marker jumping along it. Every lane stays busy.
Order: an atomic counter vs the scanoutline point
Threads finish in random order and take counter++, so a re-run gives a different order. Then the 64-bit trick: one counter holding count | sum, each thread leaving with its slot and offset in one go. End on when order matters: two overlapping transparent quads swapping colors every frame, or a sort pass.
The count stays on the GPUoutline point
A CPU and GPU timeline: the CPU records one indirect draw without knowing the number, and the GPU fills it in. The bad version reads the count back, and the CPU stalls waiting for it.
Terrain quadtree LODnew example
Each level, a node is culled (0), kept as a patch (1) or split into 4 children for the next pass. The tree refines near the camera, and each level's list is the next level's thread row. Far Cry 5's terrain and Nanite's cluster hierarchy work this way.
Radix sort is repeated binningnew example
Sort a few numbers digit by digit with the binning table, once per digit. Order inside a bin must be kept here, which ties back to the order idea. Gaussian splatting sorts its tile copies this way.
Grass blades per tilenew example
Tiles near the camera spawn more blades, and blades are culled one by one. Close to LOD in structure; worth it mainly for a Ghost of Tsushima reference.