GLSL_NV_mesh_shader confusion about storage layout qualifiers for perTaskNV

[seanbaxter]

Is there language on how to define perTask-tagged blocks in SPIR-V? glslang is generating Offset and MatrixStride OpMemberDecorates for perTask-tagged ins/outs, as if they were SSBOs or UBOs, but the actual storage class is Input/Output. Nowhere else, I believe, does SPIR-V use storage decorations for anything other than UniformConstant, StorageBuffer, PushConstant or ShaderRecordBuffer.

All the mesh shader interface variable declarations seem unidiomatic and I'm not confident I can get things all right just by probing glslang.

[seanbaxter]

I believe the perTask objects are actually kept in shared memory and therefore require layout, but are confusingly named as In/Out storage class. The mesh shader stuff I put in seems to be working so I guess it's right?

[kholtnv]

The blocks marked taskNV are in task memory which does get the SPIR-V intput/output storage class and in theory one could eliminate the offset/stride. However, doing some probing in the NV compiler, offsets, when internally allocated, differ from what glslang uses.
So, it is an all or nothing proposition. Either the task/mesh shaders don't use any decorations or they both must use matching decorations. Keeping the glslang offset/stride decorations seems the safest way to go. And, perhaps it should be stated in some future version of SPIR-V that task memory (in SPIR-V marked PerTaskNV) must have a stride/offset.