AMD's Vega whitepaper summarized the surface shader as a shader type generated when tessellation was enabled. It encapsulates the initial vertex shader and hull shader stages, while the primitive shader is adjusted to encapsulate the domain and geometry shader stages. The surface shader is associated with the fixed-function tessellation stage, and it is this optional stage that governs whether the pipeline is split at a point of work amplification.
Ok, some thoughts. AMD has no "vertex shader", it's a compute shader with "interpolator outputs" (or not, just use UAVs instead), which can easily mean spill-to-LDS. The TaskShader for AMD is the wavefront kicker (probably the ACE/HWS), it takes the number of instances to create from the draw-command and instances them, that's it. The next [programmable] stage get's the lane-number and then does everything manually and drops it somewhere inside the chip/CU.
The magic is vertex connectivity, but from the software perspective that's just some clever coded likely implicit (from ordering) information. So, the hull-shader is only really producing new instances programmatically albeit constrained, and allows you to specify the instance-seed-values yourself, also possibly through LDS. If that really is fixed function in GCN ... who knows. So, tessellator is also only TaskShader.
Now comes the real difference. It appears in the MeshShader you have to write the connectivity yourself, while under the old API model the connectivity was implicit (the recursive subdivision rule). That means you have to store that information now for sure. But then, the DomainShader is just the suffix-code of a MeshShader, positioning the connected vertices.
I don't see how all of this wasn't just minor different conventions to obscure the scheduling part, having it implicit instead of explicit for the sake of ... not sure. Maybe it was Nvidia itself when DX11 was specified, because the DX9 tesselator extension from AMD was completely free of this stuff, the subdivision-level was simply a multiplier for the instance-generator and you got context-free triangles + barycentrics to do whatever you wanted in the vertex-shader (kind of like triangle-shader, not unlike the DomainShader).
The only different thing I see is, now you control amplification without implicit data generation, and explicit connectivity. And it seems recursive amplification.? Well, the Tesselator was also specified as recursive amplification. That's just streightforward generalization of this heterogenous multiple amplification points in the DX11-API.
Task shaders are optional, albeit not necessarily due to tessellation-like behavior. They can spawn extra child mesh shader workgroups, but this isn't necessary. The subdivision point for the pipeline then becomes a less straightforward one than the tessellation hardware presents, as it may not be a customary expansion since the customary tessellation unit is not there.
Which tesselation hardware. What would you resonably expect to be dedicated hardware? Try to imagine the most basic generalized building blocks needed to implement it. You don't want overly specialized silicon, I've not seen a tesselation-block on a die-shot (there might be some, but's not big and complicated and ugly). The principle problem is data-routing, and that's probably the only FF part of it, put data from somewhere to somewhere else 1:N style.
Remember AMD suggests to use the DomainShader to cull triangles using the 1:1 amplification case, basically using the stage as a decimator instead. How's that a senseful suggestion when that's FF?
The task shader is indicated as being able to make object and inter-mesh level decisions in terms of selecting meshlets, LOD, and meshlet culling. Surface shaders are described as taking the same sorts of inputs as the vertex+hull shader stage, and presenting the usual output. It falls upon the later primitive shader stage to try culling as effectively as it can from the output of the tessellation unit. The broader set of inputs/output and upstream decision making of the task shader were not mentioned.
Yeah, but that's all just creative imaginations. "Your could possibly". If something's free of implicity I can do all kinds of creative things, that's not a checkbox for MeshShader, it's a checkbox for ThinkOutOfTheMuchLargerBox.
Mesh shaders are indicated as being more closely aligned with vertex shaders, requiring some preprocessing instructions. This is similar to primitive shaders' being generated from vertex shader code. Mesh shaders may have some level of culling, but the general tenor is that if the task shader has performed cluster culling sufficiently, it is more effective to let the mesh run through to the rasterizer and beyond rather than pile up more up-front work in the shader path (one subset involving heavy attribute usage mooted a PS-like prospect). Primitive shaders have limited detail as to all the transformations they perform, but a conservative triangle sieve is the most straightforward description of the initial offering. How exactly this process is performed or how it would look in the shader code was not described.
The mesh shader has an element of precomputation for meshlets in static geometry, which is something the descriptions of primitive shaders do not mention.
That's just the same limitation as factor 64 for tesselation. Seems coincidence? Don't think so. I assume <= 64 uses the previously employed internal storage and above it spills to memory just like geometry shader stream-out. They don't say you can't do it, they say it performs predicably upto 64/126.
At this point, I think I am repeating my suspicion that these are methods with some evolutionary similarities derived from facing similar conditions in the same location in the pipeline, but with different decisions as to the scope and integration with their individual standard pipelines. Saying one element is the same as the other may gloss over the areas where their priorities and judgement calls differ.
It's different so say one is different from the other because of hardware differences (and _not_ performance differences), and to say it's different from each other because of ecosystemic points of view.
Nvidia dropped this thing as an extension to DirectX into the NVAPI. It's the way Nvidia is going forward, they like and are able to spam extensions. Last time AMD did want to communicate it's vision it led to an entire alternative data-management paradigm (and API) instead of shoehorning it into DX. That shoehorning came from MS, and it's ... hu ... a bit ugly honestly.
