<p>Your first question seems a bit philosophical, but I think the reason is to make a distinction between the actual mesh and the optimized triangle groups (meshlets) to facilitate talking about them.
I looked at (<a href="https://developer.nvidia.com/blog/introduction-turing-mesh-shaders/" rel="nofollow noreferrer">https://developer.nvidia.com/blog/introduction-turing-mesh-shaders/</a>) and from what I read I think meshlets contain the same amount of data.</p>
<p>Meshlets can be compared to wavelets, which describe functions in both frequency and time space. So it &quot;divides&quot; the function into parts that correspond to different sizes and positions. There is a similarity between the weighted wavelets (ie the projection of a function on that particular wavelet) and meshlets (group of triangles) that form the complete mesh, if that is what you mean by implementation.</p>

CC BY-SA 4.0
2023-02-12T10:04:38.307Z
2023-02-12T10:04:38.307Z
Mathis
<p>A &quot;meshlet&quot; is a concept built around the specific architecture of how shaders work.</p>
<p>Shaders are invoked in work groups, even when shader stages don't explicitly represent that concept in the API. This means that some number of invocations are executed in lock-step with each other on the same core. That's the natural way they work.</p>
<p>In theory this could allow different invocations in the same work group to share data. This is what compute shaders and tessellation control shaders do with <code>shared</code> and <code>out</code> variables respectively.</p>
<p>However, the nature of the traditional vertex processing pipeline makes this data sharing difficult. The order of execution of vertex shaders, which invocations go into which work groups, can change based on how indices are processed, the state of the post-T&amp;L vertex cache, etc. It is not reliable, and therefore you cannot really share information between VS invocations.</p>
<p>The <a href="https://registry.khronos.org/OpenGL/extensions/NV/NV_mesh_shader.txt" rel="noreferrer">mesh shader</a> pipeline is designed to more directly mirror hardware. In this pipeline, there are no equivalents to vertex attributes; if you want to get some vertex data, the shader must use SSBOs or similar tools to fetch them. That is, everything is up to you.</p>
<p>The goal here is to process meshes in work groups. For a mesh of a given size, you execute some number of work groups on that mesh, with each group having some number of invocations that can share data between them.</p>
<p>However, since work group sizes and shared storage is finite and quite small, it is reasonable for a work group to only operate on a portion of the mesh rather than the whole thing. To do this, the mesh needs to be broken down into appropriately sized chunks. We call these chunks &quot;meshlets&quot;.</p>

CC BY-SA 4.0
2023-02-13T18:52:47.207Z
Thank you for the answer!  I'll be trying to play around with this sort of thing soon and hopefully that will better illuminate things to me.

As a quick follow-up... it sounds like then that a Meshlet truly is "identical" to a Mesh as a data structure.

As such implementation wise, would it be sensible to literally partition a mesh, splitting its vertex data/faces into multiple new meshes (the meshlets)?  Or are the meshlets some simpler structure that references a parent Mesh in some way that persists after their creation?
Chris Gnam
CC BY-SA 4.0
2023-02-12T15:23:08.710Z
2023-02-12T15:23:08.710Z
Nicol Bolas
<p>Obviously, conceptually, a meshlet <em>is</em> just a small mesh.  But what is the reason for making the distinction then?  I'm assuming it has to do with how they are implemented.</p>
<p>In a meshlet architecture, does a parent mesh contain the complete vertex buffer while the meshlets contain their individual index buffers?  Or do meshlets contain more (or possibly less?) data than that?</p>
<p>I can understand the benefits of being able to act on small clusters of geometry for culling/clipping/shading, and they seem incredibly powerful with LoD techniques such as those found in Nanite.  But im a bit unclear as to what, implementation wise, is actually meant by &quot;meshlet&quot;.  Or if there is even a standard at all.</p>

<rendering><mesh><gpu><rasterizer>
What is the difference between a "meshlet" and just a small mesh?
Chris Gnam
# What is the difference between a "meshlet" and just a small mesh?

(Asked by: username_0 on 2023-02-12)

Obviously, conceptually, a meshlet *is* just a small mesh. But what is the reason for making the distinction then? I'm assuming it has to do with how they are implemented.

In a meshlet architecture, does a parent mesh contain the complete vertex buffer while the meshlets contain their individual index buffers? Or do meshlets contain more (or possibly less?) data than that?

I can understand the benefits of being able to act on small clusters of geometry for culling/clipping/shading, and they seem incredibly powerful with LoD techniques such as those found in Nanite. But im a bit unclear as to what, implementation wise, is actually meant by "meshlet". Or if there is even a standard at all.

**Tags:** rendering, mesh, gpu, rasterizer


---

## 2 answers

### Answer by username_2 on 2023-02-12. Score: 6 | Accepted answer

A "meshlet" is a concept built around the specific architecture of how shaders work.

Shaders are invoked in work groups, even when shader stages don't explicitly represent that concept in the API. This means that some number of invocations are executed in lock-step with each other on the same core. That's the natural way they work.

In theory this could allow different invocations in the same work group to share data. This is what compute shaders and tessellation control shaders do with `shared` and `out` variables respectively.

However, the nature of the traditional vertex processing pipeline makes this data sharing difficult. The order of execution of vertex shaders, which invocations go into which work groups, can change based on how indices are processed, the state of the post-T&L vertex cache, etc. It is not reliable, and therefore you cannot really share information between VS invocations.

The [mesh shader](https://registry.khronos.org/OpenGL/extensions/NV/NV_mesh_shader.txt) pipeline is designed to more directly mirror hardware. In this pipeline, there are no equivalents to vertex attributes; if you want to get some vertex data, the shader must use SSBOs or similar tools to fetch them. That is, everything is up to you.

The goal here is to process meshes in work groups. For a mesh of a given size, you execute some number of work groups on that mesh, with each group having some number of invocations that can share data between them.

However, since work group sizes and shared storage is finite and quite small, it is reasonable for a work group to only operate on a portion of the mesh rather than the whole thing. To do this, the mesh needs to be broken down into appropriately sized chunks. We call these chunks "meshlets".

> **Comments:**
> **username_0**: Thank you for the answer!  I'll be trying to play around with this sort of thing soon and hopefully that will better illuminate things to me.  As a quick follow-up... it sounds like then that a Meshlet truly is "identical" to a Mesh as a data structure.  As such implementation wise, would it be sensible to literally partition a mesh, splitting its vertex data/faces into multiple new meshes (the meshlets)?  Or are the meshlets some simpler structure that references a parent Mesh in some way that persists after their creation?  

---

### Answer by username_1 on 2023-02-12. Score: 0

Your first question seems a bit philosophical, but I think the reason is to make a distinction between the actual mesh and the optimized triangle groups (meshlets) to facilitate talking about them.
I looked at (<https://developer.nvidia.com/blog/introduction-turing-mesh-shaders/>) and from what I read I think meshlets contain the same amount of data.

Meshlets can be compared to wavelets, which describe functions in both frequency and time space. So it "divides" the function into parts that correspond to different sizes and positions. There is a similarity between the weighted wavelets (ie the projection of a function on that particular wavelet) and meshlets (group of triangles) that form the complete mesh, if that is what you mean by implementation.


---

