Comment by tinco | Hacker News Reader

Comment by tinco | Hacker News Reader

Am I understanding mesh shading correctly if I'm explaining it like this?

In the traditional rendering pipeline you unpack triangles on the CPU, and then send them to the GPU, which then maps them to screenspace and then shades in the pixels to the screen buffer.

Because of modern demands we're wanting to render insane amounts of triangles.

Mesh shaders alleviate some of the bottlenecks by being a step in the pipeline on the GPU before the other steps that can generate triangles. So for example you could upload a smaller amount of triangles to the GPU, and have the mesh shaders refine that geometry by procedurally fill in the details. You could even send it not even triangles but for example the locations where you want grass, and the direction of the wind or whatever and have the mesh shaders generate all of the grass geometry.

Excuse the laymanny language, I'm just a casual observer and have imprecise memory. The tech is cool though, I wonder why it took so long for such a feature to arise, is it because there's more general purpose compute on GPU's now?

That's just one of the many things you can do with them.

Really mesh shaders are just vertex shaders where you see 128 (or whatever the meshlet size is) vertices at once, so things like tesselation or blowing up geometry from 1 to [2,128] just naturally fall out of it.

But even if you just use them for regular triangle processing like you used vertex shaders before, you can do things like cull full triangle groups (a full meshlet) instead of culling per-triangle, which can be a lot faster and more efficient.

You can also use various features that used to be compute-only. Like shared memory.

You could quite easily have groups of triangles share data which was kind of annoying to do before.

Countless more things...

Almost everything mesh shaders can do were already possible with a compute shader that spits out triangles which a regular vertex shader then consumes and passes onto the rest of the pipeline. But with mesh shaders you cut out the writing and reading of that intermediary buffer completely, as your produced data is directly created from the typical vertex data and then handed onto the ROP units.

I think that about sums it up. The beauty of mesh shaders is that they don’t define how your input interface looks like, as long as you produce something in the end that the rasterizer can consume. Mesh shaders define two levels of compute shaders: one corresponds to an abstract “object” (which can be really anything you want) and one that corresponds to a more concrete “mesh” (a set of to be rasterizer primitives). The “object shader” can dynamically decide how many “meshes” will be generated and spawn the appropriate amount of “mesh shaders”. This gives you a level of indirection to do pretty much anything you want. It’s a generalization of the traditional rendering pipeline that supports user-defined types and structures and makes a lot of things simpler and more logical. Also a step to a more unified GPU programming model that actually exposes the massively parallel nature of the GPU hardware.

I am currently experimenting with polygon triangulation in the mesh shaders on Apple platforms and I’m rather happy with the results. The performance is excellent and the client code is radically simplified.

How is this different from tessellation?

Nvidia has a visual difference, see the table [1].

[1] https://developer.nvidia.com/blog/introduction-turing-mesh-s...

Reply on news.ycombinator.com