Handling dynamic Metal maxThreadsPerThreadgroup

[reeselevine]

I believe that the maxThreadsPerThreadgroup reported by Metal backends can change based on pipeline/shader complexity.

This can cause issues where a user attempts to launch shaders based on WebGPU's reported maxComputeWorkgroupSize{XYZ} or maxComputeInvocationsPerWorkgroup limits, but the actual limit for that shader in a given context is lower.

I encountered this issue running WebGPU natively using Dawn's bindings, and it caused a silent failure which I was only able to diagnose after enabling Metal shader validation/debug mode. I'm not sure if something similar would happen in the browser.

Opening this issue to see if anyone else has encountered/thought about this issue, and to see if there are any good solutions.

[jrprice]

I've also hit this: crbug.com/443794633.

I think we can address this by emitting [[max_total_threads_per_threadgroup(...)]] in the MSL that we generate. It changes the performance of shaders (some get better, some get worse), but I think this is probably OK (we're giving the MSL compiler strictly more information).

[reeselevine]

@jrprice oh nice! My error was exactly the same, tried to launch with 1024 but got the error message saying 704 was the max :).

If your proposed fix works that's great, since it wouldn't require any changes to the WebGPU spec either.

[mwyrzykowski]

I think you can also set -[MTLCompileOptions maxTotalThreadsPerThreadgroup] - https://developer.apple.com/documentation/metal/mtlcompileoptions/maxtotalthreadsperthreadgroup

But yes in any case, I don't think we require a change to the WGSL specification

[jimblandy]

Minutes from WGSL committee meeting Oct 7 2025

• DN: Sounds like impl issue, no spec changes required
• JP: Maybe discussion around issue, but can wait.

[jimblandy]

My unofficial summary: seems like something implementations can fix, probably no spec changes necessary.

[jimblandy]

As it seems likely that no spec work is necessary, I'm going to tentatively close this issue. But if we discover that the fixes proposed above aren't satisfactory and spec changes are indeed needed, please feel free to re-open.

[jrprice]

One interesting note for implementors is that setting the maximum total threads per threadgroup can impact shader performance, both positively and negatively. It looks like WebKit used to set the maximum number of threads, but then removed that code because it was found to make a WebGPU demo slower.

[mwyrzykowski]

Yes the difference was quite substantial