LOD detail about niagara HOT 2 CLOSED

If lod.meshletOffset is not divisible by 32, can we still derive the correct meshlet index in task shader?

So with the current structure meshlet offsets are rounded to 32, but it doesn't have to be the case - this just made sense to me when I was writing the code, but you can keep firstTask as 0 and derive the index of the meshlet yourself if you pass meshletOffset via a separate field in MeshDrawCommand that's not part of VkDrawMeshTasksIndirectCommandNV. Then in the task shader you just need to read the meshlet data using the computed meshlet index that uses the offset read from drawCommands[gl_DrawIDARB]. This should be a simple change, it just was easier to pad the data and use firstTask.

Is it possible to compute LOD level in task shader, as described in this NVIDIA blog?

This is a bit more difficult because it requires restructuring the code and may have performance implications. What happens right now is that the task shader is ran for every meshlet, with one thread in the task shader producing one meshlet - or not producing one, because the task shader runs the culling. If you don't do the culling - you can run a thread of the task shader per object, which I suspect is what the NV demo is doing, and there cull the object, select the LOD and leave the rest to the mesh shader. The mesh shader would need to cull meshlets and then transform vertices / output triangles.

The problem with this approach is that you need to span as many meshlet threads as you have meshlets times 32 or some amplification factor like that, because you want the number of threads to closely track number of vertices/triangles in the entire object, to make transformation and index output efficient.

This is completely fine if you don't cull individual meshlets. However, this renderer culls individual meshlets using the meshlet cone, and really could also cull using frustum and also do per-meshlet occlusion checks, I just didn't get to that.

To keep these checks efficient is difficult with that approach. The approach taken by the current code maximizes the degree of parallelism during culling (by running culling in the task shader) and maximizes the degree of parallelism during meshlet transform/output (by running that in the mesh shader). A different structure feels like it will be less performant if you want do cull individual meshlets.

If you don't - it doesn't matter, but then you lose a big part of the attraction of mesh shaders.

from niagara.

Sorry for my late reply. As far as I know, there are three ways to implement dynamic LOD with mesh shader:

1. Spawn a workgroup per object in task shader, with workgroup size is 1. Then compute LOD, and spawn a workgroup per meshlet in mesh shader.
2. Spawn a thread per object in task shader, with workgroup size is 32. Then compute LOD for each object and accumulate total number of meshlet in each workgroup. Finally, still spawn a workgroup per meshlet in mesh shader.
3. Combine indirect draw and task/mesh shader, as you did on stream.

The 1st method is OK and easy to implement, but it does not take the full advantage of parallelism of task shader. The 2nd method is fully parallelized, however, computing meshlet index in mesh shader is complicated and the number of task spawn by a task shader workgroup may exceed the hardware limit (which is 65536 on my machine). The 3rd method is fine, but synchronization is need between compute shader dispatch and mesh shader draw call.

To compare the performance for 2nd and 3rd methods, I did a test in a rough scene (with just a large amount of high-poly meshes), and find that the GPU frame time of 3rd method (80.1ms) is much less than 2nd method (118.2ms). Both methods should be fully parallelized, I am wondering where is the performance benefit comes from for 3rd method.

from niagara.