meshopt_optimizeVertexCache() and per-triangle data

[theagentd]

Hello!

I have recently been using meshoptimizer at my day job, and have been very impressed by its results. Now I wish to use it in my side project, specifically for optimizing the vertex cache hit rate of my voxel models.

To maximize the vertex processing performance of my voxel models, I have reduced them to a mere 3 bytes each, just an 8-bit unsigned integer 3D position. The normal and texture projection data is then stored per triangle instead, which I then read in the fragment shader using gl_PrimitiveID. Unfortunately, this kind of per-triangle seems to be somewhat incompatible with meshopt_optimizeVertexCache(), as the triangles end up being reordered, but my per-triangle data remains the same as before. While I could in theory build my own remapping by matching triangles in the original and reordered index buffers, this would be a bit slow.

Is there any functionality in meshoptimizer that I've missed that would allow me to reorder the per-triangle data together with the triangles in the index buffer?

[zeux]

There isn't a way to do this out of the box. Probably remapping the triangle data with a hash map after the function completes is the best option here; optimizeVertexCache keeps the order of indices in the triangle consistent I believe, so you can just key the hash map by the index triple.

Not directly related, but beware: using gl_PrimitiveID in fragment shader on all NVidia hardware (and early AMD GPUs, but that's less of a concern because they aren't as common) is not great for performance. It switches the pipeline to some sort of alternate mode of operation that is a little similar to their FastGS feature, and results in a reduced rate of geometry processing. Of course you may not necessarily have a good alternative option, and if your terrain is voxel based a-la Minecraft (each quad is using separate normals/triangles), then the penalty is not as high as it is in the general case, although in that case vertex cache optimization is also less important. For smooth shading / isosurface meshing it can be a problem.

[theagentd]

There isn't a way to do this out of the box. Probably remapping the triangle data with a hash map after the function completes is the best option here; optimizeVertexCache keeps the order of indices in the triangle consistent I believe, so you can just key the hash map by the index triple.

I see. Since I'm using 16-bit indices, I suppose I can pack the three indices into a 64-bit uint and use that as the hashmap key. I will at some point run some tests with this.

Would you be willing to consider adding a new version of the functions that reorder index buffers that produce an additional per-triangle remapping buffer? If so, I can create an issue for it. I believe that this could be useful for many others as well for various rendering techniques.

Not directly related, but beware: using gl_PrimitiveID in fragment shader on all NVidia hardware (and early AMD GPUs, but that's less of a concern because they aren't as common) is not great for performance. It switches the pipeline to some sort of alternate mode of operation that is a little similar to their FastGS feature, and results in a reduced rate of geometry processing.

In my tests, reading the texture projection data (which can be used to compute the normal as well) in the fragment shader based on gl_PrimitiveID allows me to deduplicate corners and makes the vertex processing over 3x faster, as it essentially allows me to use a "shadow" index buffer for all my rendering. I saw a major speedup on all GPUs when implementing this.

Of course you may not necessarily have a good alternative option, and if your terrain is voxel based a-la Minecraft (each quad is using separate normals/triangles), then the penalty is not as high as it is in the general case

My voxel renderer merges neighboring quads into complex polygons, which are then optimally triangulated into a triangle mesh, so it's not as naive and inefficient as Minecaft. This means that every vertex is always a corner which is used by triangles aligned with all 3 planes, making these optimizations critical and very impactful. Without using gl_PrimitiveID, I would only be able to reuse vertices within each polygon.

although in that case vertex cache optimization is also less important. For smooth shading / isosurface meshing it can be a problem.

I'm not sure what you are referring to here. Even small optimizations for the vertex cache seems to have a major impact in my tests.

[zeux]

allows me to deduplicate corners

Yeah, as I noted in some cases, and it sounds like this is a case like that, you don't have a great alternative vs relying on gl_PrimitiveID. The penalty on NVidia GPUs I mentioned is relative to a fully indexed mesh with no duplication of corners, so it makes sense that you'd see a speedup. There it might still be worth it to avoid implicit primitive id and use provoking vertex optimization instead, but either way it sounds like you more or less need an approach that you're using.

can create an issue for it

Feel free to create an issue. There are many functions in meshoptimizer that reorder the index buffer without generating a triangle remap table; I'm not sure that I want to duplicate the interface for each one or have a separate function that creates a remap table based on old & new index buffers, or select a subset of functions where the remap table is most useful, but either way creating an issue would make it easier for others who might have a similar need to notice it and comment on it. I don't want to make any specific changes here this year anyway so for now an external hash based remap is probably the best approach.

[theagentd]

Excellent, thanks a lot for the responses. I will create an issue for the remapping when I have had some time to figure out what the cost of the hash-based solution is.

Regarding gl_PrimitiveID, the reordering needed to try it would be quite complicated to implement for me at the moment. I will hopefully be able to experiement with mesh shaders soon, which would avoid this issue, but until then, is there any additional information on this slowdown on Nvidia? I would love to read up on it more and will at least try to measure the overhead to see what the potential win could be.

[zeux]

The performance issues are described in this talk https://advances.realtimerendering.com/s2024/content/Hable/Advances_SIGGRAPH_2024_VisibilityVRS-SIGGRAPH_Advances_2024.pptx (the algorithm described there is implemented in meshoptimizer, see https://meshoptimizer.org/#visibility-buffers). I don't know to what extent this helps for your specific use case of course, as this talk describes a more traditional mesh rendering situation and not a specialized way to store per-triangle data.