[subgroup matrix] Allow subgroup_matrix types in private address space?

The proposal describes only allowing subgroup_matrix types in Function or Private address spaces. Private is a little problematic because of the subgroup uniformity analysis. All mutable global variables are considered non-uniform. So any subgroup_matrix type in private address space would be non-uniform and effectively require disabling the analysis to use.

Suggest disallowing private for now, but consider supporting global variables in uniformity analysis via a desugaring as a separate language feature. If added we could then also allow private subgroup matrices.

Background: a subgroup_matrix value's representation is effectively spread across all a subgroup's invocations, so they are inherently subgroup-uniform.

Couldn't we just change the analysis to say that private variables must be uniform if they contain subgroup_matrix types? Storing a non-uniform value in one would be an error. (It would have to be a composite type containing other values, because the subgroup_matrix value itself would always be uniform.)

minutes from WGSL committee meeting 2025-11-17

DN: can declare a subgroup matrix in a function or module scope private. In buliltin function requires subgroup uniform value and control flow. Uniformity analysis says any mutable at module scope is non-uniform. Could be updated from anywhere with any value. Can't see far enough to deduce value. Poses problem by putting a value in there analysis breaks down. Would then require the shader author to disable the analysis through the diagnostic. Simple thing is to say don't allow that case to come up. What we were thinking internally is the issue of mutable module scope variables can be handled if you generalize uniformity by pretending they're initialized in uniform control flow at the entry point and passed in by parameters. We handle uniformity of parameter pass/return. A more general purpose way to solve entire problem. So, want to fork that as a separate uniformity enhancement and not worry about now.
JP: Alan suggested disallow for now.
JB: Is subgroup matrix predicated on making a distinction between subgroup and workgroup uniformity? Or hoping to get in without distinction
JP: no. Not coupled like that> will probably do subgroup uniformity first as it's almost done, but can do subgroup matrix without it, just changes algorithms you can write. No hard spec link.
JB: Understanding is a subgroup matrix values representation is spread across all invocations so it's intrinsically subgroup uniform. But, to be useful have to be workgroup non-uniform. So, WGSL declares these as non-uniform because it can't make the distinction.
DN: That's right.
JB: So having analysis say all values are non-uniform isn't going to be a problem?
DN: That is the problem we're coming up against
JB: Nothing to do with private at all, forgetting private, hopefully the analysis will say they're non -unform.
JP: Without extensions can only use subgroup matrix with a single subgroup our you'll trigger errors. So, get some perf but not peak
JB: So workgroup is size of one subgroup?
JP: Yes, also diagnostic to disable subgroup-uniformity checks in the absence of subgroup uniformity.
JB: Wasn't aware, you can disable the uniformity check just for matrix but not barrier?
JP: Yes, we have the same for subgroup with a subgroup uniformity diagnostic control. In practise we as an implementor will ship subgroup matrix with subgroup uniformity as it isn't super useful
JB: One idea, if the proposal authors would prefer putting off private variables that seems fine, this is something we can add later. Does seem like we could just say a private variable that contains a subgroup matrix is assumed to be …. want to say assumed to be subgroup uniform. In the current spec would assume to be uniform. The idea being you'd use the type to say because the private contains a subgroup matrix the assumption that it's non-uniform is non-useful so assume it's uniform and require all assigned values to be uniform. Gets without a lot of work
DN: Interesting. Reflecting back, the logic behind is that you could have only correctly formed the original matrix before you stored it in uniform or subgroup-uniform control flow so therefore the source of the data must have been uniform. That seems to be sound.
JB: If you have a struct with an int next it breaks down
DN: Some notion that only a subgroup matrix in the variable.
JB: Yea, like an array
DN: No tainting by other things. Interesting. Given we have new information, lets let this stew and we'll think about it.
JB: Sounds good, we'll come back to this. (If the proposers prefer to set aside and call M3 that's also fine.)
JP: I'll say it's not clear to us there are lots of compelling use cases for module scoped vars. Usually in a function and scoped to the function. So not particularly motivated to solve this if we see other means to solve it.
JB: Devs can always desugar themselves instead of using a var and pass a pointer. The urgency is low.

@dneto0

@dneto0 What is the next step for this issue? Since the urgency is low, should we assign this a later milestone? Should we treat #5445 as taking its place and close this issue?

minutes from WGSL committee meeting 2026-1-6

JB: Suggest moving to M3 (currently M2). We're discussing uniformity analysis: desugar module-scope variables as if they are declared inside the entry point and passed down as parameters #5445 now, and previous discussion concluded this wasn't urgent.
DN: Agree.

Navigation Menu

Repository navigation

[subgroup matrix] Allow subgroup_matrix types in private address space? #5435

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[subgroup matrix] Allow subgroup_matrix types in private address space? #5435

Description

Activity

jimblandy commented on Nov 18, 2025

jimblandy commented on Nov 19, 2025

jimblandy commented on Dec 9, 2025

jimblandy commented on Jan 8, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions