clusterizer: Implement experimental meshlet optimizer #673
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
So far we were mostly concerned with meshlet clustering from the perspective of treating meshlets as an unordered set of triangles; while this matches the computational and documented model, this may not be optimal for a given GPU. Notably, NVidia GPUs are much more sensitive to the order of triangles in the meshlet than to the number and fill percentage; so much so that from pure rasterization performance, scan may win over proper clustering because it implicitly generates a better order. We do not know the precise criteria / mechanism that NV GPUs use here but it helps to do locality optimization; most importantly, triangle order, but also reordering meshlet-local vertices helps a little bit. This change implements a simple meshlet optimizer; while this can also be achieved by running existing optimization algorithms (vcache / vfetch) on meshlet data, a custom optimizer is faster even when using unoptimized quadratic implementation, and may allow us to implement better locality reodering algorithms in the future assuming a small input patch. For now we just select the next triangle to maximize the number of shared vertices with the previous triangle; this results in a pseudo-strip order which seems reasonably optimal for NV; note that neither the hardware nor this algorithm is concerned with the specifics of edge matching as it doesn't seem to matter for performance.
Instead of looking for a triangle with 2 matches and falling back to 1 and 0, unify this and pick the triangle with maximum number of shared vertices, and early out if we found the best possible match.
Instead of only matching against the last triangle, match all previous triangles by tracking the delta between a given cache position; the delta is computed using 8-bit unsigned math so that overflows don't matter as much (there's still a collision between triangles 0 and 256 in the cache but that shouldn't affect the quality noticeably). Experimentally, a cutoff of 3 or 4 produce the same results on NVidia so use 3 for more conservative matching.
Mention this in README as a recommended post-processing step and add to meshlet processing pipeline for coverage.
Instead of tracking visited triangles, maintain an invariant where an increasing prefix of the triangle array is ordered properly. While it would be possible to maintain this by swapping the first triangle with the one we picked at every iteration, this distorts the selection order in an odd way that may reduce the quality of the generated sequence, and memmove is fairly fast in practice given that we've already scanned over the region we are about to move anyhow. This makes optimization ~40% faster while producing the same results.
Most of the code is fairly straightforward but some decisions may not be obvious so let's document them. Also renames newv[] to order[] for cleanliness.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
So far we were mostly concerned with meshlet clustering from the
perspective of treating meshlets as an unordered set of triangles; while
this matches the computational and documented model, this may not be
optimal for a given GPU.
Notably, NVidia GPUs are much more sensitive to the order of triangles
in the meshlet than to the number and fill percentage; so much so that
from pure rasterization performance, scan may win over proper clustering
because it implicitly generates a better order.
We do not know the precise criteria / mechanism that NV GPUs use here
but it helps to do locality optimization; most importantly, triangle
order, but also reordering meshlet-local vertices helps a little bit.
This change implements a simple meshlet optimizer; while this can also
be achieved by running existing optimization algorithms (vcache /
vfetch) on meshlet data, a custom optimizer is faster even when using
quadratic implementation, and may allow us to implement better locality
reodering algorithms in the future assuming a small input patch.
On NVidia RTX 4090, this change can result in up to 15% speedup when
workloads are raster-bound compared to just using
buildMeshlets; thegains are workload and mesh dependent. niagara sees a 5% speedup when
software triangle culling is disabled.