True, it is a bit confusing without context.
Argument tables basically put all power to you as the developer on how you want your rendering pipeline to interpret your GPU uploaded data.
Also, you are free to replace the typical vertex input workflow (using stage_in and MTLVertexDescriptor) with raw buffer indexing in the shader. The "Drawing a triangle with Metal 4" sample demonstrates that.
So with the attributeStride parameter you can (loosely) recreate what stride does on MTLVertexBufferLayoutDescriptor.
It is true that the C++ side structs will determine the underlying buffer layout for the shader, but what if you wanna have multiple variants of the buffer types?
e.g.
struct {
simd_float2 position;
simd_float4 color;
} VertexData1;
struct {
simd_float2 position;
simd_float4 color;
simd_float3 normal;
simd_float2 uv;
} VertexData2;
E.g.: Imagine you have a big vertex buffer that contains lots of data, but not all shaders use the same vertex inputs.
Maybe you are interleaving or otherwise packing vertex info like positions, normals, tangents, uvs etc. But you have multiple shaders, one that only processes positions and normals, and others that need the full set of attributes.
So to avoid recreating slicing your original GPU buffers to subsets of the same data, you just create a different 'view' of your buffers, binding the same GPU buffer with different strides on the argument table.
Hope this all makes sense, this is how I understand it.
Having said that, I haven't used this API so the above is speculative.
