I think there are (at least) 2 directions to pick from here.

Keep in mind that, regardless of which direction we go, the lengths of these dynamically sized allocations must be supplied to the create*Pipeline() call. The issue at hand is the mechanism for representing this in the shading language (and, to a lesser degree, what should the IDL of GPUProgrammableStage contain).

Option 1

Treat this feature as normal specialisation constants. If you want to get the length of the array, just use the name of the specialisation constant:

[[override]] let myLength: i32;

var<workgroup> myWorkgroupArray: Array<f32, myLength>;

fn foo(...) {
    for (var i: i32 = 0; i < myLength; i = i + 1)
        ... myWorkgroupArray[i] ...
}

But, this would be limited to only work in very narrow circumstances:

// These don't work:
var myWorkgroupArray: Array<f32, myLength>;
var<private> myWorkgroupArray: Array<f32, myLength>;
var<workgroup> myWorkgroupArray: Array<Array<f32, myLength>, 17>;
struct myStruct {
    myArray: Array<f32, myLength>;
}

Option 2

Add a new attribute for this, which goes on the var<workgroup> variable. If you want to get the length of the array, use the same arrayLength() function that we currently have today for getting the length of runtime-sized arrays:

[[dynamic_size]] var<workgroup> myWorkgroupArray: Array<f32>;

fn foo(...) {
    for (var i: i32 = 0; i < arrayLength(myWorkgroupArray); i = i + 1)
        ... myWorkgroupArray[i] ...
}

And then (possibly!) add a new member to GPUProgrammableStage:

dictionary GPUProgrammableStage {
    required GPUShaderModule module;
    required USVString entryPoint;
    record<USVString, GPUPipelineConstantValue> constants;
    // The new one 👇
    record<USVString, GPUPipelineLengthValue> dynamicThreadgroupSizes;
};

typedef unsigned long long GPUPipelineLengthValue;

If we wanted to unify the binding namespaces of the pipeline-overridable constant attributes and the dynamic_size threadgroup attributes (so [[override(7)]] and [[dynamic_size(7)]] would collide, and the constants and dynamicThreadgroupSizes members of GPUProgrammableStage could be collapsed), that would be reasonable.

Maybe there's a third option I haven't thought of yet.

Uh oh!

Dynamically sized threadgroup memory #2024

Description

Activity

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions