[Metal] Mesh Shader thread_index_in_threadgroup (localID) always 0 in wgpu 28.0.0

[apps4uco]

Description

When using Mesh Shaders on the Metal backend, the thread_index_in_threadgroup (or localID) appears to always be 0, regardless of the [[max_total_threads_per_threadgroup(N)]] attribute in the MSL shader.
Parallelized logic fails (e.g., assigning colors or positions based on threadIndex), while a manual for loop within a single thread correctly renders geometry. This suggests the MTLRenderPipelineState is being initialized with a threadgroup size of 1 instead of the size defined in the shader.

Disclaimer: My analysis might be completely wrong, if I have made a mistake in the code, could you suggest the correction and could the working example be included in the crate?

Repro steps

I created a new example mesh_shader_parallel in the examples/features directory in the forked repo:

https://github.com/apps4uco/wgpu

cargo run -- mesh_shader_parallel

Expected vs observed behavior

Currently no geometry is shown.

Expected the same result as mesh_shader

Extra materials

No errors are produced

Platform

Information about your OS,

uname -a

Darwin apps4u.local 25.0.0 Darwin Kernel Version 25.0.0: Mon Aug 25 21:17:45 PDT 2025; root:xnu-12377.1.9~3/RELEASE_ARM64_T8103 arm64

Macbook Air M1

version of wgpu

trunk (28.0.0)

rustc --version
rustc 1.93.1 (01f6ddf75 2026-02-11)

[ErichDonGubler]

Pinging @inner-daemons as somebody who's worked with mesh shader implementation.

[inner-daemons]

Ok so max_total_threads_per_threadgroup doesn't do much other than hint to the metal compiler to optimize for a <= workgroup size. You still have to tell wgpu which workgroup size to use. See ShaderModuleDescriptorPassthrough::num_workgroups, though the name is actually wrong here (its workgroup size not num workgroups).

[inner-daemons]

The passthrough shader descriptor will be updated in #9064, but I doubt that will make it in for the 29.0 release.