(This proposal was posted long before #1393, but)

In my opinion, this proposal produces considerably less readable code than #1393. With #1393, reading code requires only that you know the layout algorithm (very simple) and the default alignments/sizes (not trivial, but pretty concise). The alignments/sizes only ever diverge from the defaults when explicitly written.

This proposal requires the reader to know (up to) one layout algorithm per layout, and one table of alignments/sizes per layout.
Multiply that by 2-4 layouts and it's a lot.

I think this proposal also makes it much harder to match existing layouts (such as an engine's existing C struct that is set up to interoperate with GLSL and HLSL code) unless our rules match those of GLSL and HLSL (which are complex and difficult).

@litherum

What happens if I want to use the same struct in a storage buffer and a uniform buffer?

Then you just use the [[layout(general)]] on it, which is compatible with any host-shareable buffers.

What if my fields would just happen to have the same alignments/sizes in both contexts?

With this proposal, there is no "context" to derive the alignment/sizes from, other than the [[layout(xx)]] on the struct itself. So there is always one context, and it's explicit.

Can I assign from an instance of the storage struct to an instance of the uniform struct?

Since it's the same type, you can assign things of this type :)

@kainino0x

With #1393, reading code requires only that you know the layout algorithm (very simple) and the default alignments/sizes (not trivial, but pretty concise). The alignments/sizes only ever diverge from the defaults when explicitly written.
This proposal requires the reader to know (up to) one layout algorithm per layout, and one table of alignments/sizes per layout.
Multiply that by 2-4 layouts and it's a lot.

The fact that you see (or write) the alignment/sizes/offset/spans/whatever does not mean you don't need to know what your buffer is used for, which means, you have to know the layout requirements. So I don't clearly see how #1393 makes it cleaner. You still have to know the exact uniform layout rules (std140) in order to answer a question of whether this structure is going to be compatible with uniform buffers.

That is, perhaps, the core of my larger point: we can't pretend layouts don't exist. We have those defined in requirements for uniform/storage structures, and the choice is either:
(A) - we allow the user to lay out the structure in a custom way (via offset/sizes/spans/alignments), but also require them to be compatible with a layout they need, or
(B) - the user just explicit tells us what layout they need (this proposal).

Either way, in order to use a structure in host-shareable way, they need to know those (2-4?) layouts you mentioned.

I think this proposal also makes it much harder to match existing layouts (such as an engine's existing C struct that is set up to interoperate with GLSL and HLSL code) unless our rules match those of GLSL and HLSL (which are complex and difficult).

I also believe this point about matching is exaggerated. It's trivial to write a tool that would spell out the offsets for you, given a struct definition (i.e. we can get this into Naga/Tint/shader playground/you name it). It's a task for the machine, not a human. The reality is that most structs will just work as is, and that's also mentioned in #1393.

You still have to know the exact uniform layout rules (std140) in order to answer a question of whether this structure is going to be compatible with uniform buffers.

I don't think a code-reader needs to know that - I assume they would know if their shader doesn't compile. OTOH, it's much harder to know that your data is getting fed into the shader correctly, for every field. Therefore it's more important a code-reader be able to understand the latter (the data is being fed in correctly) than the former (the shader will compile).

I also believe this point about matching is exaggerated.

OK, I buy that. It's not core to my opinion though.

Therefore it's more important a code-reader be able to understand the latter (the data is being fed in correctly) than the former (the shader will compile).

I think I'm starting to understand your point better. Somehow, the discussion on #1393 wasn't clicking the main selling point of the proposal for me (sorry @ben-clayton ! I was asking the wrong questions, possibly). So here is what I see.

Both #1393 and this PR could benefit from tooling that tells you the exact offsets of the members. The difference, however, is how difficult it is for the reader to compute them in their head. In #1393, they'd only need to know the "default layout", and any changes have to be explicitly stated with [[size]] and [[align]]. In this PR, the user would at least need to know the "general" and "storage" as two different (at least for some types) layouts. In a way, #1393 could be seen as a middle ground between the offsets and this PR: it's implicit on the main path (expected to apply to most fields/types), and explicit on the side roads.

Consider me interested :) Just a bit concerned about the [[size]] and [[align]]: whether they are required for the proposal, and whether they need to be on types (which is what the PR does), or on fields directly, is not totally clear to me yet.

What happens if I want to use the same struct in a storage buffer and a uniform buffer?

Then you just use the [[layout(general)]] on it, which is compatible with any host-shareable buffers.

Oh, that's awesome! I missed that when reading the proposal. So general works everywhere, and storage only works for storage buffers.

Would there be any benefit to having a 3rd keyword, uniform, which would only work in uniform buffers and would be better (somehow?) than general?

Would there be any benefit to having a 3rd keyword, uniform, which would only work in uniform buffers and would be better (somehow?) than general?

I believe uniform buffers should be strictly more constraining than storage buffers.

In this PR, the user would at least need to know the "general" and "storage" as two different (at least for some types) layouts. In a way, #1393 could be seen as a middle ground between the offsets and this PR: it's implicit on the main path (expected to apply to most fields/types), and explicit on the side roads.

Yes. That's the point.

Earlier on:

"You want a layout? You got your layout. Easy peasy."

My trouble with this is this PR would contemplate a bunch of named layouts.
We have many years of experience that people and confused by the rules, and tools are buggy.
But you need to be a shader language lawyer to remember the differences between them. Everybody struggles with it.
I can't stress this enough. I have this feedback in the strongest terms, given by people who have had to deal with years and years of bug reports to well known graphics drivers.

The list of layouts can grow, with things like "relaxed" and "scalar" on the radar.

This is a bug, not a feature.

What #1393 gives is a default that "just works" both clearly and performantly, but gives you simple tools to dive into the details and do things exactly as you like, if the rules allow. Separating the layout algorithm from the rules is really important (thanks @kainino0x for emphasizing that). In future, if hardware and driver stacks evolve to support more things like scalar layout, then we can turn on a switch to relax the rules, but the algorithm for layout is the same.

@dneto0

Separating the layout algorithm from the rules is really important (thanks @kainino0x for emphasizing that)

After sleeping on this I realized that the layout algorithm is already separated out (see https://gpuweb.github.io/gpuweb/wgsl.html#memory-layout-intent, just need to become normative), and it's going to stay separated no matter what path we take (even the offsets, fwiw). So the algorithm separation is not an advantage of #1393, and is not specific to it.

Here is some perverted pseudo-code for #1393

const DEFAULT_LAYOUT: Layout = ...;
const STORAGE_RULE: Table = ...; // validation rules for storage buffers
const UNIFORM_RULE: Table = ...; // validation rules for uniform buffers
let custom_decorations; //`[[size]]` and `[[align]]`
let struct_layout = layout_algorithm(struct_declaration, DEFAULT_LAYOUT, custom_decorations);
validate(struct_layout, rule);

And here is one for this PR:

const STORAGE_LAYOUT: Table = ...; 
const UNIFORM_LAYOUT: Table = ...;
let layout_decoration; //`[[layout(general)]]` or `[[layout(uniform)]]`
let struct_layout = layout_algorithm(struct_declaration, layout_decoration);
// no validation needed!

This is meant to show how similar the approaches really are:

• in both cases, we have a table defined for the kind of layout we want. There is no getting away from that. The fact that [WGSL] Proposal: Default Struct Layout #1393 just totally ignores this aspect and says "we'll define uniforms rules later/separately" is a bit disingenuous, but I understand where it's coming from.
• in both cases, the layout algorithm is exactly the same, it operates on the sizes and alignments of the members. These just come from different sources.

The spec complexity in case of #1393 is a tiny bit higher (for the size/align decorations), and the users would have more friction to get the uniform buffers going, but the end result may be less error-prone, since tricky parts will have to be annotated with those decorations.

There's a key difference in who is paying for the complexity of understanding the rule set, at what stage of development.

Premise: Programmers read code many times more often than they write code.

With #1393, when a programmer looks at their struct, and can quickly read off where their data should be, and do it with high confidence. They only remember one set of rules. (With current spec requiring offsets everywhere, they remember zero rules, but that has worse writability.)

With named layouts, the programmer has to remember multiple sets of rules (that confuse everybody). They only get feedback when they get the data in the wrong place when integrating with the host side. This has poor readability and a bad feedback channel.

Separate point:

The memory-layout-intent section is really imprecise, because of ambiguities about how statements reference other statements and how far they recurse, and priority rules. It's not suitable as normative spec language.

@dneto0 that's a very reasonable line of thought!
Just one tiny thing:

This has poor readability and a bad feedback channel.

Generally speaking, it's the same feedback as with #1393, i.e. you have something in your head, and you can run a tool to verify your assumptions. So you are talking about more of a "easier to get right" or "easier to reason about" point here, since following the default layout + explicit decorations makes it easier for the reader than just knowing the layout name.

Superseded by #1393.