nit: The array of arrays of bytes is a little confusing to read, I think it would be easier to describe if we tracked the data and the initialization-state separately. Data as an array of N bytes, initialization state as an array of N/4 booleans.

When I read this I think "immediate data variable" means onevar<immediate>, of which there is of course only one (at most). But thatvar itself has aSizeOf the entire struct, whereas we actually want onlyaccessible parts of the struct to need to be initialized. That is going to require the WGSL spec to "reflect" some new information for us - the map ofslot -> is_accessible - for us to validate against.

I would recommend combining this PR with the WGSL PR, since there will be new integration between the specs.

Ok, Let me do this and abandon wgsl PR.

Unfortunately the WGSL spec doesn't really defined "padding" or "contains actual data". It probably should, but that's probably too much to ask to fix in this PR.

I think the text in this PR is good enough for all but the most adversarial reader. I recommend a followup PR (by the WGSL editors) to more carefully define padding and non-padding (or whatever we cal it).

API spec still needs to be updated to useAccessibleBytes?

Copying Alan's comment here:
#5424 (comment)

I agree with Alan here, the "Concrete ..." part is redundant, and should be removed.

We didn't really discuss this in the group, but do you have any opinion aboutsetImmediates instead? This is to try to improve the ergonomics very slightly but might be a bit confusing to developers given that an ArrayBuffer is passed.

I'm Ok forsetImmediates (TBH, I'm Ok for all simplification names). But better go through community meeting.

setImmediates sounds good 👍

I agree with Alan here, the "Concrete ..." part is redundant, and should be removed.

Unfortunately the WGSL spec doesn't really defined "padding" or "contains actual data". It probably should, but that's probably too much to ask to fix in this PR.

I think the text in this PR is good enough for all but the most adversarial reader. I recommend a followup PR (by the WGSL editors) to more carefully define padding and non-padding (or whatever we cal it).

As far as I can tell there could be nested structs. If we want to go with this algorithm, maybe we should instead recursively find all scalar and vector types and require the range [offset, offset + size) be set in the API?

As it stands for the structure cases I could have:

struct S {  a : vec4u,  b : u32}struct T {  x : S,  y : u32,}var<immediate> imm : T;

Since the align ofS is 16,SizeOf(S) is 32. That means some padding bytes are required to be set.

The spec uses, but does not define padding bytes. I wonder if it would be better to just define padding bytes and use that here.

The[[immediate_data]] internal slot is described as "initially empty" but also states "The length equals the device's {{supported limits/maxImmediateSize}}." These two statements are contradictory. It should be initialized to a byte sequence of lengthmaxImmediateSize with all bytes set to a default value (e.g., 0), not "initially empty".

+1

The[[immediate_data_set]] internal slot is described as "initially empty" but also states "The length equals the device's {{supported limits/maxImmediateSize}} divided by 4." These two statements are contradictory. It should be initialized to a list of lengthmaxImmediateSize / 4 with all entries set tofalse, not "initially empty".

+1

These edits look inconsistent with Shader Interfaces now. Also the carve outs for immediate data aren't great with the rest of the spec. I wonder if we should instead introduce a new interface for immediates. That might make all this cleaner. Thoughts@dneto0?

Yes, I think so.

There is a strong association with the pipeline layout rules, and those are all about things that have binding points.

Immediates are more like overrides, and override-declarations are already separately called out in the Shader Interface (section 13.3).

Also, override-declarations are called out in footnote 4 of the table in seciton 7. Variable and value declarations.

Tomorrow I'll try to make a patch to this PR to do this.

I've reworked it to make immediate data variables their own aspect of the shader interface, not part of the resource interface.
PTAL@alan-baker

Yes, I think so.

There is a strong association with the pipeline layout rules, and those are all about things that have binding points.

Immediates are more like overrides, and override-declarations are already separately called out in the Shader Interface (section 13.3).

Also, override-declarations are called out in footnote 4 of the table in seciton 7. Variable and value declarations.

Tomorrow I'll try to make a patch to this PR to do this.

nit: Maybe this should be calleddataSize, so it's clearly associated with the type ofdata (not specified in bytes). We can changewriteBuffer as well.

These are very hard to decypher. I think it might be better to write it out as something more then the set notation (I didn't realize the| ink + Offset | k in.. was doing set and wasn't or'ing together two things).

Maybe something like:

If |T| Is a structure |S|, then [=AccessibleBytes=](|T|) is the set calculated as:  * for each member `i` in S    * for each k in AccessibleBytes(`i`)      * Then the set contains k + `Offset`, where `Offset` = [=OffsetOfMember](|S|, `i`)

A similar reformatting formatrix could also be helpful

If |T| is a matrix with |C| columns and |R| rows, then [=AccessibleBytes=](|T|) is the set calculated as:  * for each `i` in 0..C-1     * for each k in AccessibleBytes(vec|R|)       * Then the set contains k + i * `Stride`, where `Stride` is [=roundUp=]([=AlignOf=](vec|R|), [=SizeOf=](vec|R|))