@jrprice has some feedback about this concept that it's weird/unsatisfying.

Previews, as seen when this build job started (242b728):
WebGPU | IDL
WGSL
Explainer

Can we please split these commits into separate PRs?

Yeah, this builds on #2103, as preliminary work.

I see now. Was expecting the base PR to be mentioned in the main description, but it wasn't.
Will take another look!

[process]
Marking this as draft because it shouldn't land before #2103

The new commit is just a rebase.

Previews, as seen when this build job started (22a892b):
WebGPU | IDL
WGSL
Explainer

[process] Marking this as draft because it shouldn't land before #2103

This is now independent of #2103. I still need to revisit #2105 which is meant to build on this PR and be considered together.

Previews, as seen when this build job started (d8bbd15):
WebGPU | IDL
WGSL
Explainer

This is now independent of #2103. I still need to revisit #2105 which is meant to build on this PR and be considered together.

Oops. I think I left some 2103 material in.

And I think this accidentally allows runtime-sized arrays to appear in private, workgroup storage.

Previews, as seen when this build job started (6dff330):
WebGPU | IDL
WGSL
Explainer

Previews, as seen when this build job started (a49f5d7):
WebGPU | IDL
WGSL
Explainer

Previews, as seen when this build job started (d6ae22b):
WebGPU | IDL
WGSL
Explainer

How is the implementation supposed to behave for this case?

struct Foo {
...
};
var<uniform> foo: Foo;
struct Bar {
  foo: Foo,
};

fn func(f: Foo) {
...
}

My understanding is that SPIR-V backend would have to generate 2 different stuctures for Foo: one with the block attribute, and one without. But then how would func signature look like? Would we also need to generate two different func bodies?

Wouldn't the argument to func be passed by value, so that it is using the non-decorated version of Foo?

Vulkan 1.2 spec section 15 "Shader Interface"

This specification describes valid uses for Vulkan of these decorations. Any other use of one of these decorations is invalid, with the exception that, when using SPIR-V versions 1.4 and earlier: Block, BufferBlock, Offset, ArrayStride, and MatrixStride can also decorate types and type members used by variables in the Private and Function storage classes.

It seems that newer version of SPIR-V would disallow using a Block-decorated Foo anywhere but in the interface declaration so you'd need two structs anyway.

Ok, so there is one func instance in the generated code. And then the user does func(foo). Are we expected to go and manually copy over the contents (field by field?) from the decorated structure into non-decorated?

I think so. That's what happens in GLSL with this small shader (that's a bit similar up to variables in buffer being injected in the global scope):

#version 460
struct Foo {
  int a;
  int b[4];
};

layout(std430, binding=0) buffer MyFoo {
  Foo foo;
};

void f(Foo a) {
}

void main()
{
    f(foo);
}

How is the implementation supposed to behave for this case?

My understanding is that SPIR-V backend would have to generate 2 different stuctures for Foo: one with the block attribute, and one without. But then how would func signature look like? Would we also need to generate two different func bodies?

We discussed this internally, and the solution I think Tint is going to use is to wrap the uniform and storage buffers with a single-field block-decorated structure, and adjust any uniform / storage buffer member-accesses to go via that single field. All other uses of the structure are kept as-is.

So:

struct Foo {
  i : i32;
};

[[group(0), binding(0)]] var<uniform> ubo: Foo;
[[group(0), binding(1)]] var<storage, read_write> ssbo: Foo;

struct Bar {
  foo: Foo;
};

fn func(f: Foo) {
  ssbo.i = f.i;
  x := ubo;
}

Would internally translate to:

struct Foo {
  i : i32;
};

[[block]] // For internal / illustrative purposes only.
struct FooWrapper {
  inner : Foo;
};

[[group(0), binding(0)]] var<uniform> ubo: FooWrapper;
[[group(0), binding(1)]] var<storage, read_write> ssbo: FooWrapper;

struct Bar {
  foo: Foo;
};

fn func(f: Foo) {
  ssbo.inner.i = f.i;
  x := ubo.inner;
}

This same transformation would work for non-structure storage and buffer types.

Yes, that makes sense. Thanks @ben-clayton !

One thing to remember is if there's a runtime-sized array in the struct, then SPIR-V/Vulkan requires it to be in the outermost struct for an SSBO. But WGSL can't use that struct anywhere else anyway.

Added this issue to the next agenda.

Right, so this transformation doesn't apply to all storage/uniform structures, it excludes the ones with run-time arrays. That seems fine.

Rebased against main. No content change.

Previews, as seen when this build job started (49b56fd):
WebGPU | IDL
WGSL
Explainer

Approved in 2021-11-30 meeting