[subgroup-matrix] Consider improving flag for memory layout on load/store

The subgroupMatrixLoad() and subgroupMatrixStore() builtins currently use a bool parameter to indicate whether the memory layout is row-major or column-major:

... = subgroupMatrixLoad<LeftType>(&buffer, 0, false, 16)
                                               ^^^^^

This is not great from a readability or writability perspective.

We could improve this in a few different ways.

1. Add built-in constants for the different options

... = subgroupMatrixLoad<LeftType>(&buffer, 0, kSubgroupMatrixRowMajor, 16)

These would be in the global namespace (eventually the wgsl namespace). The parameter could stay as a bool, or we could switch to an integer which gives us room for future expansion if we ever need it (unlikely in this case).

2. Add an enum

Essentially the same as the above from the developer perspective, but with more clearly defined rules about what can be used. This would require us to add the concept of "enumerants that have values" to WGSL, which may be a substantial amount of work (also requested by user here).

3. Add different overloads for the different layouts

... = subgroupMatrixLoadRowMajor<LeftType>(&buffer, 0, 16)

This requires no new concepts from the language perspective as these are just new builtin overloads.

@dneto0

Another option was raised today by @dneto0:

4. Add another template parameter to the function

... = subgroupMatrixLoad<LeftType, RowMajor>(&buffer, 0, 16)

minutes from WGSL committee meeting 2026-3-24

JP: currently proposal for load/store one param specifies the memory layout, row or column major. In proposal it's a bool true/false. Hard to read/write. Think we should change it, few different options, could use named constants which we don't yet thave in WGSl but have discussed. Could add a proper enum for it which we also don't have in WGSL. Maybe a nice way to do it but more work. Or differently named overloads subgroupMatrixLoadRowMajor, etc. DN also mentioned it could be a template param to subgroupMatrixLoad to say the same thing. Dont' think we have a consensus on which option we prefer at this point
DN: We do have predeclared enumerants for access mode, address space and texel format. But we only use those in template argument positions. Don't need to add the feature to declare new enumerants, we just have a new predeclared one which is row_major/column_major
JB: Does this need to be dynamic? Something people can choose at runtime? I forgot what the type of buffer is, it's one that has to be subgroup matrix?
JP: No loading from a flat array of data.
JB: First impulse is type of buffer should be saying the layout, but if the proposal opted not to introduce new types for these matrices that would be a bit of a change. Is there a reason the proposal doesn' thave types?
JP: There are subgroup matrix types, but the data you're loading from/storing too doesnt' use those types
JB: Types only refer to tyings in registered, not stored. Is it bad idea to have type for the stored values?
DN: Think you're dynamically slurping data from things that usually come as opaque blobs of tensors and you iterate over and chop up. Think it's over-constraining to set the type
JB: Right you're breaking a thing up over blocks and that could depend on subgroup size and the data comes in and is what is it is. If we don't have to select dynamically, then template param?
JP: It could be, it's what DN suggested right before meeting
DN: Essentially same as changing name of function
JB: Yes, just a little neater/cleaner. Only suggestive, not substantive. Proposal seems like clarifying this would be nice. Everyone hates booleans, always have to lookup what they mean. Names are good. Enums seems like a large step. Options 2, 3 and unstated 4 would be the best.
DN: Just thinking about dynamic, intuition is you're doing loops to do the work and loops will proceed in a physically informed way. If you're incrementing x or y is coupled to row vs column major. So, don't think in the same set of static code you would not change dynamically
JB: Has to match loop it's in
DN: Comfortable as new names or template param
JP: In proposal where it's a bool it's required to be a const expression due to one of the backends. Needed to be done for code-gen purposes.
DS: Template param seems like a nice compromise to an explosion of function names
JB: Exactly. Sounds like ready for a proposal
JP: JB You said 2,3 and 4 but enums too far. But 2is enums.
JB: Oh, 1 is constants for true/false, 2 is separate type. I meant 3 or 4
JP: But not 1, not named constants.
DS: Named constants seems like a hack
Resolution: Send PR, template parameters.

Resolution: Let's go with Option 4

[subgroup-matrix] Update proposal (#6275)

Navigation Menu

Repository navigation

[subgroup-matrix] Consider improving flag for memory layout on load/store #5579

1. Add built-in constants for the different options

2. Add an enum

3. Add different overloads for the different layouts

4. Add another template parameter to the function

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[subgroup-matrix] Consider improving flag for memory layout on load/store #5579

Description

1. Add built-in constants for the different options

2. Add an enum

3. Add different overloads for the different layouts

Activity

jrprice commented on Mar 24, 2026

4. Add another template parameter to the function

jimblandy commented on Mar 24, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions