Mesh Shaders Tracking Issue

[SupaMaggie70Incorporated]

Should replace #3018.

Progress

Spec: being added in #7885. The spec there is currently the most up to date reference.

Current open PR(s) and other work

#7345
#7930

naga

• Add mesh, task shaders to naga shader types so wgpu-hal can stop pretending they are compute shaders - Add mesh shader stages to wgt::ShaderStages and naga::ShaderStage #7292
• Support in WGSL frontend - Initial naga changes for mesh shaders #7930
• Validation - Initial naga changes for mesh shaders #7930 (partial, doesn't check against limits though)
• Support in SPIRV writer - Initial naga changes for mesh shaders #7930
• Support in hlsl/msl writer
• Reflection info for pipeline validation

wgpu-hal backends

• Vulkan - Mesh shaders - initial wgpu hal changes #7089
• DX12 - Mesh Shading for DirectX 12 #7219
• Metal

Other

• Formal spec - Added mesh shading spec #7885
• wgpu API - Add mesh shading api to wgpu & wgpu-core #7345
• wgpu-core pipeline validation - Add mesh shading api to wgpu & wgpu-core #7345 (?)
• General tests- Add mesh shading api to wgpu & wgpu-core #7345
• More tests - line rendering, limits, etc
• Examples - Add mesh shading api to wgpu & wgpu-core #7345

Features

• Multiview mesh shaders #7262
• Per-primitive fragment shader inputs
• Primitive ID builtin (I haven't looked at or thought about this yet at all)
• Queries
• Point primitives(at least in vulkan)
• Finalize limits. I haven't spent enough time looking at how limits are handled. But it may be that for example some devices allow having very large x and y dimensions for dispatches and low z dimensions. Right now we just use the lowest of all dimensions.

Current Priorities

• Multiview in wgpu-hal - very simple - Add multiview mesh shaders to wgpu-hal #7278
• Naga types - needed for wgpu-hal completeness(current code pretends they are compute shaders) - Add mesh shader stages to wgt::ShaderStages and naga::ShaderStage #7292
• Formal spec created and added to trunk - Added mesh shading spec #7885
• Experimental wgpu API - blocking many things - Add mesh shading api to wgpu & wgpu-core #7345
• Lots of testing for wgpu - Add mesh shading api to wgpu & wgpu-core #7345
• Naga WGSL frontend - needed for proper wgpu implementation - Initial naga changes for mesh shaders #7930
• Naga SPIRV backend - needed for proper wgpu implementation - Initial naga changes for mesh shaders #7930
• Naga reflection info - needed for proper wgpu implementation
• DX12 in wgpu-hal - desired

Current workarounds

Possibly incorrect validation layers error

See KhronosGroup/Vulkan-ValidationLayers#10404.

Once everything is implemented correctly this shouldn't be an actual issue. All the built-ins (except the indices stuff) will need to be in the same struct anyway, since you can only have one such struct for builtins per 15.1.1.

Issues to work out

• How to implement multiview, what features, etc
• What information needs to be exposed through adapter limits
• How should point primitives be handled(probably not possible on directX?)
• Per primitive things on fragment shader

API differences

Task payload handling

• GLSL - only a single variable with the taskPayloadSharedEXT storage class per compilation unit(or none). This is then automatically passed to the entry point.
• SPIR-V - Variables can have the TaskPayloadWorkgroupEXT storage class. This is then optionally passed as an argument to OpEmitMeshTasksEXT. For mesh shaders the payload variable is inferred.
• HLSL - For mesh shaders, input is taken as in payload MeshPayloadStruct MeshPayload in function signature. groupshared payload_t MeshPayload is taken as an argument to DispatchMesh in task shaders.
• MSL - Task shaders write the payload using object_data Payload& outPayload [[payload]] in the function parameters. Mesh shaders read them with object_data const Payload& payload [[payload]].

Current proposed method: in WGSL, an @payload(global_var) attribute for entry points. Potential drawbacks:

• May not be able to properly parse all SPIR-V shaders. This is a tradeoff, as HLSL/SPIRV have the potential payload output specified in the emitMeshTasks function, while MSL/GLSL has it specified in the entry signature. This should be fine anyway, but may require smarter parsing for SPIRV.

[SupaMaggie70Incorporated]

@cwfitzgerald
I’ve been thinking, we probably ought to have some way to indicate the “payload” for task and mesh shaders. I’m updating the original comment to add an attribute, @payload(some global variable). This would also probably mean we don’t need a new storage class. Let me know if you think there is a better option.

[cwfitzgerald]

Sounds fine - one thing to keep in mind that we want the IR to be compatible enough with how SPIR-V does stuff, such that spirv-in can eventually support mesh shaders. I don't know specifics about how mesh shaders work in spirv, but we should be careful to not require things that are too hard to implement in that frrontend. We' already require heroics in the spirv frontend for atomics.

[SupaMaggie70Incorporated]

@cwfitzgerald Thanks for the response. I'll try to keep a list of things that might be hard to implement in certain environments.